2,400 SKUs. Five tender types. Twelve source ledgers. The client's team spent two weeks a month matching entries by hand — and still ended with a book of unresolved breaks. We built an auto-matcher that closes 99.9% of the ledger before a human ever sees it.
Every transaction had to reconcile across three axes at once: which SKU, which tender, which acquiring bank. Reconcilers built VLOOKUPs that took hours to run and hid the exceptions that mattered.
~180,000 transactions a day landed in five tender buckets. Cash needed matching against physical DSR sheets. Cards had TID-level MDR splits from three acquirers. UPI came through two aggregators with different settlement windows.
Reconcilers manually classified breaks into ten failure modes: TID mismatch, MDR variance, refund echo, split settlement, cutover timing, chargeback echo, and more. It never caught up.
Multi-tenderMulti-acquirerSettlement lagSKU sprawlManual VLOOKUP
We collapsed the reconciliation matrix into a single rules-plus-fuzzy engine, driven by tender-specific match keys. Anything auto-matched posts straight to the ledger; only true breaks reach the reconciler queue.
Bank statements, processor MIS, POS DSR and internal orders unified into one canonical schema per tender.
TID + amount + timestamp keys clear the majority in one pass. Split-settlement and refund echoes handled inline.
Amount-window and reference-prefix matchers pick up MDR variance, timing gaps and truncated remittance strings.
Every unmatched entry auto-tagged by failure mode with a proposed resolution. Reconciler confirms or overrides.
Within two months the reconciler's workday flipped: from clearing thousands of matched rows to investigating a handful of true exceptions. The rest simply reconciled.
"The reconciliation ledger used to be the last thing we looked at every day. Now the engine writes it before we start — and my team spends their time on the exceptions that need judgment."
The rules, the models, the operator tools — all shipped as source. No black-box service.