Picture a platform that collects money on behalf of the businesses that use it. Payments arrive by card and by bank debit, settle on different days, and some of them come back a week later. The question its finance team cannot answer quickly is the simplest one: did we receive what we think we received.
Money arrives on five schedules and the books close on one
A card payment is approved in a second, but the money reaches the bank a day or two later with the fees already taken off. A bank debit leaves on one date, arrives on another, and can be returned up to sixty days afterwards. A cheque arrives whenever the post does.
So on any given day the gateway report, the bank statement and the ledger show three different numbers, all of them correct. Without something reconciling them daily, the differences are found at close, chased by hand, and the ones nobody can explain get written off with a journal entry to make the month balance.
Every payment has a record and a reason
The design rule is that nothing is ever overwritten and nothing is ever balanced by force. A payment, a fee, a return and a correction are all separate entries with their own evidence, so the history of any amount can be read back.
Card details go straight to the payment provider and come back as a secure token, so no card number is ever stored in the platform’s own systems.
Bank transfer files sent on schedule, and bounced payments handled automatically according to why they bounced, rather than by someone reading a report.
Every payment, fee, refund and correction is recorded as its own entry. Nothing is changed afterwards; a mistake is fixed with a new entry, so the history always adds up.
The payment provider’s report, the bank statement and the ledger compared every day, so a difference is a day old when someone looks at it, not a month old.
The evidence packet — the order, the delivery proof, the communications — assembled automatically against the deadline the card network sets.
Payments that will not match are reviewed by an AI assistant that suggests the right match and shows why. A person approves it.
Fees are recorded separately rather than quietly subtracted, which is the difference between books that match the bank exactly and books that are close enough until an auditor asks.
One payment, from authorisation to reconciled
This is the standard lifecycle every payment goes through. The work is not in any single step — it is in making sure the record written at each one can still be matched to the others a week later, when something goes wrong.
The card is approved and the payment provider returns a secure token. The card number itself never reaches the platform’s own systems.
The money moves overnight and the bank deposit arrives the next day with fees already taken off — which is why fees are recorded separately.
The payment is recorded against the invoices it covers, oldest first or by the business’s own rule, with the provider’s reference attached so it can always be traced.
Provider, bank and ledger are matched daily. If a bank payment bounces, it is reversed with the reason recorded, the invoices it paid are reopened, and the right retry or follow-up starts on its own.
The AI assistant looks at the payments that will not match — a transfer with no reference, one payment covering two invoices — and suggests a match with the evidence beside it. It never records an entry, never moves money and never writes off a difference. A person approves every one.
Differences are a day old, not a month old
Finance opens a queue of exceptions with the three records side by side and the evidence attached, instead of opening a spreadsheet at close. A returned payment reverses itself correctly, reopens the right charges and applies the right fee without anyone looking up what the bank’s return code means. Card numbers never touch the platform’s own systems, which keeps its card-security (PCI) scope as small as the payment provider allows.
Records matched every day: the payment provider, the bank and the ledger.
Unexplained write-offs. Nothing is balanced by quietly adjusting the numbers.
Reconciliation, so a problem surfaces in hours rather than at month end.
This case study is an illustrative example of how we build this kind of system. It does not describe or identify a specific client, and the details are representative. Product and company names are trademarks of their respective owners, mentioned only to describe compatibility; no partnership or endorsement is implied.
