Claims lifecycle architecture.
Configure
Claim rules & eligibility criteria defined upfront
Simulate
Claim amounts previewed before anything is generated
Generate
Claims raised automatically from qualifying transactions
Approve
Claims reviewed & approved within policy limits
Settle
Approved claims paid out against the account
Reconcile
Settled claims matched back to source documents
One engine for every claim.
A claim type is configuration, not a project
A claim generation setup names the source records, the selection rules combined with AND, OR or custom logic, a date window, how candidates group into claims, whether amounts sum into one line or map one line per record, the field mappings onto claim header and lines, and an optional netting leg. Trade scheme settlements, quantity and slab rebates, cashback, contract price differences, sale-return credits and goods-receipt shortages all run on that one engine.
Proven before it pays anything
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 creating anything. Finance parallel-runs a cycle against the process being retired, investigates every difference, and only then switches simulate off. Generation is idempotent by construction, so the runs after that are uneventful.
Decided line by line, settled from approved figures
Approvers set approved and rejected quantities per line, or decide a clean claim at once, and claims group into batches for review the way finance actually works — by type, region and period. Settlement then runs automatically from the approved figures: a credit note posted against the partner’s account and linked back to the claim, a part-to-part inventory adjustment where a shortage settles in replacement stock, or no document at all where a claim type only needs its settlement event.
The claim computes itself.
The capabilities, stated plainly.
Every row ships today and traces to a capability described on this page.
| Capability | xMatix Claims |
|---|---|
| Claim types defined by configuration | Setups, no code |
| Selection rules with AND, OR and custom logic | Yes |
| Save-time dry run of the configured query | Yes |
| Simulate mode — a run that writes nothing | Default on new setups |
| Idempotent generation keyed by type, group and period | Yes |
| Netting a second source per group | Yes |
| Scheduled run groups, and an on-demand action | Both |
| Line-level approved and rejected quantities | Yes |
| Partial approval settles partially | Yes |
| Capability | xMatix Claims |
|---|---|
| Settlement document | Credit note, stock adjustment, or none |
| Credit note applied to open invoices | Configurable, oldest first |
| Claim batches with rolled-up approved totals | Yes |
| Warranty, free service and accident-job claims from job cards | Yes |
| Supplier-side shortage, damage and expiry claims | Yes |
| Partner sees their own claims and status | Portal, read-only |
| Submission into a principal's own claim system | Integration flow |
| Reconciliation | Flag, action and register |
Everything in Claims.
Claim generation setups
A claim type without a project.
Source, rules, date window, grouping, aggregation and mappings are configuration — so the claim type your commercial team invents next year does not need a release.
Simulate mode
Proven before it pays.
A simulated run executes the whole pipeline and reports the claims it would have written, creating nothing. It is how a configuration earns its way into production.
Idempotent runs
Re-running is uneventful.
Claims are keyed by type, group and period and consumed sources are flagged in the same transaction, so a repeated or restarted run skips what exists.
Netting
Returns subtracted inside the claim.
A second source is subtracted per group before the claim is written, and groups that fall to zero produce nothing — so a return never arrives later as a surprise adjustment.
Line-level decisions
Partial approval, partial settlement.
Approved and rejected quantities are set per line, with approve-all and reject-all for clean claims. Settlement is built from the approved column only.
Settlement documents
Money, or replacement stock.
A linked credit note against the partner's account, a part-to-part inventory adjustment where a shortage settles in stock, or settlement switched off entirely for a claim type.
Service-contract claims
Warranty, free service and accident jobs.
The contract's posting treatment decides per line who pays, so one job can bill the customer for consumables and claim the principal or insurer for covered work.
Supplier-side claims
Shortage caught at the gate.
Shortages recorded on the goods receipt and expiry or damage returns become claims on the supplier, carrying the receipt, item and batch that prove them.
Claim batches
Reviewed the way finance works.
Claims group into batches by type, region or period, with the same decision controls and rolled-up approved totals.
Scheme accrual to credit note
The trade loop, closed.
Benefits accrue as documents post, the run sweeps the accruals into claims, and approval posts a credit note into the ledger the distributor's invoices already live on.
The questions evaluators ask.
No. A claim type is a generation setup: you name the source records, the rules that select them, how they group, what is summed or mapped, and what happens after approval. The engine that runs it is the same one every other claim type uses, which is why adding one is configuration work for an administrator rather than a development quote.
Two gates. Saving a setup dry-runs its query against live data, so anything that cannot resolve fails immediately. Then simulate mode runs the whole pipeline and reports the claims it would have written — groups, lines and amounts — without creating a thing, which is what lets finance parallel-run a full cycle against the process being replaced and compare before switching over.
It settles partially. Approvers set approved and rejected quantities per line, and the settlement document is built from the approved figures only, so a claim approved at 60% produces a 60% credit note. The rejected remainder never becomes a payout and keeps its reason attached.
Partners see and track their claims on the portal — status from generation through approval to settlement, plus their accrued, claimable and already-claimed scheme money, scoped by record security to their own records. Raising is deliberately not a portal action, because the commercial claims are computed from the transactions that earned them rather than typed from memory; damage and freight claims start from the goods receipt or despatch that captured the evidence.
Through an integration flow configured for that principal. Claim and batch documents, their lines and their evidence keys are all queryable, and every principal expects a different submission format, so the transport is configured per relationship rather than assumed by the product.
