EDD Commissions tracks vendor earnings from EDD sales in its own table (edd_commissions), with status flags for unpaid, paid, and revoked. The default admin lists commission records with a fixed column set: vendor, product, amount, status, date. To run a monthly payout batch you filter by date and status, hope the filter holds across pages, and then mark records paid one at a time as you wire each vendor.

SleekView reads edd_commissions directly and joins it to the vendor (a WP user or vendor post type depending on your stack), the parent edd_orders record, and the download product. A vendor-aggregate view shows total unpaid per vendor as one row each (sum of amount grouped by vendor id) so a finance lead reconciles the batch list before any transfers go out. Drill into a vendor row to see the underlying commission records as a child table.

Status changes route through EDD Commissions' CRUD helpers where supported, so bulk-mark-paid fires the same hooks the per-record screen does. The audit trail (timestamp, who marked it paid, reference id stored in commission meta) stays consistent whether you mark one record or three hundred.

Running a multi-vendor EDD marketplace at scale means monthly payouts to dozens or hundreds of vendors. Each vendor expects a reliable cadence, accurate amounts, and a clear record of what they're being paid for. EDD Commissions does the accounting correctly: every sale generates a commission record with the right amount, the right vendor reference, the right product.

What it doesn't do is shape that record list into the work the finance team actually does. The finance team works in batches: this month's unpaid by vendor, with payout method visible, exported for the bank transfer, marked paid after the wire confirms. The default per-record list makes that flow possible but tedious — marking each record paid in a 300-record batch is half a workday.

SleekView reads the same edd_commissions table and groups it by vendor, surfaces the payout method from usermeta, and lets finance bulk-mark-paid through the CRUD layer so audit hooks still fire. Same database, same hooks, the monthly payout cycle compresses from a workday to an hour.