A round number arrives from a vendor with 4 open invoices. Which one did it settle?
On the day, the question answers itself. The remittance is in somebody's inbox, the amount is recognisable, the context is fresh. 3 weeks later it is a small research project, and there are 200 more like it waiting in the same list.
That is payment reconciliation in 1 example. The work is not difficult. It is only difficult late, and almost every finance stack is built in a way that guarantees it happens late.
systems at All Gravy, including a card provider and 2 payment platforms, replaced by 1 ledger
card transactions a month at All Gravy that used to be uploaded and matched by hand
agent clearing the bank continuously, under its own identity and audit trail
The gap that creates the work
Payment reconciliation exists as a distinct task because payment happens in 1 system and the ledger lives in another. Money moves through a payment platform, a card provider, a bank. The record of what was owed sits in the books. Nothing connects the 2 except a reference field that survives the journey maybe 70% of the time.
All Gravy had 3 of these gaps at once: Pleo for cards, Corpay and Farpay for supplier payments, and 4 different ledgers underneath. The card side alone produced 500 to 600 transactions a month with no direct link into any ledger, so every one went in by hand. A single missing receipt held up the entry, which meant somebody tracked exceptions across 2 systems while the close waited.
Note the shape of that. The exceptions were not caused by anything unusual about the transactions. They were manufactured by the pipeline that moved them.
What closing the gap looks like
All Gravy replaced all 7 systems with 1. Card spend is now native to the ledger and those 500 to 600 monthly transactions land without anyone touching them. Global bill pay replaced both payment platforms.
Once payment and record sit in the same place, matching stops being a translation exercise between 2 systems and becomes an internal consistency check. The Bank Rec Agent clears the bank against live feeds as transactions arrive, carrying its own principal so every match is attributable rather than disappearing into a shared service account. Each run shows what it matched and on what basis.
Dreamdata reaches the same outcome from the receivables side: payment settlement feeds bank reconciliation directly, so cash ties back to the invoice it settled without a matching step in between.
500 to 600 card transactions a month at All Gravy, every one matched by hand. That number is now 0.
Old model
Two systems, one reference field
Payments live in a platform, obligations live in the ledger, and reconciliation is the monthly job of reconnecting them from whatever reference survived.
Light's model
One system, no translation
Payment and record sit together. The Bank Rec Agent matches on arrival under its own identity, and exceptions surface the same day.
What changes
Cash is current, not monthly
The ledger is the cash position today rather than as at last month-end, so nobody maintains a second view in a spreadsheet.
Partial payments, fees and the rest of the mess
The hard cases in payment reconciliation are always the same short list. A customer pays 2 invoices with 1 transfer. A payment arrives net of a fee the bank took. A partial payment lands against a disputed line. An FX difference means the amount received is not the amount invoiced. A refund arrives with no reference at all.
None of these are exotic and none of them are solved by better matching logic alone. They are solved by proximity. Every one is tractable while somebody still remembers the context, and every one becomes a research task once the trail has gone cold. Matching on arrival does not make the hard cases easy. It makes them recent, which is most of the way there.
The genuinely ambiguous ones still reach a person, and they should. There are far fewer of them when the ambiguity is 4 hours old rather than 4 weeks.
Why this is a cash question, not an accounting one
A finance team with monthly payment reconciliation has a trustworthy cash position once a month and an estimate for the other 29 days. Most have quietly accepted this and run a parallel cash view in a spreadsheet for the questions that arrive in between.
That spreadsheet is the tell. It exists because the ledger cannot answer a question the CFO gets asked weekly: what have we actually got, what is genuinely still owed, and can we commit to this.
All Gravy's next ask is precisely this, and it is worth quoting as a destination rather than a feature: a live treasury view across every connected bank account, showing what is coming in, what is going out and what the company holds, without waiting for the close to say so. That is only possible when payments and the ledger stopped being 2 systems.
See how Light runs payments and reconciliation, or book a demo.