Commissions

The problem#

Commission is the best example of a decision that looks like one field and is really a question about history. The rate will change sooner or later, and every order from before the change has to settle the way it settled then.

This chapter exists to show a pattern that recurs in several other places: a value used to calculate money must not be read from the current configuration.

Minimum version#

• One platform-wide rate, kept in configuration.
• The commission amount charged recorded on the order line at purchase time.
• The amount recorded together with the base it was calculated from, so it can be checked.
• A refund reduces commission in proportion to the value returned.

What not to build yet#

• A hierarchy of rules per category, product type and seller, while you have one rate.
• An interface for negotiating individual rates.
• Commission that varies over time, for example falling with turnover.
• A simulator showing what a seller would earn at different rates.

Plan ahead#

The result, not the rule#

The order should carry the amount charged, not a reference to the rule it came from. A reference to a rule means changing the rule changes the past. An amount recorded outright is immune to whatever happens to the configuration later.

Room for a second dimension#

Today there is one rate. Tomorrow a different one appears for a category or for a seller. If the commission charged sits on the line, adding a second dimension touches nothing historical. If it is computed on read, it touches everything.

Who funds the discount#

A discount given by the platform reduces platform revenue, not the seller revenue. A seller discount reduces theirs. If the model does not tell them apart, every promotion becomes an argument about who paid for it.

Triggers#

• the first rate change;
• the first seller with a negotiated different rate;
• the first category that needs a different rate;
• the first promotion funded by the platform;
• a seller disputes the size of a deduction.

Next stage#

After the first trigger: nothing, if the amounts are persisted. That is the whole point of this chapter. After the second and third: rules with a defined precedence, from most specific to most general. After the fifth: showing the seller a breakdown, which is cheap if the calculation base was recorded.

Common mistakes#

What works in practice#

Commission on my side is charged on the order line and stays there, together with the base it was calculated from. Because of that, rate changes, adding specific rules and introducing platform-funded discounts never once required touching historical data.

Distinguishing who funds a reduction turned out to be needed sooner than I expected. From a seller point of view a loyalty programme and a welcome discount are the same question, why did I get less, and without an explicit record the answer has to be reconstructed.

Checklist#

• The commission amount charged is recorded on the order line.
• The calculation base is recorded alongside the amount.
• It is recorded whether the calculation used the value before or after a discount.
• A partial refund reduces commission proportionally.
• It is clear who funds each discount.
• A rate change touches no order from before the change.