Across Europe and parts of Latin America, the way invoices move between businesses is changing. Instead of emailed PDFs, many countries are shifting to structured electronic invoice formats that are transmitted system-to-system. By 2026, these models will be active in most of the EU, and similar patterns are appearing globally.
This is meaningful progress. It reduces fraud, increases transparency, and lowers the administrative burden of receiving invoices.
But there is a belief spreading alongside it:
“Once invoices are electronic, invoice processing becomes automatic.”
However, this is not how it will unfold in real estate. In reality, the work will not disappear. It will simply move.
Historically, invoice processing has been slowed down by the way invoices arrive:
Someone had to find them, open them, key in amounts, clean up formatting issues, and chase missing information. It was repetitive work and prone to mistakes.
Structured invoicing solves that part of the process: invoices arrive in a consistent, machine-readable format. No inbox sorting. No OCR. No copy-paste. And this is progress.
But capturing the invoice has never been where real estate AP earns its keep.
The Hard Part Isn’t Reading the Invoice; It’s Understanding It
Once the data is received, accounting teams still need to answer context-based questions:
These are not data extraction questions. They are judgment questions. And judgment questions require:
No structured invoice format includes this context. Not Peppol. Not UBL. Not KSeF. Not SDI. Not CFDi. Not NF-e. This means that, while the capture workload decreases, the coding workload remains.
And for many organizations, it becomes even more visible.
Real estate accounting is fundamentally context-driven:
This nuance doesn’t live in the invoice; it lives in the building, the ownership structure, and the financial model.
That’s why OCR didn’t solve coding, and e-invoicing doesn’t either. The complexity isn’t in the file. It’s in the business logic layered behind it.
Structured invoicing will roll out unevenly.
Large national vendors and corporate suppliers will adopt it early; local trades, building engineers, seasonal vendors, and project-based contractors will not.
This means AP teams will operate in a dual environment for several years:
PDF → Extraction → Coding
XML → Retrieval → Coding
Notice that the right side of these workflows are exactly the same. The coding layer must be unified, or operational complexity rises rather than falls.
The complexity grows more obvious when we look at operators with global footprints, as the experience will not be unified across regions. Global companies will see operational differences depending on where exactly their teams operate:
That is potentially six different invoice entry models in the same organization. But the solution is not to force everything into one format. The solution is to accept all formats, but interpret them through one shared accounting logic layer.
A single coding workflow.
A single approval framework.
A single posting approach.
Regardless of how the invoice arrives.
The organizations that transition smoothly will:
This is not “automate everything;” this is “automate the parts that should be automated, and clarify the parts where judgment still matters.”
It is a shift from manual handling to informed oversight.
E-invoicing changes how invoices arrive; it does not change what finance teams must understand about them.
Retrieval is plumbing; coding is intelligence.
And real estate runs on intelligence.
For readers who want to explore the regulatory background and phased rollout of e-invoicing across Europe and globally, the following resources provide helpful detail and ongoing updates:
Poland is a strong example of how structured invoicing centralizes invoice transmission and audit traceability, while coding decisions remain organization-specific.
This helps frame how e-invoicing fits into the larger shift toward real-time/transaction-level reporting, especially under ViDA (VAT in the Digital Age).