How to Keep Marketplace Commission Rates Right for Every Seller

Commission rate drift on a marketplace is the gap between the rate your system charges and the rate in the document your sellers signed, and because both artifacts are yours, no bank statement and no payment report will ever tell you it opened.

You have two commission rates for the same seller: one is charged by the system, the other sits in the document you signed. Until somebody puts them side by side, both are true.

This article breaks down:

• Why does nobody report a rate drift?
• Which 5 places do rates drift in?
• How do you detect a drift?
• What do you do with one already charged?

Key insights

• Nobody reports a rate drift because both artifacts are yours: your bank has never read your terms, so a reconciliation of amounts ties out to the cent while the rate those amounts were calculated from is wrong.
• Rates drift in five places: a typo at entry, a change in the system with no change to the document, the same change the other way round, an exception granted over email, and a category inheriting the default rate from an import.
• You detect a drift by comparing the charge rather than the configuration: divide the commission by the base per seller, category and period, and set the effective rate against the table in force on the day the order was created.
• A drift already charged is money to give back rather than to explain: a quarter of a point across 12 sellers over seven months is €42,000, and unwinding it is 84 correcting documents rather than one transfer.

Why does no third party report a rate drift?

Every other financial control in a marketplace compares your system against somebody else's. Reconciling the money sets your book against the bank statement and the payment provider's report.

The other side has its own record and its own interest in explaining the difference. The ledger (the ledger behind a balance) checks itself.

This one control is different: it compares your system against your own commercial promise. On one side sits the configuration the commission is calculated from.

On the other sits the rate table in the document the seller accepted before they posted their first offer. Both artifacts are yours, both edited by your company, and no third party will report that they have drifted apart.

Your bank has not read your terms, and your payment provider does not know how much you were entitled to charge. A reconciliation of amounts ties out to the cent even when the rate is wrong, because it checks whether the money arrived rather than whether you were allowed to take it.

That is why the gap between those two numbers is a claim rather than a technical defect.

A defect waits to be fixed. A claim grows: every order charged at the wrong rate adds an amount to it, and the catalog does not stop selling.

The line is sharp, though it is easy to smudge. Payment reconciliation reconciles an amount against a bank statement.

This article reconciles a parameter against a document. Those are two different processes, with a different cadence, a different owner, and a different piece of evidence.

What does a quarter of a percentage point cost in seven months?

The canonical case of this series: a €1,000 cart, a commission of 12%, and €880 left for the seller. Suppose the document you published to sellers says 11.75% for this category, while the system holds 12%.

The gap is a quarter of a percentage point. Nobody is going to spot a number that size on an invoice.

• Commission per the system: 1,000 × 12% = €120.00, and the seller keeps €880.00.
• Commission per the document: 1,000 × 11.75% = €117.50, and the seller keeps €882.50.
• The difference on a single cart: €2.50.

Scale turns that into a financial position. The category has 12 active sellers, each with 200 orders a month at €1,000, which is €2,400,000 of turnover a month.

A quarter of a point on that base is €6,000 a month (€2.50 × 200 × 12 gives the same figure). The drift was created when the category was loaded and ran for seven months: €42,000.

That is €42,000 to give back rather than to explain. The difference between those two sentences is the entire content of this article.

It is also the one thing worth repeating to your board.

Which 5 places do commission rates drift in?

1. A typo at data entry

Rates are assigned to categories by hand, and there can be thousands of them.

Practitioners at large platforms admit their own slips here: 5.5 instead of 5.25 looks correct on screen, because both numbers are plausible. The most common source, and the hardest to catch by eye.

2. A change in the system with no change to the document

Somebody with the right permissions raises the rate in a category, because that is what was agreed at a sales meeting.

The configuration now matches the decision and no longer matches the document. The rules on decisions about sellers cover the mode and notice for changing terms.

What counts here is that two truths now exist in your data.

3. A change to the document with no change in the system

The reverse case, and more common than people expect: the new rate table is published, and nobody touched the configuration, because the document is written by a different department than the one clicking through the panel.

4. An exception granted over email

A seller gets six months at half the rate: 6% instead of 12%.

The promotional grid goes in, and its expiry date lives in a spreadsheet or in somebody's memory. At 200 orders a month, three months of delay in switching it off is €36,000 of commission never charged, on a single seller (200 × €60 × 3).

This drift is created by the passage of time, with nobody taking any action. It appears in neither of the two artifacts, because the third artifact is an email thread.

