How to reproduce a platform realized fee from its deductions

Rebuilding a platform fee is an exercise in matching records, not choosing an application. The example values below are invented. Begin with the cash that settled, then trace back through the fee rule and every deduction until each amount points to the same transaction.

What exactly am I calculating?

Calculate the realized rate by subtracting all deductions from the posted fee, then dividing the amount kept by the value that flowed through the platform. Realized rate is reliable only when the fee schedule, transaction ledger, and deductions identify the same transaction, and can be compared with settled cash.

How much can deductions change the headline?

In the invented monthly example, a 15.0-point fee becomes 9.0 points after four deductions, retaining 60% of the headline or 180,000 from 2,000,000 in value. The table separates each deduction's rate effect from its monthly amount so the arithmetic can be checked line by line.

The posted fee is a gross figure, not the amount kept after costs. The SEC describes an income statement top line as gross because expenses have not yet been deducted; use that distinction when checking the platform report against its financial statement explanation.

What steps reproduce the rate for a quarter?

Use the same arithmetic on last quarter, segment by segment, and stop at the first calculation you cannot complete. Every subtraction should be supported by a record tied to the transaction; the unfinished step identifies the missing evidence instead of inviting an estimate.

Here the example leaves 180,000, but your reconciliation must use the amount supported by records. Compare that amount with cash settled, then investigate the first difference rather than adjusting the posted fee to make the report agree without an explanation.

Why are these amounts stored separately?

The deductions originate in separate team workflows, so their source records answer different questions and may not join automatically. A report can be correct within one system yet still fail to connect credits, seller rebates, payment costs, and refunds to the fee schedule for each transaction.

Payment costs can include the debit card interchange fee. The Federal Reserve's Regulation II sets standards for whether a debit card interchange fee is reasonable and proportional to the issuer's costs; that supports recording this cost per transaction rather than inserting a monthly estimate.

How can I see which side or cohort loses the most?

Break realized against posted by side, category, and cohort; a blended rate hides which segment absorbs the greatest deductions. Tag those fields from the first transaction, then identify the weakest deduction step within each category. The required output is a number that can be split without changing the transaction identity.

Marketplace teams can compare their definitions with marketplace metrics, but this calculation still depends on the transaction-level join. Ask for realized against posted separately by segment, then trace the deduction that explains the largest gap before changing the fee or policy.

Can a spreadsheet handle the reconciliation?

Yes, a spreadsheet can be trustworthy when one owner controls definitions, a full ledger rebuild takes minutes rather than hours, and fee changes do not create two active rule versions during the quarter. It is a sensible starting point if those conditions hold.

Once the spreadsheet cannot rebuild quickly or protect the rule from competing edits, software categories mainly differ by cost driver; none supplies the join automatically. Run the export test before purchase, and use marketplace-system records to judge what a marketplace export must retain.

What should be recorded before launch?

Before launch, define each deduction category and owner, store fee tiers and exceptions as data, and preserve every rate change with its before and after values. Run the export test on day one while the file is still small, so retrieval can be checked before the records grow.

Adding categories after credits or refunds begin requires backfilling. Backfilled deduction data is guessed data, even when it appears in a confident and consistent format; avoid treating the tidy appearance of a rebuilt file as evidence that the original transaction-level record existed.

How much past data do I need?

Keep enough history to include a full participant cycle and the most recent fee change. A shorter window cannot separate a seasonal movement from the effect of that change, so it cannot support the same comparison in the realized rate.

Are transaction records in the product database enough?

Product database records establish volume, but not money by themselves. The calculation also needs the fee and each deduction settled against the same transaction, then a comparison with settled cash rather than a monthly total alone for each line before the rate is trusted.

Does reconciliation decide whether the fee is right?

No. A reconciliation establishes the realized rate, not which side should pay, what platform rules should require, or whether a fee increase is defensible.

Those questions belong to pricing architecture; if the measured shape or cost base looks wrong, move to model innovation or unit economics, then revisit platform fee choices.

Should I buy or build the reconciliation?

Buy generic tools and build only the join, because the join depends on how your deductions arose. A purchased join may still need rebuilding; buying does not remove the need to agree definitions, test exports, and make each deduction traceable to the transaction that generated it.

What should I do first?

Start with one recent quarter and the first failed join, not a dashboard purchase. Confirm the arithmetic by segment, trace each deduction to its owner and source record, and compare the remaining amount with settled cash before expanding the process or changing the fee.