Three systems record every sale. They never agree.

The merchant's ledger has the order amount. The payment gateway has it less its fee. The bank has one netted credit a day or two later, covering dozens of orders, with no line items. This engine reconciles all three, explains every difference it can, and hands the rest to a person with a reason attached.

Open the workbench Read the source

resolved on the reference batch
agreement with the answer key
unseen defects caught

01How it works

Four files in. Every record out, with a reason.

Matching is a cascade of progressively weaker methods. Every resolution records the tier that produced it, so the result is stratified by confidence instead of reported as one opaque percentage. Figures below are from the reference batch.

Ledger

ledger.csv

Gateway

gateway.csv

Settlements

settlements.csv

Bank

bank.csv

Engine

Tiered matcher

0 Self-consistency
1 Exact key joins
2 Deterministic inference
3 Bounded agent

Matched–

Explained–

Needs review–

Break–

Matched and explained records close themselves. Anything that needs review or is a genuine break is sent to a person with the reason attached; none is dropped.

The cascade

Each tier sees only what the tier before it could not close. The bars show how much of the batch is still open as it enters each one. Select a tier for what it does.

02Workbench

Run it on a batch of your choosing.

Pick a bundled batch, generate one with the defect rate you want, or upload your own three files. Every chart and table below is the engine's output for that batch; the browser only lays it out.

04The agent

The model proposes; code decides.

Records the deterministic tiers cannot close go to a bounded agent. It chooses which of nine investigation tools to call, at most five rounds per record, and must cite a tool result for any claim. It does no arithmetic. An invented class is downgraded, an unevidenced resolution is overruled, and a model failure becomes an escalation, never a wrong number.

Records

Trace

05Principles

Three stances, and the rules of the domain.

The reasoning behind each choice, and what was rejected, is in DECISIONS.md; what broke during the build and how it was fixed, in NOTES.md.

A wrong match is worse than no match

An unmatched record is visible and gets looked at. A wrong match is invisible and makes the books appear to balance. Where two settlements fit equally, the engine refuses to choose.

Constraints live in code, not in the prompt

Step limits, a closed tool registry, a fixed taxonomy and the evidence rule are enforced by the program and tested with adversarial input, no model in the loop. A rule in a prompt is a request.

Measured against an answer key

The generator writes a ground-truth file the engine never reads. Accuracy is graded, not asserted, and CI fails the build if it moves.

Domain rules encoded

Each is enforced in the engine's code rather than left to convention. A single hardcoded fee rate, for example, would be wrong on three of the four payment methods.

Money is integer paise throughout; floats never touch currency.
MDR depends on method: a percentage for cards and wallets, flat for netbanking, zero for UPI.
Settlement is T+1 working days; a Friday capture settles on Monday.
Refunds and chargebacks are negative, so a settlement can legitimately net below zero.
Only rows that moved money must satisfy gross − fee − GST = net; a failed attempt has net zero.
An order in a currency other than INR cannot be compared, however well its number ties.