5. Migration and price list import

You load the grid from a file, or carry it from a previous system.

The usual construction sets a default rate at the top of the category tree and overrides it further down. A category added later, which nobody overrode, inherits the default rate: 15% instead of the 8% in the document.

The configuration is then formally correct. Nobody broke anything, and nobody entered anything either.

Which artifact is the source of truth for a rate?

The reflex answer is "the system, because that is where the charge happens." That answer fails. The system carries out an obligation.

It does not set the content of that obligation. The content was set by the document, and the seller used it to work out their margin and decide to come in.

The document on its own is not enough either, because you cannot calculate from it: it carries no caps, no ordering of rules, and no mapping onto the categories in your tree. The practical answer: one rate registry, and both artifacts are generated from it (the configuration and the table for sellers).

Drift then cannot happen. There is nothing left to detect.

The principle that every piece of data has one place where it is edited, with everything else derived from it, is a standard pattern in data architecture. The reason is exactly this: copies maintained independently drift apart over time, and not through anybody's fault.

Until you have that, you need a comparison control. Almost nobody has it at the start.

The control does not replace a single source of truth. It buys time: it shortens the window between a drift appearing and its discovery from "never" to "one cycle."

What does each drift cost on the same cart?

The last column carries a warning that no feature list will give you. Your seller is a one-directional sensor.

They will report every drift that costs them money, and they will report none of the ones that pay them. A control that runs only after a complaint therefore finds half the cases by definition, and the other half is revenue that never existed.

How do you detect a rate drift?

The most common design mistake here is comparing the configuration screen against the table in the document. That is not enough: the configuration can be correct and the commission still calculated from a different rule.

It may come from an individual grid, a brand rule, a cap, or an exception.

Compare the rate that was charged. You take the orders from the period, divide the commission amount by the base, and get the effective rate.

The grain: seller × category × period. You set the result against the table in force when the order was created.

Two things have to be settled up front so the control does not drown in noise. It is the same lesson as in reconciling amounts.

A cap counts as no drift. A €10,000 bicycle at 12% with a maximum commission of €300 gives an effective rate of 3%, and that is correct.

A control that knows nothing about caps will flag every line like that. Rounding counts as no drift either: set a tolerance in cents and never come back to it.

The cadence has three triggers rather than one. On every publication of a new version of the document.

On every launch of a new category and on every import of a grid. Plus a standing monthly cycle, for whatever nobody reported.

The cheapest moment is the day of the upload, when the drift has zero charges behind it.

The control is run by somebody other than the person who enters the rates. This is a built-in limitation rather than a question of trust: a human reads their own typo as what they meant to write.

Separating whoever makes a change from whoever approves it is a classic principle of internal control, and it catches mistakes and abuse in the same pass. In a small team it is enough that the account manager enters the rate while finance runs the comparison, as long as the check leaves a trace with a date and a name.

What do you do with a drift you have already charged?

Three decisions, always in this order.

Which side binds. The default answer is the document, because it was the basis of the seller's commercial decision.

The ruling itself belongs to your lawyer and to what your contract says (the documents you sign with a seller). Your own job is narrower and independent of that: you have to be able to show which version of the document was in force on the day the order was created.

Without that, the dispute cannot be settled, whoever happens to be right.

The correction goes backward. Market practice here follows from a rule you are not allowed to break: an order that has already been settled is never recalculated.

Our €42,000 is not one transfer: with a monthly commission invoice it is 12 sellers × 7 periods = 84 correcting documents, averaging €500 each. The cost of unwinding is measured in documents rather than in the amount.

How to post them and which period they belong to is the subject of corrections and credit notes and the ledger behind a balance.

The correction forward. Here is a distinction worth having ready for the committee: bringing the system down to the document falls short of a change of terms.

Bringing the document up to the system always is. In the first case, you go back to what the seller accepted.

In the second, you are changing their terms, and you enter the mode, the notice period, and the delivery covered by the rules on decisions about sellers, even if in your own eyes you are only "fixing a mistake."

What does rate drift change about the rest of your build?

1. Every element of the grid is one more pair to compare

Thresholds, caps, per-brand rates, individual exceptions. Building the grid (how much commission you can charge) and constructing exceptions (thresholds, caps and negotiated rates) have their commercial justifications, and every element multiplies the number of comparisons.

2. Commission on a refund is given back at some rate

