Your contracts are not complicated.Paying them by hand is.

From the contract, not retyped

Rates, conditions and effective dates read off the signed agreement and turned into rows, with the source document kept against them.

• Annexures, rate cards and amendments read in one pipeline
• Every row traceable back to the clause it came from
• Effective dates carried, so a rate change does not overwrite history

Before it goes live

The sheet is checked for the faults that quietly double or halve a payout: gaps, overlaps, duplicates and conditions that can never be met.

• Duplicate rows, and rows that differ only in the rate
• Bands that leave a gap, or overlap so two rates both apply
• Conditions no partner can satisfy, flagged rather than paid

Rates change, history should not

Each version is dated. A rate backdated to January recomputes the periods it touches, instead of silently changing what was paid.

• Retrospective changes recompute the periods they touch
• The difference lands as arrears or a recovery, with the reason
• What was paid under the old rate stays visible

From your systems, not a summary

Units, trips, shipments, disbursals, policies or hours taken from the transaction record itself, at the grain the scheme is written at.

• Counted at the grain the scheme uses, not rolled up first
• Cancellations, returns and reversals removed from the count
• The same unit never counted under two territories

What actually counts

Not every unit qualifies. Exclusions in the contract are applied to the measure before any rate is chosen.

• Excluded categories, customers and channels removed
• Attendance and activity thresholds evaluated per partner
• Disputed and cancelled units held out until they settle

Against the source of truth

The measure is agreed against the operating system before payout, so nobody is arguing about the count afterwards.

• Volume agreed against the operating system, not the payout sheet
• Differences listed by partner and period, with the records behind them
• The agreed count frozen once the period closes

The straightforward half

A rate per day, per unit or per period, applied to the qualified measure. This part is rarely where money is lost, and it is where most tools stop.

• Per unit, per day, per trip, per policy or per period
• Multiple rates in one period, each with its own window
• Currency and rounding handled at the rate, not at the total

As your contract defines them

A band pays either on the whole volume or only on the units inside it. We do not impose a convention, because contracts genuinely differ.

• Whole-volume or marginal, set per scheme rather than globally
• Retrospective tiers that reprice earlier volume when a band is hit
• The band that was applied shown next to the one below it

Floors, cliffs and one-offs

A guarantee is a floor evaluated over a period, not a rate. An incentive often has a cliff: one unit short and the whole component is zero.

• Guarantee compared against the computed total, then topped up
• Cliffs shown as a distance to the threshold, before the period ends
• Seasonal and campaign incentives applied only inside their window

Decided once, applied every time

The order in which schemes resolve is configured with you and then applied identically to every partner and every period.

• Stack, best-of, or absorb, set per pair of schemes
• The same rule applied to every partner, with no local exceptions
• A change of rule recomputes rather than applying from now on

One unit, one payment

The same volume paid under two overlapping schemes is one of the largest and quietest leaks in any payout run.

• Every unit tagged with the scheme that paid for it
• Units claimed by two schemes surfaced before payment
• Overlapping territories and categories resolved explicitly

Not just the answer

For every partner and period, the computation is retained: which rows applied, in what order, against what measure.

• Every payout traceable to the rows that produced it
• The rejected alternatives kept alongside the applied one
• A dispute answered from the record rather than rebuilt

Netted, with a reason

Advances, equipment, damages, shortages and penalties netted against the payout, each carrying the event that caused it.

• Advances recovered on the schedule that was agreed
• Damages and shortages linked to the incident record
• Nothing deducted without a reference the partner can check

At the right rate, per class

Tax withheld according to the partner class and the applicable rate, with certificates produced rather than requested later.

• Rate driven by partner class and registration status
• Certificates generated with the payout, not at year end
• Thresholds tracked across the year rather than per payment

Ready to run

The bank file and the accounting entry come from one computation, so the books and the bank cannot disagree.

• One computation behind the payment file and the journal
• Entity, cost centre and account determined from the scheme
• Failed and returned payments traced back to the payout line

Live, not at month end

Volume so far, the band it currently falls in, and what has accrued. Visible during the period, when the partner can still act on it.

• Running volume and accrued payout, updated as data arrives
• The current band and the distance to the next one
• Attendance and qualifying thresholds shown against the target

Workings included

Every payout line with the scheme, the rate, the measure and the deductions that produced it. The same view your team sees.

• Gross, deductions and net, each with the rows behind them
• Downloadable statement per period, per partner
• Withholding certificates attached to the period they cover

Not in an inbox

A partner disputes a line rather than an amount, your team answers against the record, and the exchange stays attached to the payout.

• Disputes raised against a specific line, not a total
• The evidence already attached when the query opens
• Resolution recorded against the period it affects