Most finance teams running multi-bank reconciliation assume their bank statement feeds speak one language. They don't. Walk into almost any mid-sized company pulling statements from more than two or three banking relationships and you will find two coexisting formats: MT940, a SWIFT standard that predates the euro, and camt.053 (BankToCustomerStatementV13), the ISO 20022 XML schema that was supposed to replace it. The replacement never fully happened. It is 2026, and plenty of SME-serving banks still issue MT940 as their primary or only statement export. Any reconciliation system that assumes a single format is building on a false premise.
This is not a cosmetic difference. MT940 is a flat, positional text format with terse tag codes. camt.053 is structured XML with explicit fields for currency, value date, and transaction classification. A reconciliation engine built to parse one will choke, silently or loudly, on the other. The practical fix is not elegant: a format-detection layer at ingestion that routes each statement to the right parser before anything downstream touches it. Teams that skip this step usually discover the gap the hard way, when a bank quietly migrates one account to a new export format mid-quarter and matching rates drop without anyone understanding why until someone opens the raw file.
Underneath the format problem sits a currency identification problem that is easy to underestimate. ISO 4217's three-letter currency codes are supposed to be the canonical layer every downstream calculation depends on. In practice, symbol-based or free-text currency references still leak into statement data, especially from older banking interfaces, and that ambiguity propagates into every FX calculation that follows. A transaction marked with a dollar sign is not a currency code. Enforcing ISO 4217 at the normalization stage, before any matching logic runs, is one of the cheapest controls available and one of the most frequently skipped.
Once statements are normalized, the actual matching work has a known, measurable limit. Deterministic matching, exact rule-based pairing of invoice to payment, is reliable and auditable but has a hard ceiling. A 2022 academic benchmark (Czekaj et al., arXiv:2205.10678) found that layering machine learning entity-matching on top of deterministic rules raised recall from roughly 78% to over 90% at 99% precision. That is a meaningful jump, but the study is a single-company, single-currency dataset and has not been peer-reviewed. It demonstrates what ML-assisted matching can do under favorable conditions, not what it will do across multi-currency, multi-format, multi-bank data with FX timing drift and netted payments. Treat the number as a ceiling to aim for, not a guarantee.
What that gap means operationally is an exception queue. At an illustrative volume of 10,000 transactions a month, the difference between a 78% and a 90% match rate leaves over 1,000 lines a month in manual review. That is not a rounding error. It is a headcount-sized workload that most finance teams absorb quietly rather than measure, which is exactly why reconciliation automation projects get approved on optimistic assumptions and then stall six months in when the exception queue turns out to be the real cost center.
The accounting layer adds its own structural trap, one that catches teams reconciling across US and EU entities in particular. IAS 21 (the IFRS standard most EU entities follow) requires monetary items to be retranslated at the closing rate each reporting date, with FX differences hitting profit or loss. US GAAP's ASC 830 draws a different line: translation differences for a foreign subsidiary go to other comprehensive income, while remeasurement of monetary items in a non-functional currency hits the income statement directly. These are not two ways of describing the same mechanics. They are structurally different postings with no clean one-to-one mapping. A reconciliation system built for a single-entity, single-framework environment will post FX differences in the wrong place the moment a second accounting framework enters the picture, and the error will not surface until an auditor asks why the numbers do not tie.
There is also a vendor-risk dimension that is easy to miss until a regulator asks about it directly. Under DORA (Regulation (EU) 2022/2554, directly applicable since January 2025), any reconciliation vendor handling your ICT infrastructure needs to sit in a register of information, with contractual provisions covering SLAs, data location, audit rights, and an exit strategy. EBA/GL/2019/02 adds a proportionality-based test for whether the outsourced reconciliation function counts as "critical or important," which in turn determines how much documentation and exit planning is mandatory. Teams that treat reconciliation tooling as a plug-and-play SaaS purchase, rather than a regulated third-party arrangement, are building a compliance gap that does not show up until an audit or a vendor failure forces the question.
The sequence that actually works, based on what we have seen hold up across multi-entity engagements, runs in four layers. First, statement ingestion with dual-format detection, so MT940 and camt.053 are both handled without assumption. Second, normalization that enforces ISO 4217 currency codes and retains both the transaction-date FX rate and the period-end FX rate as separate fields, because collapsing them loses information you need later for IAS 21 or ASC 830 postings. Third, a matching engine that runs deterministic rules first and routes only the residual tail to ML-assisted matching, rather than trying to force one model to do both jobs. Fourth, a posting and handoff layer that flags each transaction with the correct entity's reporting framework before it reaches the general ledger, so IFRS and GAAP postings never get mixed.
None of this ships well on a big-bang rollout. The realistic path is staged trust: a full shadow-mode cycle before anything auto-posts, an assisted mode where deterministic matches post automatically but ML and exception matches get human review, and full automation only after the system has survived a complete quarter-end or year-end FX retranslation cycle without manual correction. For a multi-currency, multi-entity group, a realistic timeline from regulatory and vendor due diligence through parallel run sits around four to seven months, not the weeks a sales deck might imply.
The teams that get burned are the ones that buy a reconciliation tool as if it were a single technical decision. It is a format-handling decision, a currency-data-quality decision, an accounting-framework decision, and a regulatory third-party-risk decision, all stacked on top of each other. Skipping any one layer does not make the problem go away. It just moves the cost from the implementation budget into the exception queue, the audit finding, or the vendor contract you signed without reading the DORA clause.