---
id: saas/take-rate-marketplaces
industry: SaaS and technology
usage: specific
effort: medium
grain: Transaction (fact); customer (seller, creator, store) x day and x month
---

# Take rate: transaction volume against platform revenue

How much went through the platform, how much of it is your revenue and where it comes from, by customer and by month, without confusing volume with revenue.

## Executive summary

**For:** SaaS that charges a commission on its customers' transactions: payment, creator and delivery platforms and B2B marketplaces.

**What it solves**

- Transaction volume and platform revenue in separate columns, each with its own rule.
- Revenue broken down by source: commission, interest, advances and fees.
- A take rate per customer that matches what the platform charges.

**Why it matters:** On a transactional platform, volume impresses and revenue pays the bills. Summing volume as revenue inflates it many times over; netting refunds out of volume hides the loss. With volume and revenue separated by source, you can see which customers bring volume with little margin and when a fee change moved the result.

**Business questions it answers**

- What is this month's take rate and how did it change from last month?
- How much revenue came from commission, installment interest and advances?
- Which customers have high volume and a take rate below contract?
- How much did the top 10 customers transact this week against last week?
- How much did we lose to refunds and chargebacks this month?

**What you need**

- The product's orders, charges and wallet entries connected to Nekt
- The fee and commission table with validity dates, including per-customer negotiated rates
- The list of internal, test and demo accounts

**What you get**

- A transactions table with volume, revenue by source, refunds and chargebacks
- Take rate by customer, product, payment method and month
- Volume drop alerts for the largest customers
- An AI agent that keeps volume and revenue apart in its answers

## Detailed

### The problem

The charge carries what the buyer paid, and it's easy to call that revenue. In a real case, a gross revenue field was just volume minus refunds and chargebacks, without removing the share that belongs to the customer, and it was practically equal to volume. Fees change over time and by customer, interest and advances live in separate tables, and the buyer's subscription status misleads about what was paid.

### Business rules

1. **Volume is always gross.** GMV or TPV is the gross amount paid by the buyer on approved transactions, including installment interest when the buyer pays it. Refunds, returns and chargebacks are separate events, with their own date, and don't reduce volume. That way a closed month's volume doesn't change when a refund arrives later. (Avoid: Netting refunds and returns out of volume.)
2. **Revenue comes from the platform's entries.** Platform revenue is what lands in the platform's account: the commission split entries in the platform wallet. When only the rate exists, revenue = the transaction's commission rate times volume, rounded per transaction. A ready-made gross revenue field must be tested against the entries before use. (Avoid: Using a gross revenue field without checking it, or calling volume revenue.)
3. **Revenue by source, each with its own date.** Separate commission (take rate or MDR, merchant discount rate), installment interest, advance fees, withdrawal fees and other fees. Commission and interest on the payment date, advances on the execution date, withdrawals on the completion date. Net revenue = sum of sources minus the platform's share of refunds and chargebacks. (Avoid: A single revenue column, with no idea where it comes from.)
4. **Paid uses the same criterion for volume and revenue.** Use a single paid-transaction criterion, the payment's approved status, for both volume and revenue. The buyer's subscription status (for example, active period) doesn't say whether that charge was paid, and using one criterion on each side kept volume and revenue from reconciling. (Avoid: Revenue by subscription status and volume by payment status.)
5. **Fees versioned by date and by customer.** Fees change over time and can be negotiated. Keep the table with validity (from, to) and each customer's negotiated plan by payment method: card, boleto (bank payment slip) and Pix, with a percentage and a fixed amount. Never apply today's fee to the past. Withdrawal fees only apply to completed withdrawals. (Avoid: Computing every month's revenue with the current fee.)
6. **A changed date rule is declared.** When an event's date rule changes, for example withdrawals dated by creation until one day and by completion afterwards, store the cutover date and apply each rule to its period. Recomputing everything with the new rule rewrites closed months. (Avoid: Switching the event date across all history.)
7. **The take rate base is the contract's.** Take rate is revenue / volume, and the right volume is the one the contract uses: sales attributed to the platform (by coupon, link or own channel), not all of the customer's sales. Tiered commission is progressive: each tier applies its rate only to the share of volume inside it. Validate against what the platform charged: in a real base, with the right base, the calculation matched almost 100%. (Avoid: Dividing revenue by all of the customer's sales.)
8. **Own channel separate from aggregators.** Platforms that receive orders from their own channels and from aggregators (delivery marketplaces, for example) show volume by channel, because revenue and value to the customer differ in each. An order with an unrealistic amount, above a declared cap, counts as zero in volume and goes to review. (Avoid: Summing every channel and accepting any order amount.)
9. **Currency converted at the monthly average.** Volume in several currencies is a flow: convert at the month's average rate, not the closing rate, from an official source such as treasury. Freeze closed months and record any missing rate manually, with a warning. (Avoid: Converting at the last day's rate or summing currencies.)
10. **Refunds and disputes from their own objects.** In Stripe Connect and similar gateways, refunds and disputes that happen after the load don't update the charge already loaded. Read refunds and disputes from their own objects and use the larger of the refunded amount there and on the charge. Production transactions only (livemode in Stripe). (Avoid: Trusting the charge's refunded amount field.)

