Germany’s E-Rechnungspflicht, ZUGFeRD, and the EU’s ViDA initiative are pushing structured invoicing into every finance department, and ISO 20022 is doing the same for payment messaging. Neither format was built to carry remittance detail all the way to the general ledger, which is why match rates barely move after e-invoicing rollouts. Transformance closes that gap with ClearMatch, using vision language models and persistent memory to read and reconcile remittance data regardless of which system it arrives through.
Key Takeaways
- E-invoicing formats (XRechnung, ZUGFeRD, ViDA) structure the invoice. They do not carry payment or remittance data.
- ISO 20022 structures the payment message, but structured remittance fields are frequently empty, truncated, or ignored by the originating bank.
- Most remittance detail still arrives separately, by email, customer portal, or PDF, no matter how compliant the invoice or payment message is.
- Straight-through matching needs an AI layer that reconciles invoice, payment, and remittance data across formats, something neither mandate provides on its own.
- Transformance’s ClearMatch reads remittance data as it arrives (PDF, EDI, email, bank portal) and reconciles it against the ERP without template configuration.
In This Article
- What Is Cash Application Automation?
- The Regulatory Push: E-Invoicing Mandates Across Europe
- What Does ISO 20022 Actually Structure?
- Why E-Invoicing and ISO 20022 Together Still Don’t Automate Matching
- Where Does Remittance Data Actually Come From?
- How AI-Native Cash Application Closes the Gap
- Comparing the Approaches
- Frequently Asked Questions
- Conclusion: Compliance Projects Will Not Fix Your Match Rate
What Is Cash Application Automation?
Cash application automation is the use of software, typically AI-driven, to match incoming customer payments against open invoices and post the result to the ERP without manual intervention. It requires three things to line up: the payment itself, the invoice it settles, and the remittance advice that tells the system which invoice, or invoices, the payment covers.
Most AR teams already automate the easy part. Payments that arrive with a clean, exact reference number match themselves through basic rules. The hard part, and the part that consumes analyst hours, is everything else: split payments, short pays, deductions bundled into a single wire, and remittance data that shows up in a different system than the payment.
This is where the e-invoicing conversation gets misapplied. Finance leaders hear “structured data” and assume matching gets easier. It only gets easier for the invoice side of the equation.
The Regulatory Push: E-Invoicing Mandates Across Europe
Germany’s E-Rechnungspflicht began phasing in on January 1, 2025, when B2B businesses had to be able to receive structured electronic invoices in formats like XRechnung and ZUGFeRD. The obligation to issue those invoices phases in from 2027, with larger companies first. The EU’s broader ViDA (VAT in the Digital Age) initiative extends similar mandates across member states, with digital reporting requirements for cross-border transactions phasing in later this decade.
These mandates are genuinely useful. They cut invoice processing errors, speed up accounts payable workflows, and give tax authorities real-time visibility into transactions. According to Deloitte (2023), finance teams running e-invoicing compliance projects report faster invoice approval cycles and fewer data entry errors on the AP side.
What these mandates do not touch is the AR side of the transaction, specifically how the payment gets matched once it arrives. Deloitte’s same research notes that e-invoicing compliance projects rarely include cash application or reconciliation workflows in scope. The invoice gets structured. The payment that eventually settles it does not.
What Does ISO 20022 Actually Structure?
ISO 20022 is a global messaging standard for financial transactions that structures the data fields banks use to communicate payment instructions, balances, and remittance information between institutions. Unlike e-invoicing, which governs the document sent from seller to buyer, ISO 20022 governs the message sent from bank to bank once the buyer pays.
The standard includes fields specifically designed to carry remittance information, such as invoice references, alongside the payment itself. In theory, this should make cash application easier. In practice, adoption of those specific fields lags far behind adoption of the standard itself.
Cross-border payment messaging on SWIFT completed its migration to ISO 20022 (CBPR+) in November 2025, formalizing the standard across the correspondent banking network. But according to Gartner (2024), remittance-carrying fields within ISO 20022 messages remain optional, and originating banks frequently truncate or omit them entirely, especially for domestic and lower-value transactions. A structured message with an empty remittance field solves nothing for the AR team on the receiving end.
Why E-Invoicing and ISO 20022 Together Still Don’t Automate Matching
Even a company that has fully adopted XRechnung on the invoice side and receives ISO 20022 payment messages on the banking side will not see straight-through cash application as a result. Four structural gaps explain why.
- The two standards were written for different audiences. E-invoicing formats were built by tax authorities and accounting standards bodies to satisfy VAT compliance. ISO 20022 was built by banks and payment networks to standardize interbank messaging. Neither working group set out to solve receivables matching, so the handoff between the two was never designed.
- Remittance data routinely travels outside both channels. According to IOFM (2023), more than 60% of B2B remittance advices are sent separately from the payment itself, arriving by email, customer self-service portal, or fax, well after the structured invoice and well outside the structured payment message.
- Structured fields get populated inconsistently. A bank might support ISO 20022’s remittance fields technically while its corporate customers, or intermediary banks in the chain, strip or shorten that data before it reaches the beneficiary. The standard exists; the discipline to use it consistently across every counterparty does not.
- Rules-based matching plateaus regardless of upstream structure. According to McKinsey (2023), straight-through reconciliation rates for large enterprises using traditional rules engines plateau around 70 to 75%, even in environments with structured invoicing already in place. The remaining volume needs judgment, not just data.
Ardent Partners (2024) found that the average AR team still spends more than 15 hours per week manually matching payments to invoices, a figure that has moved little as e-invoicing adoption has climbed. Structuring the invoice did not touch the bottleneck.
Where Does Remittance Data Actually Come From?
Remittance data most often arrives through channels that neither e-invoicing nor ISO 20022 controls: emailed remittance advices, customer AP portals, EDI 820 transactions, and bank lockbox files. Each format looks different, and the same customer may use two or three of them depending on which system generated the payment run.
This is the practical reason legacy cash application tools struggle. They rely on OCR and regex rules tuned to specific document layouts, so a new customer, a new ERP version, or a slightly reformatted remittance template breaks the match rate until someone rebuilds the template. Our guide to agentic AI for cash application covers why that template-per-format model was always a temporary fix, not a real solution.
Controllers feel this gap directly during month-end close, when unmatched cash sits in suspense accounts and analysts chase down remittance detail manually before the books can close. It’s one of the recurring frustrations we hear about in conversations on what controllers actually want from AI automation: not another dashboard, but fewer unresolved items at close.
How AI-Native Cash Application Closes the Gap
Transformance built ClearMatch around a simple premise: remittance data will keep arriving in whatever format the customer’s system produces, regardless of what e-invoicing or ISO 20022 mandate. Rather than waiting for standardization that will never fully arrive, ClearMatch reads the document as it is.
ClearMatch uses vision language models (DocSense) to read remittance advices, emails, EDI files, and bank portal downloads, extracting invoice references, amounts, and payment details with 99.7% accuracy on structured data and 96.6% on complex, multi-column tables. It does this without template configuration, so a new customer’s remittance format is read correctly on first contact, not after weeks of manual mapping.
Matching itself runs across three layers. Deterministic rules handle roughly 70% of matches (exact amount, reference, and date). Machine learning pattern matching resolves another 25%, covering partial payments, splits, and timing differences. The remaining 5%, the cases legacy tools route straight to a human queue, get investigated by an AI agent using persistent memory of the customer’s past resolutions, seasonal patterns, and formatting quirks.
That persistent memory layer is the mechanism that improves match rates over time. Deployments typically start around 85% auto-match and climb to 95% or higher within 90 days, automatically, without a consulting engagement or manual retraining cycle. This is the structural answer to the gap that e-invoicing and ISO 20022 leave open: an intelligence layer that reconciles invoice, payment, and remittance data regardless of which format each one arrives in.
For teams thinking about cash application as one piece of a broader order-to-cash automation strategy, it’s worth reading our overview of order-to-cash and where AI fits across the process, since matching rarely improves in isolation from collections and deductions work happening downstream.
Comparing the Approaches
The table below lines up what each approach actually structures, how it handles remittance data in practice, and what that means for match rates and rollout time.
Frequently Asked Questions
Does XRechnung automate cash application?
No, XRechnung structures the invoice document for VAT compliance but does not carry payment or remittance data. Matching a payment to the invoice it settles still depends on remittance detail that XRechnung never touches, which is why AR teams see no change in match rates after adopting it.
What is the difference between e-invoicing and ISO 20022?
E-invoicing standardizes the document sent from seller to buyer before payment, while ISO 20022 standardizes the message sent between banks once payment is made. They cover different stages of the transaction, and neither was designed with receivables matching as the primary use case.
Will ISO 20022 fix remittance matching on its own?
No, because the remittance fields within ISO 20022 messages are optional and frequently left blank or truncated by originating banks. Gartner (2024) documented how inconsistently these fields are populated, and the SWIFT CBPR+ migration completed in late 2025 standardized the message format without making the remittance fields mandatory.
What percentage of remittance data arrives separately from the payment?
More than 60% of B2B remittance advices arrive separately from the payment, according to IOFM (2023), typically by email, customer portal, or another out-of-band channel rather than embedded in the payment message itself.
Does ViDA change how invoices are matched to payments?
No, ViDA focuses on real-time digital VAT reporting and cross-border invoice structuring, not on the payment or remittance side of the transaction. It will make invoice data more consistent across the EU, but matching still depends on what happens after the invoice is issued.
How does AI-native cash application close the gap that e-invoicing leaves open?
AI-native platforms like Transformance’s ClearMatch read remittance data directly from whatever format it arrives in, PDF, email, EDI, or bank portal, using vision language models instead of template-based OCR. Combined with persistent memory of each customer’s payment patterns, this closes the reconciliation gap that neither e-invoicing nor ISO 20022 was built to solve.
Conclusion: Compliance Projects Will Not Fix Your Match Rate
E-invoicing and ISO 20022 are worth adopting on their own terms: cleaner invoices, faster AP cycles, standardized bank messaging. Neither was designed to solve cash application, and treating either mandate as an automation project for AR sets up finance teams for a plateau they will not see coming until month-end close proves it.
Closing that gap takes a matching layer built to read remittance data as it actually arrives, not as regulators eventually intend it to. If your team is still reconciling manually despite structured invoicing and modern payment rails, it’s worth a conversation about where the actual bottleneck sits. Book a call with Transformance to walk through what ClearMatch would look like against your own remittance formats.
