Trade schemes are where distribution margins go to hide. A slab discount misapplied at the counter, a free-goods scheme calculated three different ways by three different reps, scheme spend that nobody can tie back to claims — every one of them is real money, leaking quietly. The fix is not more vigilance; it is schemes defined once and computed by the system, identically, in every order — the discipline described in trade scheme management.
Define once, apply everywhere
In xMatix Rewards, a scheme is a governed definition — eligibility (who, where, which products), mechanics (quantity slabs, value slabs, free goods, percentage or absolute discounts), stacking rules and validity windows. The same definition prices the order in the rep's offline order pad, the B2B commerce portal, and the back office. There is no "field version" of the scheme.
The server recomputes — always
Devices apply schemes so the counter conversation is honest, but the server recomputes every order on sync and remains the authority. A stale scheme on a device, a manually edited line, a clever workaround — all get re-priced against the governed definition. Discount groups price by relationship, so an outlet's negotiated terms and the running scheme compose predictably instead of compounding accidentally.
Spend that becomes a claim, automatically
Every scheme application is a ledger fact: which order, which outlet, which scheme, how much. Scheme spend accrues as it happens, so the question "what did this promotion cost, and where?" has a running answer. When the scheme is distributor-funded or company-reimbursed, the accrued spend becomes a claimable settlement with line-level evidence — the claim writes itself from the orders, instead of being reconstructed from memory at quarter end and disputed for two more. The full settlement chain — sweep, netting, line-level approval, credit note — is covered under trade claims.
Did the scheme work?
Because schemes, orders and outlets share one data model, promotion effectiveness is a query, not a project: uptake by beat, incremental volume against the scheme window, spend per incremental case — alongside collections and secondary sales on the same dashboards. Ask Sense which schemes moved volume and which merely moved margin.
Common questions
What kinds of trade schemes can be modelled?
Quantity and value slabs, free goods (same product or different), percentage and absolute discounts, and combinations — each with eligibility by customer segment, geography or product set, validity windows, and rules about how schemes stack with negotiated discount groups. The point is less any single mechanic than that all of them live in one governed definition.
How do schemes stay correct in offline orders?
Active scheme definitions sync to the device with the catalogue and pricing, so the rep's order applies them at the counter. On sync, the server recomputes the order against the governed definition and remains the authority — a stale or tampered device cannot commit the business to a price it never offered.
Can scheme spend be tracked against a budget?
Yes — every application accrues against the scheme as it happens, so running spend, spend by geography and spend per case are live views during the promotion, not a post-mortem after it. Overrun risk is visible while there is still time to act on it.
How do scheme claims and settlements work?
Because each scheme application is tied to specific order lines, the claim is generated from the evidence: outlet, invoice, scheme, amount. Distributor-funded and company-reimbursed schemes settle against that line-level trail, which is what turns claim season from a negotiation into a reconciliation.
Can different outlets get different prices for the same product?
Yes — discount groups price by relationship, so negotiated terms live on the customer while schemes live on the promotion. The two compose by rule, and the composed price is what every channel — rep, van, portal — quotes.