Every Monday morning, the same ritual: a treasury manager manually exports bank statements from five different banks, loads them into the ERP, spends two hours reconciling unmatched lines, and finally gets a cash position that reflects… last Friday. This is the day-to-day reality of many European mid-market companies in 2026 — even though the EU’s PSD2 regulation has made automatic daily synchronisation technically possible since 2018.
This guide explains how to connect your ERP to your bank accounts via Open Banking APIs in practice, which aggregators to choose based on your context, and what changes day-to-day operations — without conflating a regulatory obligation with an add-on service your banks charge as an option.
PSD2 and Open Banking: What It Means in Practice for Your ERP
PSD2 Explained in 3 Minutes for Finance Directors
The European Payment Services Directive 2 (PSD2), which came into force across EU member states from 2018 with Regulatory Technical Standards (RTS) fully applicable from 2021, requires banks to open customer account data to authorised third-party providers — provided the account holder has given consent. This principle is called Open Banking.
For a CFO or Finance Director, this means two things:
- Your bank can no longer block access to your own data. If you authorise an approved provider (your ERP, an aggregator, a treasury tool) to read your bank statements, the bank is legally obliged to expose that data via a standardised API. Billing this access as a paid optional service is contrary to the directive’s intent.
- Authorisation is the key. Providers that access bank accounts on your behalf must be registered as AISPs (Account Information Service Providers) or PISPs (Payment Initiation Service Providers) with a national regulator — the FCA in the UK, the ACPR in France, the BaFin in Germany, the DNB in the Netherlands. This is not a marketing label; it is a verifiable regulatory authorisation on public registers.
PSD2 does not give your ERP direct access to your bank accounts — it creates an ecosystem of authorised providers that can do so on your behalf. This is where banking aggregators come in.
From Weekly Manual Reconciliation to Daily Automated Synchronisation
Before PSD2, connecting an ERP to a bank required either manual file exports (OFX, CAMT.053) or heavy protocols like EBICS — relevant for large corporates with significant transaction volumes, but complex to deploy for a mid-market company with two or three banking relationships.
With PSD2 and aggregators, the process changes fundamentally:
- Your company mandates an AISP-authorised aggregator (Bridge, Powens, GoCardless, Tink, Salt Edge)
- The aggregator connects to your banks via their PSD2 APIs with your consent
- Transactions from all your accounts arrive in your ERP in a normalised format, multiple times per day
- The ERP applies automatic matching rules (invoice reference, amount, counterparty)
- Only unmatched exceptions are surfaced to the treasury manager for manual handling
The result: a J+0 cash position instead of J+3 to J+7 with manual statements. Short-term investment decisions, factoring, or arbitrage between credit lines can be made first thing in the morning based on actual figures — not estimates.
How the Bank-to-ERP Connection Works via PSD2
AIS APIs (Account Information Services): Reading Account Data
AIS is the building block of any bank synchronisation project. An AISP-authorised provider can, with your consent, access your payment account data: balances, transaction history, IBAN identifiers. Data is exposed in near real-time — with multiple updates per day depending on the bank.
For your ERP, AIS replaces OFX file exports and PDF statements: transactions arrive directly in the accounting module via the aggregator’s API, formatted to match your accounting entries.
AIS consent has a 90-day validity period under PSD2, renewable. In practice, most aggregators automate this renewal to avoid synchronisation breaks.
PIS APIs (Payment Initiation Services): Initiating Payments
PIS goes one step further: it allows an authorised PISP to initiate a payment from your bank account without using your bank’s own interface. In an ERP context, this opens the door to approving and executing supplier payments directly from the accounts payable module — without exporting payment files or logging into your banking portal.
At this stage, PIS remains less mature than AIS in standard ERP integrations. Most bank synchronisation projects start with AIS for reconciliation, and consider PIS in a second phase for bulk payment initiation. The Strong Customer Authentication (SCA) constraints imposed by PSD2 on payments add an authentication layer that complicates full automation.
Banking Aggregators: The Link Between Your Bank and Your ERP
Your ERP is not designed to manage the specific APIs of every European bank — there are several hundred of them. That is the role of banking aggregators: they maintain bank-by-bank connectors, handle PSD2 authentication, and expose a single normalised API to your ERP.
The architecture is straightforward:
ERP ←→ Aggregator API ←→ Your banks' PSD2 APIsThe aggregator manages the technical complexity (variability of PSD2 implementations bank by bank, SCA, consent renewal, error handling). Your ERP or your integrator handles a single data format.
EBICS vs PSD2: What’s the Difference for Mid-Market and Enterprise?
EBICS (Electronic Banking Internet Communication Standard) has been the de facto protocol for bank-to-ERP exchanges in France, Germany and Switzerland since the early 2000s. It remains dominant for large corporates with significant payment volumes and multi-signature approval workflows.
Comparison for a European mid-market company:
| Criteria | EBICS | PSD2 / AIS |
|---|---|---|
| Bank coverage | Excellent (major FR/DE/CH banks) | Pan-European via aggregator |
| Real-time | No — scheduled batch processing | Yes — multiple updates per day |
| Deployment | Heavy — bank-by-bank contract, certificates | Lightweight — via aggregator, days not months |
| Volumes | Best for high payment volumes | Suited for balance reading + single payments |
| Cost | Bank fees + infrastructure | Aggregator subscription (typically a few hundred €/month) |
| Multi-bank | Each bank = separate contract | Single aggregator connection |
For a mid-market company with two or three banking relationships, PSD2 via aggregator is generally faster to deploy and cheaper to maintain than EBICS. For a group with mass payment runs and complex approval workflows, EBICS remains relevant — and the two can coexist: EBICS for bulk payments, AIS for real-time balance monitoring.
ERPs with Native Open Banking Support in 2026
SAP S/4HANA: SAP Multi-Bank Connectivity and SWIFT
SAP offers its own banking connectivity solution: SAP Multi-Bank Connectivity (MBC). It centralises bank connections for S/4HANA and simultaneously supports SWIFT, EBICS, SFTP (Host-to-Host), and PSD2 APIs depending on connected partners. Bank statements arrive in camt.053 and camt.054 format — the ISO 20022 XML standards that S/4HANA processes natively.
SAP MBC is relevant for groups wanting a SAP-native solution, but note that SAP is not a SWIFT reseller — companies using SWIFT connectivity through MBC must separately subscribe to the SWIFT network and obtain their own BIC. For mid-market companies outside of international groups, a third-party aggregator (Tink, Salt Edge) connected to S/4HANA via API is often a lighter-weight alternative.
Microsoft Dynamics 365 Finance: Native Bank Connectors
Dynamics 365 Finance includes an advanced bank reconciliation module with import of bank statements in standard electronic formats (BAI2, MT940, camt.053). PSD2 connectivity is handled via third-party connectors — Tink is a Microsoft partner and integrates natively into the Azure/Power Platform ecosystem. Synchronised statements feed directly into the treasury journal and automatic reconciliation rules.
Odoo 17/18: The Bank Synchronisation Module (Salt Edge, Ponto)
Odoo has offered a native bank synchronisation module since version 13, with no custom development required. Configuration is done from the accounting dashboard and typically takes less than a day for covered banks. Natively connected providers are Salt Edge (global coverage), Ponto (Europe, strong for Belgian and French mid-market companies), and Enable Banking (Nordic countries) (source: Odoo 18.0 documentation, Bank synchronisation).
Synchronisation runs automatically every 12 hours by default, with the option to trigger it manually at any time. It is the most accessible Open Banking implementation on the market for an SME or mid-market company already running Odoo.
Sage X3 and Access Group: Bank Reconciliation Modules
Sage X3 and Access Financials both support bank statement import in standard formats and offer automated reconciliation modules. PSD2 connectivity typically runs through integration partners or third-party connectors. Sage has partnered with treasury fintech tools (Agicap, Kyriba) whose bank connections enrich the financial module’s data.
NetSuite: Bank Feeds and Electronic Bank Payments
Oracle NetSuite offers two complementary features: Bank Feeds for automatic statement synchronisation (via authorised providers depending on country), and Electronic Bank Payments for payment initiation. European coverage of Bank Feeds varies by country — check with your NetSuite partner for your specific banks.
European Banking Aggregators: Overview
Bridge (formerly Bankin): Leading French AISP, ACPR-Authorised
Bridge is the historically leading French aggregator, spun out of the Bankin app. It covers all major French banks and is AISP-authorised by the ACPR. Bridge is widely used by French B2B fintechs and accounting firms. Its API is well documented and B2B pricing is negotiable based on volume. Worth checking: coverage of regional banks and specific business accounts before signing.
Powens (formerly Budget Insight): Strong in B2B and ERP Integrations
Powens is specialised in B2B use cases — bank reconciliation, treasury, fraud detection. Its positioning is less consumer-facing than Bridge, which translates into a more integrator-oriented API. Powens also offers enriched features around transactional data (categorisation, normalisation) that simplify downstream ERP work.
GoCardless (formerly Nordigen): Pan-European, Open API
Nordigen, acquired by GoCardless, offers a pan-European Open Banking API covering more than 2,300 financial institutions in 31 countries (source: OpenBankingTracker, European PSD2 aggregators). Its positioning leans more toward recurring payments than account monitoring, but the geographic coverage is a key advantage for groups with subsidiaries across several European countries.
Tink (Visa): European Coverage, Microsoft Partner
Tink, acquired by Visa in 2022, is one of the aggregators with the broadest European coverage. Its Microsoft partnership makes it the natural choice for Dynamics 365 environments. Tink supports both AIS and PIS across the majority of EU countries.
Salt Edge: Global Reach with Strong Odoo Presence
Salt Edge stands out for its global coverage (over 50 countries) and its native integration into Odoo. It is the simplest option for a company already on Odoo that wants to activate bank synchronisation without custom development.
Tangible Benefits: What Changes Day-to-Day
Bank Reconciliation: From 4 Hours per Week to 15 Minutes
The most immediate gain is reduced reconciliation time. Before automated synchronisation: export statements, import into ERP, manually match unrecognised lines. After: transactions already arrive in the ERP, automatic matching rules handle 85 to 95% of lines depending on rule quality. The treasury manager only handles exceptions. Real-world feedback from companies that have deployed this type of solution (Odoo + Salt Edge, Dynamics 365 + Tink) consistently points to an 80 to 90% reduction in manual reconciliation time — a figure consistent with the nature of the gain, though every context is different.
Treasury Forecasts: J+0 Visibility Instead of J+7
With daily bank balance synchronisation, the ERP’s cash forecasting module works from actual, current data — not estimates or figures several days old. Building a reliable 30- or 90-day forecast becomes possible as soon as the opening position is certain.
Early Anomaly Detection
An automated transaction feed allows you to configure alerts on unusual patterns: transfers to new beneficiary IBANs, transactions above a threshold, duplicate payments. These controls, difficult to perform manually on weekly statements, become automatable as soon as bank data is in the ERP in near real-time.
Implementation: Steps and Pitfalls to Avoid
Deployment Steps
Step 1 — Account inventory. List all business banks and accounts to synchronise, including current accounts, term deposits, and corporate cards if managed in your ERP. Verify your target aggregator’s coverage of these specific banks before signing.
Step 2 — Aggregator selection. Compare bank coverage, regulatory certifications (ACPR, FCA, BaFin, DNB depending on your countries), SLA levels, and pricing models. An aggregator already partnered with your ERP reduces integration work. If you have banks across several European countries, prioritise a pan-European provider like GoCardless or Tink.
Step 3 — Reconciliation rule configuration. The quality of automatic matching rules directly determines the match rate. Work with your integrator to model your transaction patterns: invoice references, typical amounts by supplier, recurring bank statement descriptions.
Step 4 — Training and validation. Train treasury teams on the new workflows. Plan a parallel run period (manual + automatic reconciliation simultaneously) of 2 to 4 weeks to validate rules before full cutover.
Key Pitfalls
GDPR and banking data. Banking data is sensitive financial data subject to GDPR requirements. Your contract with the aggregator must include a GDPR-compliant DPA (Data Processing Agreement) specifying retention periods, encryption measures in transit and at rest, and any sub-processors. If your organisation has a DPO, involve them from aggregator selection. For a deeper look at the GDPR framework within your ERP, read our complete guide to GDPR compliance for ERPs.
PSD2 scope. PSD2 covers payment accounts as defined by the directive — not necessarily all business bank accounts. Check with your bank which accounts are exposed via the PSD2 API and which remain outside the scope (term deposits, escrow accounts, etc.).
Avoiding double reconciliation. If you maintain an external treasury tool (Agicap, Kyriba, Cashforce) alongside your ERP, ensure you do not have two competing bank synchronisation feeds creating duplicate entries. Define a single system of record.
PSD3 on the Horizon: What Changes for ERPs (2027–2028)
The European Parliament and Council reached a political agreement on PSD3 and the new Payment Services Regulation (PSR) at the end of 2025 (source: OpenBankingTracker, Open Banking in 2026). PSD3 will strengthen several points that matter to IT and finance teams:
- Improved API quality. PSD2 opened APIs in principle, but implementation quality varies significantly bank by bank. PSD3 should impose stricter performance and availability standards.
- Extended access rights. PSD3 should broaden the data accessible via Open Banking beyond payment accounts, potentially including savings and credit data.
- Enhanced security. New SCA requirements and stronger anti-fraud mechanisms are expected.
For IT and finance teams, the message is clear: bank synchronisation projects launched under PSD2 will be forward-compatible with PSD3 — PSD3 improves the framework without dismantling the Open Banking architecture. Anticipate consent updates and potentially new features from your aggregators during 2027.
To go further on treasury management in your ERP, read our complete guide to ERP treasury and real-time cash flow management and our ERP treasury comparison: CMS, SWIFT and cash forecasting for CFOs.
