Articles educational

Open Banking for Reconciliation

Open banking can replace some statement downloads with consent-based access to payment-account data, supporting more frequent reconciliation. It does not itself match invoices, guarantee identical fields across banks, or prove data completeness. Reliable implementation requires regulated access, consent management, pagination, status handling, source controls, monitoring, and a fallback process.

Open banking reconciliation uses consent-based account-information access to retrieve bank balances and transactions for reconciliation workflows. In the European context, PSD2 created rules for account information service providers (AISPs) and access to payment-account information. Open banking is the data-access channel; reconciliation is the accounting control performed with that data.

This distinction prevents three common overstatements. Open banking does not automatically identify the invoice behind a payment, standardise every bank’s descriptions, or prove that an accounting ledger is complete.

The regulatory and operational chain

A typical flow involves:

  1. a business user authorises access to selected payment accounts;
  2. a regulated provider or its technical service connects to the account-servicing bank;
  3. the provider retrieves available account and transaction information;
  4. the reconciliation application stores or processes that information under its agreed role and purpose;
  5. matching and control logic compares it with invoices or ledger data;
  6. finance users review exceptions and retain evidence.

The European Commission states that PSD2 applies to payment services and laid groundwork for open banking. It also describes the policy work to revise the framework through PSD3 and a Payment Services Regulation. Check the current legal status rather than describing proposals as already applicable law. See the Commission’s payment services page.

The EBA’s PSD2 materials cover account-information access and security requirements. Strong customer authentication and applicable exemptions influence user journeys and continuity; they are not reconciliation controls. See the EBA interactive single rulebook and its technical standards material on authentication and secure communication.

Data useful for reconciliation

Depending on the bank and provider, a transaction may include:

  • provider and bank identifiers;
  • booked or pending status;
  • signed amount and currency;
  • booking and value dates;
  • debtor or creditor name and account information;
  • structured and unstructured remittance;
  • bank transaction codes;
  • end-to-end or proprietary references.

Treat every field as conditionally available. A mapper should preserve the original payload, distinguish absent from empty values, and record source and retrieval time. Normalised reference text and customer mappings belong in derived fields.

Enable Banking’s official API reference illustrates relevant integration mechanics: its account-transactions endpoint supports date ranges, transaction-status filtering and continuation keys for pagination. Those documented features apply to that API; actual bank data and behaviour can vary by connection.

Completeness cannot be assumed

An API returning HTTP success does not prove a complete accounting population. Controls should test:

  • all expected accounts and currencies are present;
  • requested dates overlap safely around previous successful retrieval;
  • every continuation page is processed;
  • retries do not create duplicates;
  • pending-to-booked lifecycle changes are handled;
  • opening and closing balances roll forward where data permits;
  • transaction counts and signed sums reconcile across processing stages;
  • late or amended entries are captured;
  • consent or connection failures trigger alerts.

Retain a controlled statement-import fallback. During an outage or expired authorisation, finance still needs to close and prove the source.

Do not describe an open-banking connection as “read-only” without verifying the contracted service and permissions. Account information and payment initiation are distinct services, but a provider or application may support one or both. Document the actual scope requested and granted.

Finance and technology teams should know who the regulated provider is, which accounts are covered, how users authorise access, how access is revoked, where data is processed, and how incidents are handled. Open-banking regulation does not certify the reconciliation application, its matching quality or its wider security controls.

Example architecture

Consider an SMB with three euro accounts. A connector retrieves booked transactions on a schedule. The ingestion service stores raw responses, validates schema, follows pagination and deduplicates lifecycle events. A reconciliation service compares incoming credits with issued invoices and presents supported candidates. Finance confirms ambiguous links. Separately, accounting compares each bank closing balance with its ledger balance and manages fees, supplier payments and timing items.

This separation keeps responsibilities clear:

  • connector: authorised access and retrieval;
  • ingestion: completeness, lineage and normalisation;
  • matching: candidate and allocation logic;
  • accounting: posting, policy and account-level sign-off;
  • review: challenge, evidence and exception ownership.

Implementation checklist

  • Verify the provider’s regulatory role and service scope.
  • Map consent, renewal, disconnection and fallback journeys.
  • Test every supported bank and account type with representative data.
  • Preserve transaction status, all dates, currency and raw references.
  • Implement pagination, retries, idempotency and monitoring.
  • Compare raw-to-processed counts and signed totals.
  • Keep matching evidence visible and uncertain items unmatched.
  • Test reversals, duplicates, missing fields and late bookings.
  • Define retention, access, deletion and incident procedures.
  • Reconcile bank balances to the ledger independently.

In Invunion

Invunion alpha is intended to support issued-invoice and incoming-bank-transaction matching. Any open-banking availability, provider relationship, bank coverage, history depth, refresh behaviour, consent flow and field availability must be verified for the current alpha release.

Do not infer universal European bank coverage or uninterrupted feeds. Integration partners should design against documented, tested interfaces and keep a fallback import process. Finance teams should review matching output and continue full bank-to-ledger reconciliation outside Invunion unless that separate capability is explicitly confirmed.

Sources

Updated

Was this article helpful?

Feedback helps us improve the next version of this article.

Tell us what is missing