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 |
| 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.
The questions evaluators ask.
Do we need a developer to add a new claim type?
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.
How do we know a new claim configuration is right before it pays anyone?
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.
What happens when a claim is only partly approved?
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.
Can partners raise their claims from the portal?
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.
How does a claim reach the principal’s own claim system?
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.
