A software platform collects money on behalf of the businesses that use it. Payments arrive by card and by bank debit, settle on different days, and some come back a week later. Its finance team cannot quickly answer the simplest question: did we receive what we think we received?
Payments settle on different days, but the books close once a month
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
Nothing is overwritten, and nothing is adjusted just to make the numbers balance. 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 differences are found the next day instead of at month end.
The evidence for each dispute, including the order, proof of delivery and messages, is put together automatically before the card network’s deadline.
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 as separate entries rather than subtracted from payments, so the books match the bank statement exactly.
One payment, from authorisation to reconciled
This is the standard lifecycle every payment goes through. The hard part is making sure the record from each step 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. That 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 payments that will not match, such as a transfer with no reference or 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.
Problems found the next day
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.