If it is given back at the current rate rather than the rate from the moment of sale, the drift comes back after the period closes (the commission on a refunded order). What you calculate the base from in the first place is settled by split payments and who pays the fees.

3. Commission you overcharged is already sitting in your results

It has been recognized as revenue ("Marketplace Revenue Recognition: Do You Book the Commission or the GMV?"), so giving it back is a correction rather than a reduction of a cost to what you showed your board.

How do you check for rate drift with a vendor?

Five questions for the demo.

1. "Show me an order and tell me which rule this rate came from." If the system cannot point to the rule, a comparison control cannot be built. You do not know what you are comparing.
2. "Is the charged rate stored on the order, or recalculated from the current configuration?" The second answer means history rewrites itself every time you change the grid.
3. "How do we export the full grid in a form we can set against the table from the document?" If the export is a PDF or a screenshot, the control will be manual, and after three months it will stop happening.
4. "Who can change a rate, and where do we see who changed it and when?"
5. "What happens to a promotional rate on the day its term runs out?" The answer "somebody has to switch it off" means the term is not in the system.

Three questions for yourself, more important than the five above.

1. Who, by name, owns the document with the rates, and is that the same person who enters them into the system?
2. How many versions of that document have we published, and can we produce the one from March 14? Where do the exceptions granted over email physically live?
3. Does anybody know their expiry dates?

Which mistakes do operators make about commission rates?

1. A control that runs only after a complaint

It finds only the drifts that work against the seller, because those are the only ones with somebody to report them. The rest stay.

2. Comparing the configuration instead of the charges

The settings screen can agree with the document while the commission is still calculated from an individual grid or an exception.

3. The same person enters the rates and checks them

The cheapest control to put in place, and the only one that does not work.

4. An exception that lives only in an email

It binds you commercially and is absent from both artifacts. A control that works properly will flag it as an error, and somebody will switch the control off, because "we agreed that one."

5. Fixing the rate without settling what happens to the period already charged

The drift disappears from the screen and stays in the books.

What do you still have to settle about your own rates?

This article does not settle which side of a drift binds legally, or whether the seller is entitled to be paid back for a period in the past. That depends on what your contract says and on how you described the precedence of documents.

Walk it through with a lawyer before you fix the rule in the system (the documents you sign with a seller and the rules on decisions about sellers). Two more items belong on the same list.

Does differentiating rates between competing sellers create a competition law risk in your case? And where a reduced rate is in practice an exchange for better exposure, does that trigger a duty to disclose how fees influence ranking (the rules on decisions about sellers and price history and discount messages)?

Our claim is narrow and independent of everything above: if nobody in your company sets the charged rates against the published document on a fixed rhythm, you do not know how much you owe your sellers. You will find out from them.

Summary: How do you know the rate you charge is the rate you agreed?

Only by setting one against the other on a fixed rhythm, because this is the single financial control in a marketplace with no third party on the other side. Reconciling money compares your book with a bank that keeps its own record.

Reconciling a rate compares your configuration with your own commercial promise, and both documents are edited inside your company. So the gap grows quietly: a quarter of a percentage point on a category doing €2.4 million a month is €6,000 a month, and seven months of it is €42,000 you owe rather than €42,000 to explain.

Your sellers are a one-directional sensor here. They will report every drift that costs them money and none of the ones that pay them, so a control that runs on complaints finds half the cases by construction.

Ask a vendor to show you an order and name the rule its rate came from, and whether the charged rate is stored or recalculated. Building a marketplace where one rate registry generates both the configuration and the seller's table?

Talk to us about the build.

Frequently asked questions on commission rate drift

What is commission rate drift?

Commission rate drift is the gap between the rate your system charges and the rate in the document your sellers accepted. It opens through a typo, a one-sided change, an exception agreed over email, or a category inheriting a default rate on import, and it grows with every order until somebody compares the two.

Who is the source of truth for a commission rate?

The document is the source of truth, because the seller used it to work out their margin, and the system carries that obligation out. The practical answer is one rate registry that generates both artifacts.

Until you have it, a comparison control buys time: it shortens the window between a drift appearing and being found from never to one cycle.

How often should you check commission rates?

Commission rates should be checked on three triggers plus a standing monthly cycle: every new version of the seller document, every new category, and every grid import. The cheapest moment is the day of the upload, when the drift has no charges behind it.

Whoever runs the comparison has to be somebody other than the person who entered the rates.