How admin analytics should work across vendors, orders, and commissions

Exporting 3 separate spreadsheets every Monday morning just to answer one question, who owes money, and who's owed it, isn't sustainable once a marketplace hits 60 active vendors. That's not an analytics problem. It's a system design problem.

The way most platforms handle this, vendor data lives in one section, orders in another, and commission calculations happen somewhere else entirely, usually in someone's head or a Google Sheet. The Multi-Vendor Marketplace Platform we build at Cloudgramam is designed around the opposite assumption: every number a founder needs should connect to every other number, in real time, without manual reconciliation.

Why totals are the least useful number in your dashboard

A total revenue figure tells you almost nothing operational. If your marketplace did ₹18 lakhs in orders last month, you still don't know which vendors drove it, which ones are dragging return rates up, or how much of that revenue is actually yours after commissions.

The useful number is always a breakdown. Revenue by vendor, orders by status, commission earned versus commission pending. When those three views are separated, you're doing accounting. When they're connected, you're running a business.

Where commission data breaks down in most setups

Commission logic sounds simple until you have vendors on different rate tiers, some with flat fees and some with percentage cuts, some with category-specific overrides. At that point, a single commission column in your orders table stops being accurate.

What you need is commission calculated at the line-item level, not the order level. A single order from Vendor A might contain 2 products from different categories with different commission rates. If your system collapses that into one figure, your payout reports will be wrong, and you won't know it until a vendor disputes a transfer.

Statista's global ecommerce revenue data shows marketplace models growing faster than single-vendor stores, which means the commission reconciliation problem gets worse as you scale, not better.

What a vendor-level analytics view should actually contain

Each vendor in your admin panel should have a profile that isn't just contact information. It should show you, at a glance, everything operationally relevant about that vendor's current standing.

• Orders received vs. orders fulfilled in the current period, with a fulfilment rate percentage so you can spot vendors slipping before buyers start complaining
• Commission owed to you broken down by order, with a running total for the payout cycle
• Commission owed to the vendor (their net payout), accounting for returns, cancellations, and any adjustments already applied
• Return rate by vendor, because a vendor with a 22% return rate is a problem you want to catch in week 2, not at the end of the quarter

That's the minimum. Anything less means you're making vendor management decisions with incomplete information.

Order status visibility across the whole marketplace

From the admin side, you need to see every order's current status without opening individual vendor accounts. Pending, confirmed, shipped, delivered, disputed, returned. Each status should be filterable and exportable, and the count in each bucket should update in real time.

The reason this matters operationally: if 40 orders are sitting in "confirmed" status for more than 48 hours across 5 vendors, that's a fulfilment problem you can address before it becomes a customer service problem. A dashboard that only shows you delivered orders is a lagging indicator. You need leading ones.

Payout cycles need their own workflow, not a manual step

The payout process is where analytics and operations meet. Once your commission data is accurate at the line-item level and your order statuses are current, generating a payout run should take minutes, not a day of cross-checking.

A proper payout workflow looks like this: you set a cycle (weekly, biweekly, monthly), the system calculates each vendor's net payout automatically accounting for commissions, returns, and any held amounts, you review a summary, approve it, and the transfer instructions go out. The admin panel logs the payout against each vendor's history so there's a clean audit trail if anything is ever disputed.

When that process requires manual steps at the calculation stage, you're spending founder time on bookkeeping. That's the wrong use of the role.

Cloudgramam builds marketplace admin systems where vendor data, order tracking, and commission logic are connected from day one, so the numbers you need are there when you need them, not after an export. If you want to see how this works in a live build, talk to the team.