Four entities, three banks, two accounting systems and one shared finance team. Nobody could answer 'how much cash do we actually have, and how much of it is already committed?' without a two-day exercise, and by the time the answer arrived it described a week that had already ended.
The books were not wrong. They were late. Reconciliation happened in a burst before each quarter, which meant that for most of the year the ledger was a historical document rather than an operational one. Every decision that needed a cash number, whether a hiring approval, a vendor negotiation or a working-capital line, was made on a spreadsheet somebody had maintained by hand.
Why this is an agent problem, not a rules problem
Roughly seventy per cent of matching is genuinely mechanical: amount, date and reference line up, and a rules engine handles it. The remaining thirty per cent is where finance teams actually spend their time: a single payment settling five invoices, a customer short-paying and deducting TDS, a UPI reference that carries a person's name rather than an invoice number, a credit note issued three weeks after the fact.
Those cases need reading, not matching. An agent can look at a bank narration, the open invoice set, the customer's payment history and the ledger entries, form a hypothesis, and say why it thinks a ₹4.2L receipt clears three invoices less a TDS deduction. That reasoning is the deliverable. Not the number, but the argument behind it.
How it runs
Sync, don't replace
Tally Prime and Zoho Books stay the ledger of record. BM Ledger reads masters, vouchers and open items, and writes back only entries a human or a confidence threshold has approved. No migration, no parallel truth.
Normalise every source
Bank statements, UPI and gateway settlements, sales and purchase invoices, credit notes and GST filings all land as the same typed record. Narrations are parsed into counterparty, instrument and reference before a model sees them.
Match in three passes
Exact match first, then fuzzy on amount-and-window, then partial and many-to-one for split settlements, short payments and deductions. Each pass is cheaper than the one after it, so most volume never reaches the expensive step.
Cite, then post
Every proposed match carries the rows it was built from. Above the confidence threshold it posts automatically with that citation attached; below it, it goes to a review queue as a suggestion with its reasoning, not as a blank line to investigate.
Project cash and working capital
Because the ledger is current, the projection can be too: committed payables, expected receipts weighted by each customer's actual payment behaviour, recurring costs and the working-capital position that falls out of them.
Keep the audit pack warm
Ledger, supporting document, match evidence and approver are linked as the entry is created. The audit pack is a query against work already done, not a three-week reconstruction.
The integrations are the product
Finance teams do not want another system of record, and they are right not to. The work went into meeting the tools they already run:
- Tally Prime: masters, vouchers and open items over the ODBC/XML interface, with write-back gated behind approval and a full change log.
- Zoho Books: two-way sync over the API, with idempotent writes so a retry can never double-post an entry.
- Bank, UPI and payment-gateway feeds: statements and settlement reports normalised into one shape, including the ones that still arrive as PDF.
- GST portal data: for reconciling input credit against purchase entries, which is where a surprising share of the exceptions turn up.
- Anything else over a generic adapter: a few clients run a second ERP for one entity, and that entity should not become the exception.
What a live ledger makes possible
The cashflow projection was the outcome the client cared about, but it was never a modelling problem. It was a data-freshness problem wearing a modelling costume. Once reconciliation ran daily, a useful forecast was mostly arithmetic over reconciled positions plus each customer's observed payment behaviour.
Illustrative figures. The shape that matters is the widening band: a projection built on reconciled books is narrow near today and honest about how quickly it loses confidence.
- Auto-matched
- 94%
- no human touch
- Books current to
- Yesterday
- Audit pack prep
- 2 days
- from 3 weeks
- Finance hours returned
- 160/mo
The remaining six per cent is not failure. It is the set of things that genuinely need a person: a missing document, a disputed deduction, a duplicate that should be written off. Making that queue small, well-explained and consistently short is the actual goal, not driving it to zero.
What we would do again
- Fix ingest before touching the model. Most 'the agent got it wrong' tickets in month one were narration-parsing bugs.
- Ship the review queue in week one. Every correction a reviewer makes is a labelled example, and the confidence threshold has nowhere to move without them.
- Never let the agent be the only writer. Reversible, attributed, logged, or it does not post.
- Treat the exception queue length as the health metric. Match rate can look excellent while the exceptions quietly pile up.
- Keep the projection tied to reconciled data, and show the band. A confident forecast on stale books is worse than no forecast.
“We stopped preparing for the audit. The audit pack is just a report now, and I know our cash position before the standup rather than after month-end.”