Merchant operations
What the order system says the customer paid or received back.
— recordsRazorpay finance operations · bounded reconciliation sandbox
Four ledgers.
One provable story.
MatchRail connects merchant operations, Razorpay reconciliation, accounting, and bank records. It matches only what the evidence proves and sends uncertainty to review.
No setup required, or bring a strict four-source dataset below.
Inspect the frozen benchmark ↓Data inputs · upload files or use Razorpay test Recon
Data inputs
Use your files, or pull test-mode Razorpay Recon.
Runs are isolated to this browser session. Completed runs expire after one hour by default.
Default limits: 2 MiB per file, 8 MiB combined, five run attempts per ten minutes, and twelve AI calls per run. Provider and Razorpay credentials never enter the browser.
Uploads run deterministic reconciliation. The optional live AI demonstration uses separate fixed synthetic cases, not your uploaded exceptions.
The reconciliation problem
Each source tells a different version of financial truth.
Identifiers drift, dates move, refunds split, records disappear, and totals still need to balance.
Razorpay recon
What the payment gateway says was captured, refunded, and settled.
— recordsAccounting ledger
What finance booked, sometimes under different references or dates.
— recordsBank statement
What cash actually arrived, anchored by UTR and settlement net.
— recordsHow MatchRail stays safe
Evidence first. AI inside the guardrails.
- 1
Normalize four sources into integer-paise financial records.
- 2
Prove exact identifiers, settlement membership, UTRs, and arithmetic.
- 3
Abstain when multiple financially valid candidates remain.
- 4
Ask AI only about the unresolved semantic description.
- 5
Gate again with candidate, confidence, and verbatim-evidence checks.
- 6
Expose every exception and its source-level evidence for review.
Run lifecycle
Ready for a seeded run
Reconciliation outcome
Proven matches, balanced money, visible exceptions.
Settlement control equation
Razorpay reconstructed net = bank cash = accounting net
—=
—=
—
Checking
Proof ledger
Recent proven relations
| Relation | Method | Evidence |
|---|
Review queue
Exceptions MatchRail refused to guess
Live provider sample · canonical benchmark preserved separately
Live AI demonstration on fixed synthetic cases.
This separate 12-case demonstration does not resolve exceptions in the current dataset.
Correct resolution coverage is the share of uniquely resolvable cases
matched correctly. It is not a safety score, so it is always shown with precision and
false-auto-match count.
Frozen benchmark
A wrong match is worse than an honest exception.
Identical synthetic inputs. Known answer keys. Results captured once and preserved.
Across golden, holdout, and adversarial datasets, compare the naive matcher with deterministic MatchRail. These results measure the tested cases; they are not a guarantee for unseen merchant data.
| Dataset | System | Precision | Recall | False matches | Correct abstentions |
|---|---|---|---|---|---|
| Loading frozen evidence… | |||||
Break MatchRail
Inspect the traps that make a naive matcher guess.
Choose a frozen adversarial case to inspect both decisions and the source records.
Frozen AI benchmark
9 correct resolutions. Zero false matches. Three abstentions.
12 fixed semantic cases: 10 resolvable and 2 intentionally ambiguous. Claude resolved 9 of the 10 resolvable cases. Two ambiguous cases and one low-confidence case remained abstained. The live sample above may differ.
Correct resolution coverage = correct resolutions / resolvable cases. A matcher can reach 100% coverage while also making false matches. Always inspect precision and false-match count alongside it. An abstaining system with no predictions is reported as 100% precision by convention; that is not evidence of useful coverage.
Curated source files, hashes, method, and limitations ship with the repository under docs/benchmarks. Latency and cost are historical measurements.