How a rebate calculation runs¶

A rebate calculation takes every rebate element on a deal that is flagged to calculate, works out each member's rebateable turnover for each period, and produces one payment line per element, per member, per period. It is the process behind the figures shown on the rebate views and dashboards.

Calculations run in the background: starting one shows a progress bar (named for the element and period currently being processed) and sends a notification when it finishes. Starting a new calculation for a deal cancels any calculation already running for that same deal. Currently running calculations for all deals are visible in the calculation jobs list.

Live, projection, and simulation runs¶

Live calculation — uses actual entered turnover. Results become the deal's rebate payment lines. When a live calculation finishes, a projection run starts automatically so estimated (on-target) figures stay in step with actuals.
Projection — the same engine run against projected turnover. Results are stored separately and update the estimated (OTE — on-target earnings) values shown alongside actuals.
Simulation — a what-if run: a total turnover amount is spread across the deal's months and members, and the engine calculates what rebate that would produce. Simulation results are kept in temporary tables and never touch real payment lines. The output can be rendered as a "Simulation Output" PDF document stored against the deal under Rebate Simulations.

What a calculation preserves¶

Recalculating does not wipe payment history. Where a payment line already exists for the same element, member, and period, the line is updated in place — turnover, rebate values, and payable amounts are refreshed but the line's identity and paid status are kept. Deleting rebate lines is a separate, explicit action on the deal's rebate tab.

Why do rebate figures change unexpectedly?¶

New turnover arrived. Any run after new figures are entered picks them up — including the automatic projection run after a live calculation.
The element's period isn't what you assumed. Elements calculate in period blocks (monthly, quarterly, annual, and so on). A figure landing in a different period block moves the rebate between periods rather than changing the total.
A band boundary was crossed. On stepped rebates, turnover crossing into the next band changes the rate applied — retrospectively to all turnover unless the element is non-retrospective.
A modifier is in play. Compound elements are reduced by what another element already paid; strung elements earn on turnover net of another element's rebate; catch-up elements re-measure cumulative turnover every period. See the rebate types and banding reference.
The projection window moved. Estimated values refresh on every projection run as the last-figures date advances.

Every run writes a calculation log for the deal — a per-element, per-period, per-member trail of the turnover found, the band chosen, and each adjustment applied, in plain language. When a figure looks wrong, read the log entry for that element and period before assuming the data is bad.

What a rebate calculation is not¶

It is not automatic on turnover entry — someone (or a scheduled process) must run the calculation for the deal.
It is not a payment — it produces payable amounts; recording money received or paid out is a separate step on the rebate payment views.
It is not scoped to one member — a run always recalculates every participating member of the deal.