Orders, charges and wallet entries
Full volume, revenue from the platform's entries
GMV, revenue by source and take rate
Board, CS and volume alerts
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.
Business questions it answers
Ask your agent these questions once the case is live.
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
Where to activate
GMV, revenue by source and take rate for the month, with a bridge of the change across volume, customer mix and fees.
A Slack alert when the weekly volume of one of the largest customers drops beyond an agreed threshold.
Answers about volume and revenue without mixing them up, with the fee in effect in each period.
Revenue usually lives in the product, in wallet or split entries. The work is finding the right source for each piece and keeping fees versioned by date. The detailed view has the business rules, the pitfalls and the acceptance test. Or send everything straight to your agent with the Nekt MCP.
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.
How it is usually done, and the rule
Each row is a mistake that already happened in practice.
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.
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.
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.
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.
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.
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.
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%.
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.
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.
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).
Where each piece of revenue comes from
Each source has its own table and date; none of them reduces volume.
Definitions
Pitfalls that already happened
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.
Drop the field and read revenue from the commission entries.
Revenue used the buyer's subscription status, and subscriptions in an active period came in as paid. Volume and revenue didn't reconcile.
Use the payment status on both sides.
The withdrawal fee changed several times in a few years, and a calculation with the current fee rewrote revenue for older months.
Fee table with validity, applied by the event date.
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.
Use the contractual base and validate against what was charged.
Test orders and mistyped amounts inflated the volume of small stores and skewed the ranking.
A declared cap per order, with the excess sent to review.
The company's own stores and demo accounts added volume and pulled the average take rate.
List of internal and test accounts applied in the first layer.
Acceptance test
The case is done when every item passes.
- 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.
Agent package
Paste into Claude, ChatGPT or any client with the Nekt MCP connected.
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.
Build the "Take rate: transaction volume against platform revenue" case in my Nekt workspace following the rules at https://academy.nekt.com/en/industrias/saas/take-rate-marketplaces.md. 1) Find the source tables and confirm the columns the rules use. 2) Create a transformation at the stated grain applying every rule. 3) Run the acceptance test and show me the result of each item. 4) Create the case's context document in the workspace, leaving my clients' exceptions open for me to fill in.
Variations
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.
In Stripe Connect, build the ledger by balance movement: sale, payout to the seller, refund and dispute, each by its object type.
A drop in the customer's transaction volume goes into the health score before the subscription is canceled.