Overview
Every user has a ledger of the commission that's been approved, cancelled or historically paid against each period. Each time a calculation runs, the latest result is compared against that ledger. If there's a difference — more or less commission than the ledger currently reflects — an update is generated on the relevant statement.
Once an update is identified, Konquest tries to explain it by comparing the current calculation against the previous one and showing what's changed at the billing level. This comparison is the differential, and it's what underpins clawback and pay-when-paid functionality — both rely on the same underlying mechanism of comparing a new calculation against what's already on the ledger.
The three differential line types
When a differential can be shown, you'll see up to three types of line item:
- Green — added. A placement, timesheet or billing has been included in the calculation since the last one.
- Pink — removed. A placement, timesheet or billing has dropped out of the calculation since the last one.
- Yellow — changed value. A placement, timesheet or billing is still included, but its value is different between calculations. Yellow lines show the previous value struck through alongside the new value.
Pre-live vs. live accounts
The basis Konquest uses for a differential — what a calculation is being compared against — differs depending on whether an account is live.
- Pre-live: There are no approvals yet to compare against, so the differential is built against the last calculation that was logged for that period. If schemes are still being configured or changed during onboarding, a period can end up looking quite different from how it was last calculated — for example, a scheme change that adds a permanent-placement filter after June will show up as an update the next time June is calculated, even though nothing about June's actual billings has changed. This isn't a data problem; it's the system correctly showing "this is what's changed since the last time we calculated this period."
- Live: Once we're confident a period's calculations match what's actually been paid, we run a process that creates historic payments for it and moves the account into its live state. This clears existing updates and resets the basis to the calculations that produced those historic payments. From that point on, an update only appears when something genuinely changes — a billing is confirmed, reversed, or its value changes — not because of earlier scheme configuration.
If you see updates that don't correspond to a real change in the underlying billings, it's worth checking whether the account (or the scheme in question) is still pre-live.
Approved changes vs. changes since approval
Once a statement has been approved, any further updates that land within that same period are split into two sections, so you can tell what you already approved apart from what's happened since:
- Approved changes — what was included at the point of approval.
- Changes since approval — anything that's moved since, shown as its own differential.
When no differential is shown
Occasionally an update appears without a differential. This happens when there's no discernible difference between calculations at the billing level, but the value produced is different regardless. It's usually a sign of a scheme change rather than a change to the underlying billings — if you see this, it's worth checking whether the scheme configuration has been edited since the previous calculation.
Including, excluding and cancelling updates
Users aren't required to include an update in the current period:
- Uncheck it to leave it out of the current period and pick it up in a later one instead.
- Cancel it to add an offsetting amount to the ledger, which resets the basis for future updates on that period.
Why this happens
Konquest doesn't store a "status" for a statement directly — Draft, Approved, Overpaid and No Commission are all derived from comparing the latest calculation against the ledger, and updates work the same way. This is what allows clawbacks and pay-when-paid plans to work automatically: the same comparison that flags a routine update is also what catches a billing that's reversed after payment, or a payment that only just came through. The trade-off is that anything which shifts the basis of comparison — including scheme configuration changes on a pre-live account — can surface as an update, even when no actual billing has changed.
Need help?
If an update or differential doesn't look right, or you're not sure whether it reflects a genuine billing change or a scheme adjustment, get in touch with your Konquest support contact with the user, period and scheme involved, and we can talk through the calculation history behind it.