A customer authorises a Pay by Bank payment and returns to your application. The payment API has accepted a resource, a callback may arrive seconds later and the beneficiary account entry may appear through another data path. Finance still needs to know which obligation was paid, which ledger entry to post and which differences require investigation.
Each signal answers a different question. Reconciliation joins them into one defensible financial outcome. At enterprise scale, that work needs durable identifiers, explicit evidence rules and a control process that can prove every expected record was considered.
The design should begin with the decision your teams need to make: when can a payment be treated as received for fulfilment, customer balance, cash reporting and accounting? One answer may be inappropriate across every product. The evidence required to release digital access may differ from the evidence required to ship high-value goods or close a finance period.
Set the evidence threshold before designing the data flow
Open Banking Limited's current Payment Initiation API Profile separates three kinds of status. The HTTP status describes the API operation. The payment-consent status describes authorisation. The payment-order status describes initiation or execution. The profile also allows a Payment Initiation Service Provider (PISP) to retrieve the payment-order resource after submission.¹
Your reconciliation policy should map these external states to business actions. Define the minimum evidence for each action before choosing fields, queues or dashboards. A useful policy might specify:
- when the customer sees a confirmation or pending message;
- when fulfilment may proceed;
- when an accounts receivable item can be cleared;
- when cash can be recognised under the organisation's accounting policy;
- when a payment moves to suspense; and
- when an operator must contact a provider, bank or customer.
Record who approved each threshold and which products, banks, payment types and values it covers. A provider's normalised 'complete' label remains an input to that policy. The team should know the underlying status, source and timestamp that support it.
Our guide to an open banking payment state machine explains the per-payment evidence model. Reconciliation extends that model across the commercial order, beneficiary account and general ledger. It also adds batch completeness, financial ownership and period controls.
Build one canonical reconciliation record
Create a canonical reconciliation record for every expected payment. This record becomes the join point between systems while each source retains its own native identifiers and history.
The record should carry:
- the customer, order, invoice, subscription or obligation identifier;
- the internal payment and payment-attempt identifiers;
- the provider, PISP, account servicing payment service provider (ASPSP) and API version;
- the consent identifier and payment-order resource identifier;
- the idempotency key and a hash of the submitted instruction;
- the amount, currency, creditor account reference and remittance information;
- raw payment statuses, reasons, sources and observed times;
- any payment transaction identifier supplied by the bank or provider;
- beneficiary account entry identifiers and booking or value dates where available;
- the journal, ledger account, legal entity and accounting period;
- match state, evidence level, exception reason, owner and resolution history; and
- the policy and mapper versions used for each decision.
Store external evidence as append-only observations. A later status can supersede the operational meaning of an earlier one while the earlier record still explains what the platform knew at that time. Retain both the event time and the local observation time. This helps teams reconstruct a late callback, delayed account feed or period-end cut-off.
The canonical record should reference source payloads through controlled storage rather than copying sensitive data into every downstream system. Finance needs durable evidence and traceability. It rarely needs every authentication or consent field in the accounting platform.
Carry identifiers from commercial intent into the payment request
Reconciliation quality is set before the payment starts. Generate stable internal identifiers when the commercial obligation and payment attempt are created. Carry the appropriate reference into the payment instruction, provider metadata or structured remittance fields, within the supported field rules and customer-display requirements.
Version 4.0.1 defines 'PaymentTransactionId' as a unique and immutable identifier within the servicing institution. It also defines structured remittance information for matching an entry to an item such as a commercial invoice.¹ These fields can improve deterministic matching when an ASPSP and provider support them. Your internal payment identifier still matters because external identifiers may appear later, vary between resources or remain absent in a particular implementation.
Use an identifier map rather than one overloaded reference. The customer-facing reference, internal attempt ID, provider payment ID, consent ID, bank transaction ID and ledger journal ID serve different owners and retention periods. Link them explicitly and prevent one value from being silently replaced by another.
Open Banking Limited's guide for businesses identifies automated invoice and payment matching as a practical use case.² Achieving that outcome depends on reference quality, consistent propagation and disciplined exception handling. A free-text invoice number with ambiguous formatting will produce weaker automation than a validated stable reference linked to a known debtor, amount and obligation.
Keep payment evidence in distinct layers
A reliable design evaluates three evidence layers.
The first layer is commercial intent. It describes what the customer owes, which entity should receive it, the amount, currency and permitted payment window. It answers the question the finance ledger ultimately cares about.
The second layer is payment execution evidence. It contains the consent, payment-order resource, status history, reason codes and provider observations. It establishes what happened in the Open Banking payment flow.
The third layer is beneficiary account evidence. It describes the credit visible to the receiving account or another confirmed bank record. This layer may arrive through account information, a provider service or a separate treasury feed. Its availability and freshness depend on the chosen service, bank coverage, consent and contractual evidence.
Join the layers through the canonical record and preserve their separate meanings. Payment submission can support a customer-facing pending state. A later execution status may meet the fulfilment policy. Beneficiary account evidence can close a cash match. The exact progression belongs in the approved policy for the product.
This separation prevents a finance report from treating a customer redirect as cash evidence. It also prevents an account credit with an unclear reference from being assigned automatically to the wrong obligation.
Combine event delivery with active retrieval
The Event Notification API Profile allows a third party to receive a signed resource-update notification containing identifiers and links for retrieval. It also states that real-time push notifications are optional for ASPSPs and third parties.³ A reconciliation design therefore needs two evidence paths.
The event path provides low-latency awareness. Store the incoming event durably, validate it, acknowledge it within the agreed timeout and process it asynchronously. Deduplicate by a stable event identifier where available. Retrieve the referenced resource and apply state changes through one transition function.
The active path looks for evidence that may have been missed. Schedule status retrieval for payments that remain in transitional states beyond their expected window. Run account or provider reports for the relevant time period. Compare expected payments, observed status changes, account entries and ledger postings.
Both paths should converge on the same canonical record and transition rules. This prevents a callback consumer and a batch job from posting competing outcomes. Use database uniqueness constraints and idempotent commands around financial side effects, including fulfilment, customer balance updates and journal creation.
Treat retry policy as part of the data contract. Record the retry reason, attempt, previous observation and result. A transport timeout may leave the remote result uncertain. The safe recovery is evidence retrieval under the same payment identity, followed by a policy decision based on the returned resource.
Match deterministically and preserve uncertainty
Build matching rules as an ordered hierarchy. Exact identifiers and validated structured references should have the highest confidence. Amount, currency, account, date and payer details can narrow candidates, while they should rarely create a final match alone when several obligations could share those values.
A practical hierarchy can use:
- an exact internal reference carried through the payment and returned with the bank or provider record;
- an immutable payment transaction identifier linked to the known payment-order resource;
- validated structured remittance information linked to one open obligation;
- a unique composite of legal entity, beneficiary account, amount, currency and bounded time window; and
- a scored candidate sent to human review when deterministic evidence is unavailable.
Every rule needs a version, scope and recorded explanation. Keep the source values used to reach the result. If two items satisfy the same deterministic rule, create an ambiguity exception instead of accepting the first database row.
Probabilistic matching can help rank candidates for an operator. It should preserve an approval boundary for financially consequential assignments unless the organisation has validated a confidence threshold, false-match tolerance and audit process. False positives can be more damaging than an item that remains visibly unmatched.
Post to the ledger through an explicit policy
The reconciliation service should propose or execute ledger actions according to an approved posting matrix. Map evidence level, payment type, value, legal entity and exception state to a permitted journal action.
For example, a platform may post a receivable clearance after a specified payment-order status and place the amount in an in-transit account until beneficiary evidence arrives. Another service may retain the obligation as open until the receiving account entry is matched. The correct treatment depends on accounting policy, contractual terms and the customer promise.
Use balanced journals and immutable references between the reconciliation record and ledger entry. Corrections should use reversal or adjustment entries under the finance policy, preserving the original posting and reason. A replayed event should return the existing journal result through its idempotency key.
GOV.UK Pay's public technical guidance shows how its own service combines references, custom metadata, event history, settlement information, reporting APIs and finance-system imports for reconciliation.⁴ Its card-provider settlement model differs from Open Banking payment status. The reusable lesson is the explicit link between payment data, financial identifiers, event history and the receiving finance process.
Prove completeness across batches and time
Individual matches can all be correct while the daily process remains incomplete. Add controls that prove the expected population was processed.
Use a watermark for every input stream, recording the latest complete event time or source period. Track counts and values across expected payments, submitted resources, terminal statuses, beneficiary entries, matched items, ledger postings and exceptions. Reconcile by legal entity, currency, beneficiary account and processing date.
The July 2026 Open Banking dashboard reports just over 13.5m failed API calls, equal to 0.46% of reported calls, with business and technical failures separated.⁵ These figures describe account-provider API calls across the reporting population. They do not measure failed payments. They show why a small percentage can still produce a large operational population and why reconciliation should retain reason categories and completeness checks.
Control totals should explain movement between stages. If 100 payments worth £25,000 entered the period, the close should show how many and how much are matched, pending within policy, rejected, reversed, duplicated, assigned to suspense or awaiting evidence. A balanced count without a balanced value can hide a partial or duplicate record.
Handle late arrivals explicitly. Keep a period open for operational matching under the finance timetable, then carry unresolved items into an aged suspense population. When later evidence resolves an item, apply the approved subsequent-period treatment and preserve the original observation history.
Give every exception an owner and a clock
An exception queue is part of the control architecture. Each item needs a reason category, value, age, priority, evidence summary, owner and next action. Route it to the team able to resolve the cause.
Useful categories include:
- payment status missing beyond the expected window;
- beneficiary credit absent or unavailable;
- duplicate payment evidence;
- amount, currency, account or reference mismatch;
- one bank entry matching several obligations;
- reversal or return after an earlier posting;
- provider and bank evidence disagreeing; and
- ledger posting failed after the payment outcome was established.
Give operations a complete evidence panel. It should show raw statuses, identifiers, times, prior retries, account evidence, ledger entries and the policy that created the exception. Provide controlled actions such as retrieve status, request replay, link to an obligation, move to suspense, reverse a journal or escalate.
Separate investigation from approval where the financial risk warrants it. Record the person, reason and evidence for every manual resolution. Repeated manual overrides should feed a rule-quality review, because they may reveal a bank-specific mapping change, missing reference, product defect or training gap.
Test the reconciliation process under failure
Happy-path sandbox payments demonstrate connectivity. Reconciliation acceptance needs failures that cross system boundaries. Include scenarios where:
- the customer returns before the payment reaches a usable state;
- the submission times out after the bank has accepted the payment;
- a callback arrives twice or after status retrieval;
- callbacks stop while payment resources continue to change;
- a provider sends events out of order;
- the bank omits a conditional identifier or remittance field;
- two payments share the same amount and customer reference;
- the beneficiary account entry arrives after the operational cut-off;
- a ledger write fails after the match is committed; and
- a mapping or API version changes while payments remain in flight.
Assert the customer outcome, canonical record, ledger effect, retry behaviour and exception state for each scenario. Then rerun the same event set to prove idempotency. The open banking provider RFP scorecard explains how to turn these tests into comparable supplier evidence and contractual acceptance criteria.
Measure financial control performance
API uptime and latency remain useful operating measures. Reconciliation needs measures tied to money and resolution.
Track the percentage and value matched automatically, time from payment initiation to the approved evidence level, time to beneficiary match, exception rate, unreconciled value, oldest unresolved item, suspense balance, false-match corrections and manual touches per thousand payments. Segment by bank, provider, payment type, API version, legal entity and deployment version.
The earlier Asima article on Open Banking API quality provides the performance context. Reconciliation measures show how interface behaviour becomes financial work. A rising exception age at one bank may be more important to cash operations than a small movement in the aggregate response-time average.
Set thresholds and escalation routes for count, value and age. A single high-value unresolved payment may require immediate attention even when the daily automatic match rate remains strong. Publish the measures to engineering, payments operations and finance so all three teams work from the same evidence.
Make reconciliation evidence portable
Provider selection should include the fields, histories and exports needed to reconstruct a financial outcome. Ask for raw bank status, normalised status, reason codes, timestamps, identifiers, callback history, retrieval access, retention periods, replay facilities and bulk exports.
Define who can access evidence during an incident and after contract termination. Retain your canonical identifiers and journal references independently of the provider dashboard. Test whether the provider can reproduce an unresolved payment without relying on one specialist or an unexportable interface.
The wider enterprise checklist for open banking integration places reliability, security, commercial predictability and developer delivery in the same buying decision. Reconciliation turns several of those qualities into observable operating outcomes.
Design reconciliation as a shared operating control
Open banking payment reconciliation succeeds when product, engineering, payments operations and finance agree on the evidence behind each business action. The canonical record connects their systems. The posting policy defines permitted outcomes. Completeness controls prove the population was processed, and the exception queue keeps uncertainty visible until it is resolved.
Start with one payment journey and one beneficiary account. Map every identifier, state transition, evidence source, journal action and exception owner. Test missing and contradictory signals before increasing volume. That foundation supports faster automation because every automatic decision remains traceable to the evidence and policy that authorised it.
Footnotes
- Open Banking Limited, Payment Initiation API Profile v4.0.1. Open the technical specification
- Open Banking Limited, How open banking payments in and out can help businesses. Open the business guide
- Open Banking Limited, Event Notification API Profile v4.0.1. Open the technical specification
- GOV.UK Pay, Reconcile and report on payments. Open the technical guidance
- Open Banking Limited, July 2026 API performance statistics. Open the performance dashboard