Open Banking for Reconciliation

Short answer

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. New to the terms? Start with What Is Open Banking?.

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 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 follows the architecture above for incoming payments and the invoices you issued.

StepIn Invunion
ConnectorEnable Banking, a licensed account information provider. You approve the access on your bank’s page. The banks offered depend on the country, the provider and whether the Entity is sandbox or production.
First retrievalThe previous 90 days. The bank may return less.
RefreshNewer lines are synced on their own while the consent is valid.
ConsentRequested for up to 180 days. After that, someone with the bank login connects the account again.
MonitoringNotification rules can alert members, Slack or Microsoft Teams when a bank sync fails or a bank is disconnected.
FallbackStatement downloads over EBICS, camt.053, MT940, CSV and JSON statement files, automatic statements over SFTP, or the API.
Bank detailsIBANs and account numbers are stored encrypted and shown masked; a full number is shown only to admins, and logged.
MatchingMatch levels (Certain, Strong, Possible); unclear pairs wait in the Match inbox.

Two checks stay with you. Compare each bank closing balance with your ledger outside Invunion, since Invunion matches transactions to invoices and does not reconcile the general ledger. And check the date of the last sync on each account, because a connected bank does not always mean every account synced.

To try a connection without a real account, a sandbox Entity includes test banks: see Connect the test bank.

Sources

Updated