Teaching software to read your ledgers

Every business that buys or sells on credit does reconciliation — matching what your ledger says
against what the other side's ledger says, invoice by invoice, until the difference is explained.
And almost every business does it the same way: someone exports both ledgers, lines them up in a
spreadsheet, and spends days finding out which invoices were never booked, which payments were
never accounted, and where the tax deductions went.

The hard part was never the arithmetic. It is that no two ledgers look alike. One side exports
from SAP, the other from Tally. One arrives as a clean spreadsheet, the other as a scanned PDF of
a printed ledger. The same invoice number is called "Bill No." on one side, "Vch No." on the
other, and "Ref/Cr Memo No." on a third. Reconciliation software that assumes one format meets
the real world and stops.

ServiceHub's ledger reconciliation starts from the mess as it is. It reads Excel, CSV, SAP HTML
exports, scanned PDFs and raw Tally vouchers; it derives the balances from the ledgers themselves
rather than trusting a typed-in number; it matches invoice-wise, classifies every difference —
including GST and TDS treatment — and walks the two closing balances toward each other until the
gap is explained line by line. A finance reviewer approves the reconciliation before anything
leaves the building, and every run records what the software actually did, tool by tool. Its
accuracy is held to real, completed reconciliations in our build pipeline: a change that would
lower it fails the build.

But the capability we are most proud of is newer, and it answers the question every reconciliation
tool eventually faces: what happens when a ledger arrives in a format you have never seen?

Until recently, the honest answer everywhere — including here — was "an engineer teaches the
system the new format." That is a project: a queue, a release, a wait.

Now you teach it yourself. You upload a sample of the new ledger, describe in your own words how
to read it — "Chalan is our despatch invoice number; Goods Val is the invoice value" — and give
it one known-correct answer: the closing balance and how many entries the sample holds. The
platform proposes how it would read the format, then proves that proposal by extracting your
entire sample and checking the result against your known-correct answer. If everything checks
out exactly, the format is approved on the spot. If anything is uncertain, it pauses and shows
you what it learned — and you correct it the way you would correct a colleague: write a comment
in plain language and ask it to try again. An approved format is live for the very next
reconciliation run. No code. No release. No waiting on us.

There is no trust-us step anywhere in that loop. A format cannot go live while its proof fails —
not even a reviewer can override that — and every live format carries its provenance: which
request taught it, what evidence it proved, and every version it has been through.

This is also, quietly, a story about the platform underneath. The training workflow was built on
the same ServiceHub primitives every customer uses — self-service requests, steps that run
deterministically or as governed AI agents, three levels of human oversight, credits. That is why
it shipped in days rather than months, and it is why the next capability will too.

We built this for construction-industry reconciliation first — cement, ready-mix concrete, and
the goods lines that follow. But mismatched ledgers are not a construction problem; they are an
every-business problem, anywhere two accounting systems meet. That is where this is heading: a
reconciliation suite that grows with the formats your counterparties actually send — a capability
growing into ReconciliationHub.

If you reconcile ledgers by hand today, we would like to show you this on your own files.