Rebates and year-end bonuses: what software must compute

Search for what a rebate is and you will find fifty pages of accounting entries. Useful, once. What none of them tell you is the thing that actually decides whether your rebate campaign takes three days or three weeks: which mechanics the software has to model, and which of them a generic package quietly refuses to handle.

The distinction, and then let us move on

French practice uses two acronyms for the same family of deferred discounts. RFA — remise de fin d'année — is the term the accounting and supplier side uses: a discount granted after the fact, based on the volume achieved over a period. BFA — bonification de fin d'année — is what most buying groups call the share of that discount passed back to their members. Ristourne is the generic word for both. The accounting treatment differs, the negotiating position differs, and your auditor cares about which is which.

From a software standpoint, the distinction changes almost nothing. In all three cases you have a base, a scale, a period, a beneficiary and someone who will check the figure. What decides whether a system works is not the vocabulary — it is whether it can express your mechanics without you rewriting them. The rest of this article is only about that.

Tiered scales, and the question that changes everything

Every scale has tiers. The structural question, and the one most often left implicit in the agreement itself, is whether the rate applies to the tier or to the entire volume once the threshold is crossed.

Take a scale at 0 % up to €500,000, 2 % from €500,000 to €1m, and 3 % beyond. A member declaring €1.2m earns €16,000 under a per-tier reading: nothing on the first slice, €10,000 on the second, €6,000 on the last. Under a whole-volume reading, the same member earns €36,000 — the full 3 % applied to €1.2m. Same scale, same declaration, more than double the amount.

Both readings exist in real agreements, sometimes within the same group, sometimes within the same supplier's contract for different product families. A tool that only knows one of them forces you to compute the other by hand, which is exactly how untraceable adjustments enter the process. Alongside that choice, the engine also needs a trigger threshold below which nothing is due, an optional cap, and an explicit rounding rule — the one that decides, at the fifth decimal, whether sixty members each receive an amount that matches their own spreadsheet.

The base is the real subject

Arguments about rebates are almost never arguments about the rate. They are arguments about what the rate applies to. A serious engine lets several bases coexist, and records which one was used for each computed line:

• Revenue declared by the member, the base on which the group's own bonus scheme usually runs.
• Revenue invoiced by the supplier, the base the supplier will defend, and rarely the same figure.
• Volumes in units — tonnes, pallets, machines — for scales that ignore price entirely.
• Revenue restricted to a family, a brand or a range, because a single supplier agreement often contains three different perimeters.
• Revenue net of on-invoice discounts, net of transport, or net of environmental levies, depending on what the agreement says and, more often, on what it does not say.

Two more things break here. Credit notes and returns, which have to reduce the base of the period they belong to rather than the period they arrive in. And the year-end cut-off: an invoice dated 29 December and received on 6 January belongs to one campaign or the other, and the engine must apply the same answer every year without anyone having to remember it.

Conditional premiums are not discounts

Growth bonuses, logistics premiums, early-payment premiums, premiums for taking part in a commercial campaign: these are not scales, they are conditions evaluated at a date. They fail differently, and they need to be modelled differently.

A growth bonus against the previous year raises a question nobody thinks to ask until the first dispute: growth against which previous year — the one actually recorded, or the one restated to a constant perimeter after a member acquired a competitor? A logistics premium conditioned on full pallets requires data your declaration form probably does not collect. And an early-payment premium depends on a payment date the group does not always hold.

Pro-rata and the split between group and member

Members join in April and leave in September. Approval agreements are signed mid-campaign. A pro-rata temporis rule handles this, but it hides a decision: is the pro-rata applied to the amount, or to the threshold? A member joining in July with €400,000 declared either misses a €500,000 threshold and receives nothing, or clears a pro-rated €250,000 threshold and receives a full tier. Both are legitimate policies. Only one is yours, and it needs to be written down before it is coded.

Then comes the split. The rebate collected from the supplier is not the bonus paid to the member: the group retains a share to fund its own operation, and that share is rarely a single percentage. It varies by supplier, sometimes by product family, sometimes by member seniority, and it changes at general meetings. The allocation key is a rule in its own right, with its own history, and it deserves the same traceability as the scale itself.

Versioned scales, traceable adjustments

A scale is not a setting. It is a dated object with a validity period, and an amendment signed in June does not modify the existing scale — it creates a new vintage that applies from its effective date. Systems that treat scales as editable settings lose the ability to explain any past amount, because the values that produced it no longer exist anywhere. This single design decision separates a rebate engine from a spreadsheet with a login screen.

The same applies to manual adjustments. The edge case no rule covers will always exist — a commercial gesture, a disputed line settled by negotiation, a member compensated for a data error. It has to be enterable, and it has to be an object: author, date, reason, original computed amount, retained amount. What must never exist is the ability to overwrite a computed figure in place. The moment that is possible, the audit trail is decorative.

The only acceptance criterion worth having

There is one test that settles the matter: take last year's complete campaign, feed the same declarations into the new engine, and compare the output line by line with what was actually paid. Same amounts, to the euro, for every member and every supplier. Nothing else demonstrates that the engine holds.

It is a demanding test, and it almost never passes on the first run. That is the point. The gaps it exposes are rarely development errors — they are rules applied by hand, year after year, that nobody had written down. On the platform we delivered for a Lyon-based group of more than sixty member companies, that comparison was the acceptance mechanism itself, and each divergence was investigated until it was either explained or corrected. Finding those rules during acceptance costs a few days. Finding them during a live campaign costs the members' confidence, which does not come back in the same financial year.

Which leads to the position worth defending: a rebate engine is not judged on its arithmetic. Computing a percentage is trivial, and every tool on the market does it correctly. It is judged on its ability to justify an amount, months later, to someone who is convinced it is wrong. A system that produces the right figure but cannot show where it came from has not solved your problem — it has moved it into a place where nobody can reach it.