Every FMCG quarter ends the same way. The schemes closed weeks ago, but the money they promised is still in motion: the distributor's claim file — a spreadsheet of what they believe they earned, assembled from invoice copies and a sales officer's assurances — lands on channel finance, which holds its own spreadsheet of what it believes it owes. The two disagree, because they were always going to: they are independent reconstructions of the same transactions. The gap gets negotiated, the settlement gets rounded, the distributor books the difference as distrust, and the company books it as leakage nobody can locate. Trade claim management software exists to end the reconstruction, and xMatix ends it at the root: the claim is generated from the scheme accruals the transactions already wrote — so there is nothing to reconstruct, and nothing to fight about but genuine exceptions.
The accrual is written when the benefit is earned
The chain starts inside the scheme engine, not at quarter-end. When an order or invoice line qualifies for a scheme, the same evaluation that prices the benefit writes an accrual into the scheme's consumption ledger — one row per benefiting line, carrying the scheme, the partner, the document and the amount. Budget caps and apply-count limits are enforced against that ledger as it grows, and claimable schemes accrue at their own claimable percentage, so a scheme that settles 80% through claims and 20% on-invoice is stated that way from the first transaction. By the time the scheme closes, the question "what did this distributor earn" has been answered continuously for three months — line by line, against the ledger, not from anyone's memory. How the scheme side works end to end is covered in our trade schemes guide.
Claims are swept, not submitted
On the schedule the claim type declares — nightly, monthly, at scheme close — the claims engine sweeps the unconsumed accruals, groups them by distributor, branch and scheme, and writes one claim per group with the lines attached. Every line points at the accrual that produced it, and every accrual points at the invoice line that earned it, so any number on the claim walks back to a transaction in two steps. The sweep is idempotent: each claim carries a generation key for its type, group and period, a group that already produced a claim is skipped, and the accruals a claim consumed are flagged in the same transaction — a re-run after a failure creates nothing twice. Sale returns can be netted inside the same computation, so a distributor who returned stock against a qualifying invoice sees the deduction inside the claim's own arithmetic rather than as a surprise adjustment later.
Proven against the spreadsheet before it replaces the spreadsheet
No finance team should switch a payout process on faith. New claim configurations run in simulate mode: the full pipeline executes — rules, grouping, netting — and reports the claims it would have written, without creating anything. The team runs one quarter in parallel, compares the simulation to the spreadsheet process it is retiring, investigates the rows that differ (in our experience the spreadsheet loses that argument more often than the ledger), and activates the setup when they agree. Bad configuration surfaces even earlier: every setup save dry-runs the query against live data, so a broken filter fails at save time, not during the month-end run.
Decided line by line, settled into the distributor's ledger
Generated claims land in the approval queue with the scheme's budget consumption alongside. Decisions are per line — approved quantities, rejected quantities with reasons — and partial approval settles partially: a claim approved at 90% produces a 90% settlement, and the rejected tail stays visible with its reason instead of vanishing into a dispute. On approval, settlement runs automatically: a credit note built from the approved figures, linked back to the claim, and posted against the distributor's account in the same ledger that holds their invoices and outstanding. That posting matters more than it sounds: the moment a claim settles, the distributor's credit position changes, and the credit gate that blocks or releases their next order reads the new number. Scheme money stops being a side agreement and becomes working capital the collections view already understands.
Beyond schemes: the rest of the claims file
Scheme settlements are the volume, but the claims folder on a channel finance desk holds more lanes than one: quantity-purchase and slab rebates computed from the period's actual despatches; contract price differences, where a customer's negotiated rate diverges from the billed rate and the gap is owed back; cashback programmes; and the credits that follow sale returns. Each of these is a claim generation setup on the same engine — a different source, different rules, its own schedule — not a separate project, which is why adding one is a configuration exercise for an administrator rather than a quarter of development. The lanes that genuinely need human eyes — damage in transit, freight reimbursement — are raised manually and inherit the same lifecycle from that point on: the batching, the line-level approval, the settlement posting. Finance learns one claims process, and the run history of every type lands on one jobs screen. The engine itself, and the full set of claim types it carries, is described on the claims product page.
The distributor watches it happen
The status conversation is half the cost of a manual claims process — every area sales manager knows the call that begins "what happened to my claim". On the distributor portal, each partner sees their own accrued, claimable and already-claimed scheme money computed live from the same ledger the claims are generated from, and each claim's position — in approval, approved, settled, rejected with the reason — scoped by record security to exactly their records. The monthly distributor meeting starts from a shared statement instead of two grievance lists, which changes its subject from history to business.
What the CFO gets back
Turn the same records around and trade-spend leakage becomes measurable instead of proverbial: claim value by scheme, region and distributor against the budgets the schemes declared; the gap between accrued and claimed (money earned that nobody collected — a real number, per scheme); cycle time from scheme close to settlement; rejection rates and their reasons. Because every settlement is a posted credit note, channel programme cost is a ledger fact, auditable at year-end without a war room — and because generation, approval and settlement each leave a trail, the answer to "why did we pay this" is attached to the payment itself.
Common questions
How are trade claims generated from schemes?
Every invoice or order line that earns a scheme benefit writes an accrual into the scheme's consumption ledger as it posts. The claims engine sweeps those accruals on the claim type's schedule, groups them by distributor and scheme, and writes claims whose every line traces back to the accrual and the invoice line that earned it — no submission or re-keying step in between.
What stops a re-run from paying a claim twice?
Idempotent generation. Each claim carries a generation key built from its type, group and period; groups that already produced a claim are skipped on later runs, and consumed accruals are flagged in the same transaction that writes the claim. Settlement is idempotent the same way — a claim that already has its credit note is never settled again.
Can distributors see their claim status themselves?
Yes. On the portal each distributor sees their own claims and status — in approval, approved, settled, rejected with the reason — plus their accrued, claimable and already-claimed scheme money, computed from the same ledger the claims are generated from and scoped by record security to their own records.
How does a settled claim affect the distributor's credit?
Immediately. Settlement posts a credit note into the same ledger that holds the distributor's invoices and outstanding, so their net position updates the moment the claim settles — and the credit limit check on their next order reads that updated number.