There is a category of software change that deserves more fear than it usually gets: the one that decides who gets paid. A new trade-scheme settlement, a rebate computation, an expiry-claim sweep — these are not features, they are standing payment instructions, and a subtly wrong filter does not crash; it pays. The traditional insurance against that is the claims project: requirements, custom code, testing, a go-live weekend, and then a quarter of disputes that are really defect reports. On xMatix, a claim type is configuration on a shared engine rather than code — which removes the project but not the fear. What removes the fear is the rollout discipline the engine is built around. It has four steps, and the whole point is that none of them requires courage.
Step one: the save is already a test
A claim generation setup declares its pipeline declaratively — the source records to sweep, selection rules, a date window, how candidates group into claims, whether amounts sum into one line or map line-per-record, and an optional netting leg that subtracts a second source, such as returns against a discount computation. Declarative configuration can still be wrong, so the engine refuses to store a setup it cannot run: every save dry-runs the configured query against live data. A field name that does not resolve, a filter that cannot compile, a netting source that does not join — these fail at save time, in the author's face, rather than at two in the morning inside the month-end run. It is a small mechanism with a large consequence: by the time a setup exists at all, its query is known to execute.
Step two: simulate against the data that matters
Executing is not the same as being right, and rightness only shows against real data — the distributor with two branches, the scheme that was amended mid-quarter, the return that arrived after close. So new setups start in simulate mode: a simulated run executes the entire pipeline — selection, grouping, aggregation, netting — and reports what it would have written: the claims, their groups, their lines, their amounts. It writes nothing, flags nothing, consumes nothing. The finance user reads the simulation the way an auditor reads a draft statement: are these the partners I expect, is the biggest number explicable, does the netting remove what I think it removes? Most configuration mistakes die here, cheaply, visible as numbers rather than as consequences.
Step three: parallel-run one real cycle
The strongest test is the one the spreadsheet has already taken. For one cycle — a month, a quarter, whatever the claim type's rhythm is — the old process runs as it always did, and the simulation runs alongside it on the same period. Then the two answers are compared, and every difference is investigated until it has a name: a dealer the spreadsheet missed, an amendment the configuration missed, a return the manual process never netted. In our experience the spreadsheet loses more of those arguments than the ledger does — manual claim processes leak in both directions, and the parallel run is usually the first time anyone measures it. Either way, the outcome is the only kind of confidence worth having: not "the demo looked right" but "these two independent computations agree on last quarter, and we understand every place they briefly didn't".
Step four: switch it on, and let idempotency carry the risk
Going live is deliberately anticlimactic: simulate mode off, the setup joins its schedule group, and the platform's job machinery runs it — with progress, per-setup summaries and inspectable errors on the same jobs screen as everything else. The property that makes live operation boring is idempotent generation. Every claim carries a generation key derived from its type, its group and its period; a group that already produced a claim is skipped, and the run summary counts skips separately from creations. The source records a claim consumed are flagged in the same transaction that writes it. So the operational incidents that plague payout systems — the job that died halfway, the nervous re-run, the double-triggered schedule — resolve to the same dull outcome: what exists is skipped, what is missing is created, nothing pays twice.
The discipline survives the go-live
Downstream, the same posture continues. Generated claims are decided line by line — approved and rejected quantities, with partial approval settling partially from approved figures only — and settlement posts a credit note (or, for shortage claims, replacement stock) linked back to the claim it settles, into the same ledger the partner's invoices live in. What began as a standing payment instruction ends as ordinary accounting, inspectable end to end: from the transaction that earned the money to the credit note that paid it. And the next claim type — the one your commercial team invents next year — follows the same four steps, on the same engine, without a project. That is the real yield of simulate-first: not just that nothing wrong gets paid, but that trying a new claim type becomes cheap enough to do often. The configuration walkthrough lives in the claim setup documentation.