### Where each piece of revenue comes from

Each source has its own table and date; none of them reduces volume.

- **commission on the sale** → Take rate or MDR (`platform split entry`)
- **interest paid by the buyer on installments** → Installment interest (`payment date`)
- **customer advanced receivables** → Advance fee (`execution date`)
- **customer withdrew the balance** → Withdrawal fee (`completed withdrawals only`)
- **refund or return** → Revenue reducer (`separate event`)
- **chargeback** → Reducer and risk (`dispute date`)

### Definitions

| Metric | Definition |
|---|---|
| GMV or TPV | sum of the amount paid by the buyer on approved transactions, including interest when charged to the buyer, by payment date |
| Platform gross revenue | sum of the platform's revenue sources (commission, interest, advances, fees), each by the date of its event |
| Net revenue | gross revenue - the platform's share of refunds, returns and chargebacks in the period |
| Take rate | commission revenue / volume of the contractual base, by customer and month |
| Effective take rate | total gross revenue / GMV, by customer and month |
| Chargeback rate | chargeback amount / GMV, by dispute date |
| Transacting customer | customer with at least one approved transaction in the month |

### Pitfalls

- **Gross revenue equal to volume.** A gross revenue field was volume minus chargebacks and refunds, without removing the customer's share. The amount came out almost equal to volume and skewed every dashboard that used it. How to avoid: Drop the field and read revenue from the commission entries.
- **Active period is not paid.** Revenue used the buyer's subscription status, and subscriptions in an active period came in as paid. Volume and revenue didn't reconcile. How to avoid: Use the payment status on both sides.
- **Today's fee applied to the past.** The withdrawal fee changed several times in a few years, and a calculation with the current fee rewrote revenue for older months. How to avoid: Fee table with validity, applied by the event date.
- **Wrong base in the take rate.** Take rate was computed over all of the customer's sales, not only those attributed to the platform, and the rate looked much lower than the contract. How to avoid: Use the contractual base and validate against what was charged.
- **Unrealistic orders in volume.** Test orders and mistyped amounts inflated the volume of small stores and skewed the ranking. How to avoid: A declared cap per order, with the excess sent to review.
- **House accounts in volume.** The company's own stores and demo accounts added volume and pulled the average take rate. How to avoid: List of internal and test accounts applied in the first layer.

### Acceptance test

- [ ] The month's commission revenue matches the sum of the platform's split entries (difference under 0.5%).
- [ ] A closed month's GMV doesn't change when a refund or chargeback arrives later.
- [ ] For a sample of customers, the computed take rate matches the rate of the plan in effect on each transaction's date.
- [ ] No internal, test or demo account appears in volume.
- [ ] Gross revenue = sum of sources, and net revenue = gross - reducers, for each customer and month.

### Context document

```text
Take rate and platform revenue
- GMV/TPV = gross amount paid by the buyer on approved transactions. Never call volume revenue.
- Refunds, returns and chargebacks are separate events. They don't reduce volume.
- Platform revenue comes from commission (split) entries in the platform wallet, plus interest, advances and fees, each on the date of its event.
- Paid = approved payment status, for volume and revenue. The buyer's subscription status doesn't say whether it was paid.
- Fees have validity dates and can be negotiated per customer. Use the fee in effect on the transaction date.
- Take rate = commission revenue / volume of the contractual base. Effective take rate = gross revenue / GMV. Say which one you are using.
- Withdrawal fees only on completed withdrawals.
- Currencies converted at the month's average rate. Reporting currency: <currency>.
- Internal, test and demo accounts are excluded.
Per-client exceptions:
- <client>: negotiated commission of <percentage>% on card and <amount> per boleto.
- <client>: take rate base = sales with the platform's coupon, not total sales.
```

### Variations

- **Sales outcome:** 30, 60 and 90-day cycles of volume and revenue from the customer's close, against the previous 30 days, to measure the sales team's real result.
- **Marketplace with payouts:** In Stripe Connect, build the ledger by balance movement: sale, payout to the seller, refund and dispute, each by its object type.
- **Volume as a health signal:** A drop in the customer's transaction volume goes into the health score before the subscription is canceled.