Ask a channel finance team to show you their claims process and they will show you a folder tree: scheme settlements in one spreadsheet, quarterly rebates in another, damage and shortage in an inbox, warranty in whatever the principal mandates, price support in a shared drive nobody fully trusts. Each lane has its own arithmetic, its own backlog, and its own version of the fight — the partner's reconstruction of what they earned meeting the company's reconstruction of what it owes. xMatix replaces the folder tree with one structural idea: a claim is not a form someone fills — it is a computation over transactions that already happened, generated on a schedule, decided line by line, and settled into the same ledger the partner's invoices live in.
One boundary first, because the word is overloaded. What follows is about commercial claims — the money a dealer, distributor, stockist or service partner claims back from a business, and the money a business claims from its suppliers and principals. It is not insurance claims processing, and it is not employee expense claims, which run as their own capability with policy checks and reimbursement.
A claim type is configuration, not a project
Most claims software hard-codes a handful of claim types and makes every new one a change request. In xMatix a claim type is described by a claim generation setup — a configuration record, not code. The setup names the source entity the claim reads from, selection rules combined with AND, OR or custom logic, a date window, how qualifying records group into claims, whether amounts are summed into one line or mapped one line per record, field-by-field mappings onto the claim header and lines, and an optional netting leg that subtracts a second source per group — sale returns against a discount claim, payouts already made against a fresh computation. Groups that net to zero or below simply produce nothing.
That is why the same engine runs trade-scheme settlements from the scheme accrual ledger, quantity and slab rebates from the quarter's despatches, cashback, contract price differences, sale-return credits and goods-receipt shortage claims — and why a claim type your business invented last year is a configuration exercise, not a development quote. Damage, freight and other evidence-first claims are raised manually and inherit the same lifecycle: the machinery downstream of generation is shared by every type.
Proven in simulate mode before it pays anything
New claim configurations are wrong in ways that only real data reveals, so the engine assumes you will get it wrong first. Every setup save dry-runs the configured query against live data, so a broken filter fails at save time rather than during the month-end run. New setups start in simulate mode: a simulated run executes the whole pipeline — rules, grouping, aggregation, netting — and reports the claims it would have written, without writing anything. Finance parallel-runs the simulation against the spreadsheet it is retiring, and flips the setup live only when the two agree. How a new claim type goes live walks through that rollout in detail.
Generation is idempotent by construction. Every claim carries a generation key built from its type, group and period; a group that already produced a claim is skipped on later runs, and the run summary counts skips separately from creations. Consumed source records are flagged in the same transaction that writes the claim. Re-running a failed job is therefore an ordinary operation, not a double-payment risk assessment.
Decided line by line, not claim by claim
A claim is lines, and decisions are per line: approved quantities, rejected quantities, or approve-all and reject-all when the whole document reads clean. Each line carries its evidence — the source transaction it was computed from, and on service claims the complaint code, fault code, technician and contract that justify it — so an approver is reading inspectable arithmetic, not adjudicating between two spreadsheets. Claims group into batches for review the way finance teams actually work — by type, region, period — with the same controls and rolled-up approved totals. Approval itself runs on the platform's approval framework, with the routing, delegation and audit trail every other document gets.
Settlement in money or in stock, from approved figures only
Approval triggers settlement automatically, and settlement is built from the approved quantities and amounts, never the claimed ones — a claim approved at 60% settles at 60%, and the rejected remainder never becomes a payout. Per claim type, a settlement setup decides the output: a credit note, linked back to the claim and posted against the partner's account in the same ledger that holds their invoices and outstanding, so a settled claim immediately moves the number the credit gate reads; a part-to-part inventory adjustment, which settles a shortage claim in replacement stock rather than money; or no document at all, leaving only the configured settlement event for downstream systems. Settlement is idempotent the same way generation is — a claim that already produced its settlement document is never settled twice.
Warranty, free service and accident jobs: claims born on the job card
Service claims never start from a blank form. A service contract carries a posting treatment, and as work is recorded, each line on the job decides who pays: covered lines become claim lines on the paying account while consumables on the same job bill the customer — one repair, several payers, decided line by line rather than argued at invoicing. All three workshop lanes are this one mechanism with different entitlements: warranty lines claim the principal, the free services sold with a vehicle are contract entitlements whose covered labour claims the principal when each service is performed, and accident job lines follow the insurer's payer lane on the same job card. The claim inherits the job's evidence trail, and where entitlement is shared, up to three weightage contracts split a line's value across them. The industry treatments are covered on their own pages — automotive warranty claims, the OEM's view, service partner claims and billing and claims in service networks.
The commercial lanes, end to end
On the sales side, the flagship loop runs from schemes and incentives: every invoice line that earns a scheme benefit accrues into the scheme ledger as it posts, claimable schemes accrue at their own claimable percentage, and the claim engine sweeps those accruals into trade claims that settle back into the distributor's account. On the supply side the same engine points the other way: shortages captured at goods receipt and expiry or damage returns become claims on the supplier or principal, built from the receipt and return documents that prove them. And because the general case is covered — scheme, rebate, damage and freight claims for OEM channels — the everything-else that usually lives in email gets a system too.
The partner watches it move
Half the cost of a manual claims process is the status conversation. On the partner portal, each dealer or distributor sees their own claims and where each one stands — in approval, approved, settled, rejected with the reason — scoped by record security to exactly their rows, alongside the accrued, claimable and already-claimed scheme money computed from the same ledger the claims are generated from. The area manager stops being a claims call centre, and the monthly partner meeting starts from a shared statement instead of two grievance lists. The full lifecycle, told as a story, is in Anatomy of a self-settling claim; the operating detail lives in the trade claims documentation.
The capability itself — the setups, the simulate-mode rollout, the settlement documents and the industry treatments — is laid out on the Claims product page.