Every month-end, the same ritual plays out at mid-market manufacturing companies: the accountant manually downloads statements from five bank accounts, imports them one by one into the ERP, spends the first two days clearing unmatched lines, and delivers a reliable cash position on Wednesday evening. The CFO waits until Thursday to make investment decisions. Four days lost, every month, on a task that technology can reduce to a few hours.
In 2026, automatic match rates of 80 to 95% are achievable for well-equipped SMEs and mid-market companies. This guide covers the three methods to get there, the bank format that changes everything (CAMT.053), and how to configure matching rules in the major ERP platforms.
This guide complements our article on open banking and PSD2 bank connectivity which covers how to establish the connection between your banks and your ERP. Here, we go into the matching mechanics on the ERP side.
Why Manual Bank Reconciliation Remains a Bottleneck in 2026
3 to 5 Days Lost Per Month: The Real Benchmark
Companies still relying on manually exported bank statements spend an average of 3 to 5 working days per month on bank reconciliation, based on benchmarks reported by ERP integrators. For a mid-market company with 8 to 15 active bank accounts, multiple currencies, and transaction volumes above 500 lines per month, this delay mechanically extends the monthly close.
For context, best-in-class companies close their monthly accounts in 6 working days versus 12 days for the average, according to EY analysis of financial close practices. Bank reconciliation is consistently identified as one of the highest-leverage areas for improvement.
The Classic Matching Errors
Three types of discrepancies appear in every context:
Payment duplicates. A supplier paid by SEPA credit transfer and by cheque on the same day generates two lines on the bank statement for a single entry in the ERP. Without a deduplication rule, both lines surface as exceptions.
Value date differences. The debit date at the bank differs from the accounting date of the invoice. For standard SEPA transfers (next day) and instant payments (seconds), the gap can range from zero to several days depending on the banks involved. Without date tolerance in the matching rules, the ERP fails to recognise the transaction.
Unstructured payment references. In older bank formats (MT940), remittance information is limited to 390 characters of free text, often poorly populated. “SEPA TRANSFER SUPPLIER REF 2024-INV-00892” can become “STP SUPPL 892” depending on the sender’s bank. The reconciliation module finds no match.
The Impact on Monthly Close and Cash Visibility
An unfinished bank reconciliation at day one of the close delays the entire chain: treasury position validation, customer receipt confirmation, real working capital calculation. The management controller cannot reliably forecast 30-day cash flow until all bank accounts are reconciled. The result: investment decisions (placements, factoring, credit line drawdowns) made on day-minus-four data rather than current-day figures.
The 3 Automation Methods Available in 2026
Method 1: Native ERP Module with Automatic Matching Rules
Every ERP on the market includes a bank reconciliation module. The power of that module depends on the number and sophistication of configurable matching rules.
A typical matching rule works in a cascade: the ERP first checks whether the exact amount and invoice reference match an open item. If yes, it reconciles automatically. If not, it drops to the next level: exact amount with a date tolerance of plus or minus two days. At the bottom of the cascade: amount within a plus or minus £0.50 / €0.50 range for FX rounding.
With a basic configuration, ERPs reach an automatic match rate of 80 to 85%. After 90 days of rule adjustment, that rate climbs to 90 to 95% (Agicap, guide to ERP bank reconciliation automation). The remaining 5 to 20% represent genuine exceptions: partial payments, disputes, inter-company discrepancies, and foreign-currency transfers with conversion differences.
Method 2: PSD2 Open Banking for Real-Time Bank Feeds
Open banking (PSD2 directive) allows your ERP or an authorised aggregator to automatically retrieve your bank statements multiple times per day, without manual export. In practice, instead of waiting for your team to download an OFX or CAMT.053 file each morning, transactions flow into the ERP continuously.
This method improves two separate things. First, data freshness: the treasury position reflects day zero rather than day minus one or two. Second, data quality: some aggregators normalise bank references before injecting them into the ERP, improving reference recognition rates.
For major European banks, PSD2 APIs are operational but with varying levels of data richness. Some banks only expose the balance and the last 90 days of transactions; others deliver complete remittance details. Integration quality depends on the bank, not on your ERP.
Method 3: Specialist AI/ML Tools for Complex Cases
For companies with high volumes (above 5,000 transactions per month), multiple currencies, or multi-entity structures, dedicated tools complement the native ERP module. The main players are Tesorio (focused on treasury and collections), HighRadius (order-to-cash and AR reconciliation), and Serrala (SAP-integrated, strong on mass payments).
These tools use machine learning to learn the matching patterns specific to each company: if supplier X consistently pays invoices three days late with a truncated reference, the model learns to recognise it within a few weeks. Their positioning is as a complement to the ERP module, not a replacement.
CAMT.053 vs MT940: The Bank Format That Changes Everything
The 390-Character Limit of the Legacy Format
Automatic match quality depends directly on the richness of the bank data received. MT940, a format inherited from the 1980s and still used by many European banks, limits remittance information to 390 characters of free text in the :86: field. That field is populated inconsistently across banks.
CAMT.053 (ISO 20022), its successor, uses structured XML with no size limit. It explicitly separates counterparty data (name, IBAN, BIC), the structured payment reference (end-to-end ID, reference), and remittance details. Each transaction can carry multiple sub-transactions with their own references — essential for bulk payments (one transfer covering ten invoices).
According to Deutsche Bank’s analysis of the CAMT format, reconciliation automation rates approach 100% with CAMT.053, compared to frequent manual interventions with MT940 for non-standardised transactions. The difference comes from the structured end-to-end reference: instead of a truncated free-text description, the ERP receives a unique, machine-readable reference.
Enabling CAMT.053 at Your Bank
The good news: most European banks have offered CAMT.053 since 2021–2022, but it is not enabled by default on all contracts. Two approaches to activate it:
Via the business banking portal. Most major banks allow you to configure the export format for statements directly in their online banking platform (look for “account statements”, “exchange formats”, or “API” sections). Request CAMT.053.001.06 or CAMT.053 ISO 20022.
Via your relationship manager. If your bank uses the EBICS protocol for file exchanges (common for larger companies with high transaction volumes), ask your relationship manager to enable the CAMT.053 version on your EBICS contract. This change typically requires no contract amendment — just a reconfiguration on the bank’s side.
Important: enable CAMT.053 in your ERP at the same time. Most ERPs support both formats, but you will need to update your connectors or import settings accordingly.
Configuring Matching Rules in the Major ERPs
SAP S/4HANA: Electronic Bank Statement
In SAP S/4HANA, bank reconciliation runs through transaction FEBAN (Electronic Bank Statement). Bank statements are imported as CAMT.053 or MT940 files, then processed according to search algorithms configured in the bank account management module.
Search algorithms (Search Strings) are priority rules that tell SAP how to interpret the reference field on the bank statement. For example: “if the reference field contains a 10-digit value starting with 11 or 12, treat it as a customer invoice number — search open AR items.” SAP applies these rules in the configured order, automatically reconciles when a match is found, and generates an exception item otherwise.
For companies with high volumes or a need for multi-bank connectivity, SAP offers the Bank Communication Management (BCM) and Multi-Bank Connectivity (MBC) modules, both available as paid add-ons. An alternative for mid-market companies cautious about SAP add-on costs: route through a Treasury Management System (TMS) such as Kyriba or TIS, which bridges the banks to SAP.
Oracle ERP Cloud: Native Cash Management
Oracle Cash Management (included in Oracle ERP Cloud) is one of the most comprehensive reconciliation modules on the market for mid-market and enterprise companies. It imports bank statements in CAMT.053, BAI2, or MT940 and applies configurable matching rules without development effort.
Oracle matching rules follow a priority logic: the system first attempts an exact match (amount, currency, reference), then tries tolerance-based matching with configurable thresholds on amount (absolute or percentage) and date (plus or minus N days). Oracle also supports grouping rules to match a single bank transaction against multiple accounting entries — useful for bulk payments.
Oracle’s key strength: matching rules are fully configurable in the interface, with no code required. A trained CFO or ERP administrator can create and modify rules directly.
Microsoft Dynamics 365 Finance: Bank Reconciliation Worksheet
In Dynamics 365 Finance, bank reconciliation is handled through the Bank Reconciliation Worksheet screen. Statement import supports BAI2, MT940, and CAMT.053 formats.
The matching rules functionality in D365 Finance allows you to define automatic matching criteria: exact or tolerance-based amounts, date ranges, document references, or markers in the description field. Rules are applied in configured priority order.
D365 Finance also offers matching rule sets, which group multiple rules into scenarios: a “customer receipts” set with its own priority logic, a “bank charges” set to recognise recurring fees, and so on.
Sage X3 and Business Central: Capabilities and Limits
Sage X3 includes a bank reconciliation module with statement import and configurable matching rules. The module covers the needs of an industrial mid-market company with euro accounts and a few foreign currency accounts. For multi-entity structures or very high volumes, Sage X3 may require custom development or a third-party connector (for example, a dedicated banking middleware integrated into the configuration).
Microsoft Dynamics 365 Business Central offers bank reconciliation suited to SMEs, with good automation levels for organisations with two to five bank accounts. Its limitations emerge on complex multi-bank configurations, multi-currency reconciliation with significant conversion differences, and unstructured bulk payments. For companies on Business Central, complementing with an open banking aggregator (TrueLayer, Token.io, or similar) significantly improves match rates by enriching incoming bank data.
How to Measure Your ROI and Take Action
Before configuring anything, measure your current situation. Two metrics are enough:
Current automatic match rate: over your last three months of reconciliations, how many lines were automatically matched by the ERP versus processed manually? If you are below 70%, there is significant improvement potential through rule reconfiguration alone, without launching a full integration project.
Monthly time spent on reconciliation: measure your team’s actual time on this task, from statement import through to final exception clearance. This is your ROI baseline.
A 5-Step Implementation Checklist
-
Audit volumes and patterns: identify the 5 to 10 transaction types generating the most manual exceptions. These reveal the missing matching rules.
-
Check CAMT.053 compatibility with your banks: contact your relationship manager or check the business banking portal. If your banks support CAMT.053, enable it before anything else. The data richness gain immediately improves match rates.
-
Configure matching rules in priority order: start with simple cases (exact amount plus reference) before adding tolerance-based rules. Do not enable overly wide tolerances from the start — you risk generating false matches.
-
Set alerts for unreconciled exceptions: configure an automatic alert if an item remains open more than three days after the bank value date. This avoids month-end backlogs of accumulated exceptions.
-
Measure your auto match rate at day 30 and adjust: compare your rate after the first month with the new rules. Identify residual patterns and add specific rules. After 90 days, the match rate should stabilise between 90 and 95%.
For a mid-market manufacturing company with £100M+ turnover and 8 to 12 active bank accounts, this type of approach typically brings monthly reconciliation time down from 3 to 4 working days to a few hours. The real gain is not just accounting productivity: it is the day-zero cash visibility the CFO gains for real-time management decisions.
Two complementary articles on the same CFO/controller audience:
- Our monthly ERP close checklist from day minus 5 to day plus 3 for industrialising the entire close process, of which reconciliation is a central component.
- Our article on AP automation and generative AI for supplier invoice processing to automate the other side of the flow: incoming supplier invoices in the ERP.
- For groups with multiple entities, our guide on cash pooling and ERP covers inter-entity reconciliation, notional pooling, and zero balancing.
