Reconciliation API. Structured bank data. Connected financial workflows.
Open Banking AIS and PIS for accounting and ERP platforms building accurate reconciliation infrastructure.
The reconciliation API is working. The unmatched exception queue is still growing.
This is the conversation I have with accounting platform teams more often than any other. They built the matching logic. They wired up the bank feeds. They deployed the reconciliation API. And every Monday morning, the exception report is long and the finance team is investigating transactions manually.
The algorithm isn’t the problem. The data feeding it is.
A reconciliation API that receives a bank transaction with the description “BACS CREDIT 441293” and a payment reference that says “INV-2024-031” is being asked to match two things that share no common identifier. The algorithm cannot bridge that gap. The infrastructure that produced the data should have prevented it.
Accurate reconciliation is an infrastructure problem before it is an algorithm problem.
“When a platform asks me why their reconciliation API has a 30% exception rate, I don’t look at the matching logic first. I look at what the transactions contain when they arrive. Nine times out of ten, the references are inconsistent, the descriptions are generic, or the bank data is arriving 18 hours after the payments are settled.” – Yuri, Finexer
TL;DR
A reconciliation API improves matching accuracy when the underlying bank transaction data is structured, referenced, and delivered near settlement. The common failure mode is not a weak matching algorithm – it is a data layer that delivers generic bank descriptions, missing references, and batch-delayed transaction data that the algorithm cannot resolve. Accurate reconciliation requires the payment reference to survive from initiation through to bank confirmation, and bank transaction data to arrive with merchant IDs and category codes already applied.
Key Takeaways
What is a reconciliation API?
A reconciliation API compares records from bank transactions, ledger entries, and invoices to identify matching entries. Accuracy depends entirely on the quality of inputs. Unstructured bank data produces an unstructured exception queue. The algorithm is fine. The inputs are the problem.
Why does accurate reconciliation fail in practice?
Three data problems: missing payment references, generic bank description strings with no usable identifier, and batch-delayed transaction data arriving 12-24 hours after settlement. None are algorithm problems. All three are data infrastructure failures the matching layer cannot resolve downstream.
How does Open Banking AIS improve reconciliation API performance?
Open Banking AIS delivers per-payment bank data with merchant IDs and consistent references. When PIS embeds an invoice reference at initiation, that reference returns with the AIS confirmation. The reconciliation API receives a structured pair – outgoing reference matched to incoming – and resolves without manual intervention.
Why Do Reconciliation APIs Fail to Deliver Accurate Reconciliation?
What Does the Data Layer Look Like When Reconciliation Breaks?
The matching algorithm gets the blame. The data layer created the problem.
Three failure modes appear in almost every reconciliation API implementation that is underperforming:
Generic bank descriptions. A payment settles. The bank statement shows “FASTER PAYMENT RECEIVED 18:43.” The reconciliation API receives this as the transaction description. There is no merchant name, no invoice reference, no counterparty identifier. The algorithm compares it to 47 open invoices by amount and date. It finds three possible matches. A human resolves it.
At 20 transactions a week, this is a minor inconvenience. At 2,000, it is a finance team headcount.
Reference loss in transit. The payment platform embeds “INV-2024-031” as the payment reference at initiation. The payment routes through a correspondent bank. The bank re-formats the reference field. The receiving bank shows “0031” or nothing at all. The reconciliation API on the other side receives a bank credit with no usable reference.
The reference was never lost. It was stripped.
Batch-delayed transaction data. The reconciliation API queries the bank feed at 9am. The transactions it sees are from the previous day. A payment that settled at 4pm yesterday is not visible until this morning’s batch import. Finance teams reconcile on T+1 data while the business operates on current activity.
For accounting platforms that have built reconciliation workflows and want to understand how manual processes compound these data failures, the manual reconciliation automation solution guide covers how fragmented bank data creates the exception queues that manual reconciliation creates.
What Does a Reconciliation API Actually Need From the Data Layer?
How Does Bank Data Quality Determine Reconciliation Accuracy?
| Data Requirement | Unstructured Bank Data | Structured AIS Bank Data |
|---|---|---|
| Payment reference | Missing or stripped in transit through correspondent banks | Embedded at initiation, carried through to bank confirmation |
| Counterparty identification | Generic description string – “BACS CREDIT 441293” | Merchant ID at source – consistent across transactions and banks |
| Transaction classification | Manual categorisation required before matching can run | Category codes applied at source – classification pre-matched |
| Data timing | T+1 batch import – matching runs on yesterday’s transactions | Near settlement – reconciliation API receives current confirmed data |
| Data format consistency | Bank-specific – separate parsing logic per institution | Consistent JSON across banks – write matching logic once |
| Exception volume | High – algorithm cannot resolve unstructured inputs | Significantly reduced – structured inputs resolve more matches |
The column on the left describes the data that most reconciliation API implementations receive today.
The column on the right describes what the reconciliation API needs to perform accurately at scale.
The difference isn’t the matching algorithm. It’s the data layer that feeds the reconciliation API before the algorithm runs.
For accounting platforms evaluating how structured transaction data changes reconciliation workflows, the automated payment reconciliation UK guide covers how bank data quality affects automated matching accuracy in UK accounting platform deployments.
How Does Finexer Support Reconciliation API Workflows?
What Does Finexer’s AIS and PIS Provide for Accurate Reconciliation?
Finexer is not a reconciliation API. It doesn’t build matching algorithms, manage ledgers, or replace ERP systems.
Finexer provides FCA-authorised Open Banking AIS and PIS – the data infrastructure layer that reconciliation APIs use as input. When that input is structured, referenced, and delivered near settlement, the reconciliation API has what it needs to perform.
PIS – payment initiation with reference embedding:
- Pay by Bank via Faster Payments – invoice reference embedded at initiation, carried through to bank confirmation
- Bulk Payout – per-recipient references in a single API call, each confirmation carries its own reference
- Payment Links – per-invoice references pre-filled, removing the manual entry errors that break matching
- VRP for recurring payments – consistent reference per recurring cycle
- Pre-payment validation before funds move
AIS – Transaction and Invoice Tracker for reconciliation:
- Merchant IDs and counterparty data at source – consistent across almost all major UK banks
- Category codes applied at source – transaction classification before it reaches the reconciliation layer
- Consistent JSON format across banks – the reconciliation API writes matching logic once
- Per-payment bank transaction data near settlement – not T+1 batch
- Invoice and payment references from initiation through to bank confirmation
- Up to 7 years of transaction history for retrospective reconciliation and exception resolution
The reference that PIS embeds at payment initiation returns with the AIS bank confirmation. The reconciliation API receives a structured pair: outgoing payment reference matched to incoming bank transaction reference. The match resolves.
- Usage-based pricing, no setup fees, deployment measured in weeks
- FCA-authorised (FRN 925695)
For platforms building reconciliation workflows for multiple invoices and payers, the payment reconciliation for multiple invoices guide covers how per-payment references change the reconciliation workflow when payments arrive in bulk.
What I Feel
The reconciliation API market is full of platforms claiming high auto-match rates. Most of those claims are true under ideal conditions – clean data, consistent references, structured inputs.
The conditions in production are rarely ideal.
The honest version of the reconciliation API conversation is this: build the best matching algorithm you can, and then spend equal effort ensuring the data that feeds it is structured enough for the algorithm to work on.
Most platform teams spend 80% of their effort on the algorithm and 20% on the data layer. The exception queue reflects this.
“Accurate reconciliation is not an algorithm problem for most platforms I work with. The matching logic is fine. The data arriving at the matching layer is not. Fixing the data layer is less interesting work than improving the algorithm. It is also more consequential.” – Yuri, Finexer
Common Use Cases
Accounting SaaS Platforms
Accounting platforms using Finexer’s AIS deliver bank transaction data to the reconciliation layer with merchant IDs and category codes already applied. The reconciliation API writes one set of matching rules against consistent JSON – not separate parsing logic per bank. Exception volumes reduce when structured inputs replace generic bank description strings.
ERP and Finance Operations Systems
ERP systems reconciling supplier invoices against bank payments benefit from AIS transaction data with payment references embedded at initiation. Each bank confirmation carries the ID of the invoice it settles. The reconciliation API checks one field. The match resolves without manual investigation.
Payment Platforms
Payment platforms matching incoming credits to open receivables need per-payment reference continuity from initiation to confirmation. When Finexer PIS embeds the invoice reference and AIS returns it confirmed, the reconciliation API receives a reference pair that closes the match. For platforms processing high volumes, the reduction in exception handling time is meaningful.
Reconciliation and Treasury Systems
Treasury systems reconciling multi-bank cash positions benefit from AIS transaction data in consistent format across all connected banks. The reconciliation API applies the same matching logic to Barclays, Lloyds, Monzo, and Starling transactions – not separate logic per institution. For a structured view of how transaction categorisation supports reconciliation API accuracy.
The transaction categorisation guide covers how category codes and merchant identifiers reduce the pre-processing overhead that delays reconciliation.
What are the three types of reconciliation in finance?
Bank reconciliation compares bank statement entries against internal ledger records. Invoice reconciliation matches outgoing payments to supplier invoices. Intercompany reconciliation aligns transactions between entities within the same group. All three types depend on the same underlying requirement: structured transaction data with consistent references. A reconciliation API that receives inconsistent or delayed bank data produces exception queues across all three types.
How does API reconciliation work?
The reconciliation API queries bank transaction data and internal records – ledger, invoice system, payment platform – and runs matching logic to identify corresponding entries. Where references and amounts align, the match resolves. Where they do not, an exception is created for manual review. Structured bank data with consistent references significantly reduces the volume the algorithm cannot resolve.
How does Open Banking improve reconciliation?
Open Banking AIS delivers per-payment bank data with merchant IDs, category codes, and consistent references. When PIS embeds an invoice reference at initiation, that reference returns with the AIS bank confirmation. The reconciliation API receives a structured input pair – reference on both sides – and resolves without manual review. Settlement timelines vary by payment type and network routing.
See how Finexer supports reconciliation API workflows with structured bank transaction data, embedded references, and Open Banking AIS infrastructure.
About the Author
Yuri
Yuriy Yakushko is the Founder of Finexer, an FCA-authorised Open Banking platform that enables businesses to access real-time bank data and Pay-by-Bank payments through secure API infrastructure. With more than 20 years of experience in fintech and software engineering, he focuses on building scalable financial technology that helps businesses modernise payments and financial data workflows.