Channel partner settlement: a practical guide
Earn/burn ratios, dated rate history, settlement batches, pool balances, and compensation documents — what each one is for, and the ordering that prevents reconciliation pain.
Partner programs grow fast and reconcile slowly. The math gets complicated the moment two partners issue points that members can spend at a third — and it gets unrecoverable the moment rates change mid-cycle. Here is the operating model that scales.
Define each partner with a code and exclusions
Every partner gets a stable code (e.g., PREM_RESELL) and contact details. Industry / location exclusions prevent self-redemption loops — points earned at one partner cannot be redeemed at another whose channels match the exclusion. This single configuration prevents the most common abuse pattern.
Set earn and burn ratios with dates
Each partner has its own earn point ratio and burn point ratio, both versioned. Every rate change carries a start date and an end date. When a rate flips mid-month, the ledger uses the rate that was effective on the transaction date, not on the settlement date. No retroactive arguments.
Roll up activity into settlement batches
A settlement batch is a snapshot of partner activity over a period — the points earned, redeemed, and the resulting net liability. Batches are immutable once finalized. Pool balances track the running liability between settlements.
Generate compensation documents
For each batch, generate a partner-statement document on a recurring cadence (weekly, monthly, custom). The statement should reconcile to the cent, sign the partner-side balance, and be exportable as PDF or CSV — finance teams will not accept anything less.
Anti-fraud is a partner concern, not a member concern
Bulk discount codes need POS / branch restrictions, attempt tracking, and signal logging. The platform should distinguish between a member fat-fingering a code and a script enumerating codes — and act differently.