How to build a reconciliation and treasury system
How bank, processor and ledger data are matched, how treasury sees and moves cash, the controls around payments, and an order to build it in.
What a reconciliation and treasury system does
A reconciliation system matches records that should agree: orders against processor payouts, payouts against bank lines, invoices against receipts. A treasury system gives one view of cash across banks and entities, forecasts it and moves it.
They belong together because both start from the same bank data. Clean bank feeds and a reliable matching engine are what make a cash position trustworthy.
The modules you need
Most teams need all of these in the end. The phased plan below sets the order.
Bank and processor feeds
Statements and transaction files from every bank and payment provider, in their formats.
Matching engine
One-to-one, one-to-many and three-way matches with rules and tolerances.
Exception queue
Unmatched items routed to the right person with suggested matches.
Cash position
Balances across banks, accounts, entities and currencies, in one view.
Forecasting
Expected inflows and outflows from invoices, payroll and schedules.
Payments
Payment files and API payments with dual authorisation and limits.
Accounting entries
Matched items posted to the general ledger.
How the parts fit together
- 01
Normalised transaction store
Every bank and processor format mapped into one model, with the raw file kept.
- 02
Rules-based matching
Matching rules as configuration, with every match recording the rule that made it.
- 03
Dual control on payments
No payment leaves without a second approver, and limits by user and amount.
- 04
Idempotent imports
Re-importing a file never creates duplicates.
- 05
Audit trail
Who matched, unmatched, approved or changed what, and when.
Data model sketch
- 01
Bank account
Bank, entity, currency and connection details.
- 02
Statement line
Each bank or processor line with its raw source.
- 03
Internal record
Orders, invoices or ledger entries to match against.
- 04
Match
The records matched, rule used, tolerance and who confirmed it.
- 05
Payment instruction
Payee, amount, approvals and status.
Systems it has to talk to
- 01
Banks
ISO 20022 messages such as camt.053 statements and pain.001 payments, SWIFT MT940 and host-to-host or API connections.
- 02
Payment providers
Settlement and payout reports from each processor.
- 03
ERP and general ledger
Invoices, payables and postings.
- 04
E-invoicing and tax systems
Where invoice data comes from a national system.
Rules to design for
Which rules apply depends on your market and product.
- 01
Accounting records
Bookkeeping and retention rules for the entries and their evidence.
- 02
Payment controls
Dual authorisation and segregation of duties expected by auditors and, for regulated firms, by supervisors.
- 03
Operational resilience
For financial firms, DORA and similar rules cover the systems that move money.
- 04
Payments rules
Strong customer authentication and payment scheme rules for payments made through APIs.
From prototype to production
Build in this order so something real is in users' hands early.
- 01
Clickable prototype
The exception queue and cash view, tried by finance and treasury staff.
- 02
First bank and matching
Feeds from the main bank and processor, matching rules and the exception queue.
- 03
All banks and cash position
Every bank and entity in one cash view, with ledger postings.
- 04
Payments and forecasting
Payments with dual approval and a cash forecast.
What drives the cost
These decide most of the budget. For a number based on your own scope, use the cost tool. OceanLab bills $30-50/hr or per milestone.
- 01
Banks and formats
Each bank and file format is an integration.
- 02
Matching complexity
Many-to-many and three-way matches take more rules and testing.
- 03
Entities and currencies
Each entity and currency adds accounts and rules.
- 04
Payment connectivity
Sending payments needs secure bank connections and approval flows.
- 05
ERP integration
How easily data moves to and from your ERP.
Product builds that match this guide
Contrepoint - Three-Way Reconciliation Engine for Orders, PSP Payouts and Bank Lines
Designed and built a clickable reconciliation engine for a Lyon-based marketplace group paid through Adyen, Stripe, PayPal and SEPA: it matches orders to PSP transactions, payouts and bank statement lines, explains every suggestion, turns what is left into a worked exceptions queue and traces each match to the journal entries it posts.
Falaj - Multi-Bank Treasury and Cash Management Platform with Dual Authorisation
Designed and built a clickable treasury platform for a Dubai-headquartered group with companies in the UAE, Saudi Arabia and India: one daily cash position across 11 banks in AED, a rolling 13-week forecast, and outgoing payments that go through dual authorisation before they are released to the bank.
Kwitek - KSeF Invoicing, Collections and Cash Matching Platform
Designed and built a clickable invoicing and receivables platform for a Gdańsk wholesale distributor of heating and plumbing supplies: invoices issued through KSeF, a receivables dashboard with ageing, a collections worklist driven by a dunning cadence, and a matching workbench that pairs bank receipts, including split payments, with the invoices they pay.
Two ways to work with OceanLab
Project build
We design and build the system as one project. It starts with a clickable prototype your team tries before any production code is written. Pay per milestone (outcome-based) or hourly at $30-50/hr, depending on role and seniority.
Embedded engineers
Our engineers join your team on a flexible monthly retainer. Part-time is fine and it runs month to month, with hours that overlap the US, UK and Europe, the Middle East, and Australia and Asia. Outcome-based or $30-50/hr.
Questions
Can matching be fully automatic?
Most of it, once the rules are tuned. The rest goes to an exception queue with suggested matches, and every match records the rule or person behind it.
Which bank formats do you support?
ISO 20022 statements and payments, SWIFT MT940 and MT942, and local formats, through files, host-to-host or bank APIs.
How are payments protected?
Dual authorisation, limits per user and amount, changes to payee details checked separately, and a full audit trail.
