E-Invoicing in Europe: What Real Estate Finance Leaders Need to Know Now (2026 Update)

By David Stifter, Founder and CEO of PredictAP. David spent 20 years in real estate and finance, most of it at Colony Capital, before founding PredictAP, which automates invoice coding for real estate AP teams on Yardi, NexusPayables and MRI. Updated September 2026; originally published November 2025.

Direct answer: E-invoicing in the EU for real estate is now mandatory in the major markets covered here: Belgium, Poland, France and Italy, and for receiving in Germany. For real estate finance leaders, the compliance part is the easy part. The hard part is that e-invoicing networks were built for tax visibility, not for routing or coding: they match on a VAT number and assume one entity, one receiver, and one-to-one coding, while real estate runs on shared entities, third-party managers, and property-level allocations. E-invoicing solves invoice retrieval. It does not solve invoice coding, and firms that treat it as if it does plug one hole and open another.

Definition: E-invoicing is the issuing, transmission and receipt of invoices as structured, machine-readable data (typically XML that follows a national implementation of the European EN 16931 semantic standard) through a government platform or certified network such as Peppol, rather than as a PDF or paper document. In real estate AP, an e-invoice still has to be routed to the right entity, property, and responsible party, then coded to GL account, cost category, VAT treatment, and recoverability before it can be posted.

What changed since November 2025?

Last November I wrote that e-invoicing mandates across the European Union were accelerating and that real estate finance teams needed to get ready. Ten months later, “get ready” is over. Belgium went live in January. Poland’s KSeF hit large taxpayers in February and most other businesses in April, with the smallest firms following in January 2027. France’s reception requirement took effect on September 1. Germany’s issuing mandate starts in January 2027.

Since that first article, we’ve stood up e-invoice intake for both owners and third-party property managers in several of those countries. This update covers what the country factsheets don’t tell you. We have learned a number of real world lessons on how this actually works particularly when integrating the Retrieval platforms to Yardi or Nexus (MRI). Below we will go through the lessons learned.

The networks do what they were built to do, and what they were built to do is fiscal. Their purpose is to give tax authorities a structured, near-real-time view of what businesses bill and pay, so VAT is visible and collected. The European Commission puts VAT that was legally due but not collected at about €128 billion for 2023, and it expects digital reporting built on e-invoicing to claw back a meaningful share of that. Getting the invoice to the right desk inside the buyer’s business, and coding it, was never the design goal.

So the retrieval side is built the way OCR and other generic capture tools are built: industry-agnostic. It assumes that matching on a VAT number (the EU’s equivalent of an EIN) identifies the right recipient and the right vendor, and that a one-to-one vendor-to-GL default is enough coding. Those assumptions hold for a business with a straightforward ownership structure. A manufacturing firm has one or a few legal entities, one chart of accounts, and vendors that bill one entity for one thing; a VAT match and a vendor default get the invoice most of the way. Real estate is built differently. A portfolio is dozens or hundreds of legal entities, often one per asset, with joint ventures, funds and management agreements layered on top. One invoice splits across entities and properties; the same expense codes differently depending on the property, the lease, and whether it’s recoverable, capital or operating (more on why the same expense gets different GL codes at different properties); and VAT treatment varies by line. None of that is on the XML. It fails hardest for third-party service providers, who receive on behalf of many downstream clients and can’t use a VAT number to sort by client, by property, or even by vendor once one vendor has several remit-to addresses. That gap is what this article is about.

Why is the EU mandating electronic invoicing?

A PDF or paper invoice can be audited, but it can’t be read by a tax authority as structured, transaction-level data in anything close to real time. Closing that gap is the point: less VAT fraud, better tax compliance, and less manual reconciliation on both sides. Business-to-government e-invoicing has been required for public procurement in most member states for years; the B2B mandates extend that to everyone, and the VAT in the Digital Age (ViDA) package requires e-invoicing and digital reporting for covered cross-border B2B transactions from July 2030, based on the European e-invoicing standard. Each member state sets its own domestic timeline, which is why the rules differ from one country to the next.

The bigger shift is what an invoice is. It’s no longer a document you look at. It’s structured data your systems process, and so are the credit notes that come with it. That changes the AP job from handling paper to validating data and managing exceptions.

Which countries have mandatory e-invoicing in 2026?

Here is where selected major real estate markets stand. Status checked September 29, 2026 against the European Commission’s eInvoicing country factsheets, the Commission’s ViDA adoption notice, the French government’s e-invoicing directory announcement, and the mandate trackers listed under Sources. Regulatory dates move; confirm with the relevant tax authority before you build a plan around one.

EU B2B e-invoicing mandates in major real estate markets, January 2025 to July 2030. Status checked September 29, 2026.

This isn’t the whole map. Romania has run a domestic B2B mandate since 2024, and Greece, Croatia and others are phasing in. Spain and Portugal are in the table because the pattern there is different: Spain’s mandate is enacted but hasn’t started its clock, and Portugal regulates the invoice without mandating a network, which is its own kind of work for AP. If you have legal entities in more than one of these countries, you’re already living in several regimes at once. That’s the first operational problem. It isn’t the biggest one.

Which invoice formats are required: structured or hybrid e-invoices?

Two kinds: structured XML sent through a platform or network, and hybrid files that pair a readable PDF with embedded structured data. Not every member state has the same legal requirements, and firms operating across multiple countries need to receive electronic invoices in both forms.

Structured e-invoices are machine-readable XML transmitted through a government platform or a certified network. In Poland, an invoice that didn’t go through KSeF isn’t a valid invoice for VAT purposes, no matter how many times it was emailed. Same idea in Italy with SdI.

Hybrid e-invoices pair a human-readable PDF with embedded structured invoice data. Factur-X in France and ZUGFeRD in Germany work this way. Your systems process the structured data; the PDF is there so a person can read it.

In every market that adopts a structured B2B mandate, plain PDFs become a shrinking share of compliant invoice exchange. If your approval workflow depends on someone opening a PDF, you’ll be running that workflow for a shrinking share of your volume, and a second one for everything else.

Why is e-invoicing in the EU harder for real estate?

Because the networks deliver invoices to a registered address, and real estate is run by property, by manager, and by client. Three things get treated as one here, and they aren’t: the legal entity that owes the money, the invoice address that entity registers on the network (in Peppol terms, the participant endpoint), and the receiver attached to that address. In the implementations we’ve worked through, most entities register one address, keyed to their VAT or registration number. The vendor sends the e-invoice to it, the network resolves the receiver, and everything for that entity lands in one queue. The rules often allow more granular addressing. Almost nobody sets it up.

Turns out that’s the problem. Three ways it shows up:

Whoever registers first gets everything. In the Peppol-based rollouts we’ve been through, everything sent to an entity’s registered invoice address goes to the receiver attached to it. If a property manager registers a client’s entity, with one address, to receive e-invoices for the one building they manage, every invoice sent to that address now routes to that manager: the owner’s other buildings in the same entity, the ones a different manager runs, the lender’s fees, the corporate costs. The owner doesn’t see any of it. Nobody designed it that way. It’s what happens when the identifier is the entity and the entity is shared.

In early rollouts, we analyzed the e-invoices arriving at a third-party manager’s payments team in the first weeks. Roughly half belonged to external property managers, not the team receiving them. Another large share couldn’t be assigned to anyone from the data on the invoice alone. Only a small fraction clearly belonged to the team whose inbox they landed in. That’s a payments team spending most of its day forwarding other people’s mail.

The statutory identifiers don’t map to how real estate is run. Real estate runs at the property level: every system, every report, every recovery calculation. The networks deliver by legal entity and stop there, and even for a single owner, one legal entity usually maps to several property codes in the accounting system. France is the interesting case. Its directory lets an entity receive at three levels: the SIREN (the nine-digit legal entity), the SIRET (SIREN plus a five-digit establishment identifier), or an internal routing code for a specific service. That’s closer to a property identifier than anything else on an e-invoice, and it’s worth using. But an establishment is not a property, the vendor has to address the invoice to the right one, and we’ve watched two teams inside the same company interpret the same SIRET differently. Useful. Not a routing rule.

Vendor identification is one-dimensional. The networks identify a vendor by a single registration ID. If your landscaping contractor has three remit-to addresses across three regions, or a national utility bills from different bank accounts by service territory, that nuance collapses to one vendor record on the way in. Your AP team spent years getting remit-to right. The network doesn’t know that. The same goes for invoices that start life outside the ERP, like acquisition costs that originate in a deal system: the network has no idea they’re different from a repair bill.

What is different for third-party property managers and fund administrators?

Third-party property managers and fund administrators receive e-invoices on behalf of clients whose entity registrations they don’t control, so every routing problem with e-invoicing hits them harder than it hits an owner.

Say you manage one office building for an owner whose entity holds twenty. If that entity has one registered invoice address, its e-invoices go to one recipient. If that’s you, you’re now the front door for nineteen buildings you don’t manage. If it’s someone else, your invoices are sitting in their queue. The mandate didn’t create a routing process. It created a routing problem and handed it to whoever was there first.

What we’ve seen work:

1. Put a front door in front of the network. Every incoming e-invoice is classified before it’s coded: to your payments team, an internal property team, an external manager, or back to the owner. The classification uses everything on the XML (VAT number, SIRET, vendor, amounts, references) plus your own history, and it holds anything it isn’t confident about for a human.
2. Treat the entity-to-responsible-party mapping as a living document. Portfolios change hands. The building you manage in January may belong to a different manager by June. Whoever owns that mapping has to update it without an IT ticket.
3. Make redirect a one-click, audited action. When an invoice isn’t yours, someone sends the PDF and the XML to the right party, rejects it out of the queue, and leaves a trail. If that’s a manual download-attach-email loop, it won’t happen consistently, and the invoice goes into limbo.
4. Ask the network for multiple lanes per entity. Some providers are starting to discuss separate registrations for a treasury lane, an internal PM lane, and an external PM lane. It’s early and not standard. Ask anyway.

Does e-invoicing solve invoice coding?

No. E-invoicing solves retrieval. The invoice shows up as structured data, in a folder, on time, with the header fields populated. That’s real progress over a PDF in someone’s inbox, and I don’t want to undersell it.

It helps to see where it sits. The real estate AP chain used to be capture, code, workflow, payment. E-invoicing adds a step at the front: retrieval, capture, code, workflow, payment. It adds a step. It doesn’t remove one. The mandate governs retrieval, and retrieval only.

It does not solve coding. Most e-invoicing solutions handle coding one of two ways: a one-to-one default from vendor to GL account, or reading a PO number off the XML and copying the PO’s coding onto the invoice. That’s fine for a company that buys office supplies. It’s an industry-agnostic tool doing an industry-agnostic job.

Real estate invoice coding isn’t one-to-one anything. A €20,000 electric bill for a mixed-use asset gets split across three properties, capitalized on one and expensed on the others, tagged recoverable for every tenant except the one who negotiated out of the CAM pool, and carries a VAT rate and a transaction type that vary by line. The vendor is the same vendor every month. The coding isn’t. (If you want the full anatomy, I wrote up what a fully coded invoice actually contains.)

So when the e-invoice lands with a vendor-default GL on it, your AP team is still doing the work, just in a different screen. And if the default gets posted without review, you’ve turned a data entry problem into a financial reporting problem, which is worse.

That’s the risk of meeting the mandate by skipping the coding step: you push it downstream, where it’s expensive. A recoverable expense coded non-recoverable is money you don’t bill back to tenants, and you find out at CAM reconciliation, months later, if you find out at all. A capital item expensed, or the reverse, moves NOI. A wrong VAT or transaction type is input tax you don’t reclaim. Every one of those starts as a coding decision at AP, which is why recovery problems start at AP, not at year-end. E-invoicing doesn’t cause any of this. It just makes it faster to post an uncoded invoice.

This is the pattern I keep seeing: a firm plugs the retrieval hole and opens the coding hole. Invoices arrive faster and cleaner, and the coding that used to happen at capture, with a person looking at the invoice, quietly stops happening at all. Predicting the coding, at the line level, from the firm’s own history, is still required. It was required before e-invoicing, and structured invoices actually make it easier, because the coding model gets clean data instead of a scanned PDF. That’s the upside nobody’s talking about. I wrote more on why the change is real but the work isn’t going away shortly after the first version of this piece.

How do e-invoices reach your AP workflow?

Four ways: email forwarding, an SFTP pull, an API, or a direct import into the ERP. The mandate says vendors must send structured e-invoices; it doesn’t say how those invoices get from the network into your AP process, and each path has a catch.

Whichever path you use, the rule doesn’t change: the e-invoice enters the same front door as every other invoice, gets routed, gets coded, and gets reviewed the same way. Running a parallel process for e-invoices doubles your workflows, your exceptions, and your training burden every time AP staff turn over.

How should e-invoicing fit with Yardi, NexusPayables or MRI?

Use the e-invoicing partner you prefer for retrieval,, but decide separately where coding and review happen, and insist that whatever sits between the network and the ERP is natively integrated with it. Otherwise you trade a coding gap for an integration gap.

Here’s a setup many Yardi and Nexus shops are being offered now. The ERP vendor partners with an e-invoicing network. The network receives the invoice for your legal entity and delivers it straight into the ERP’s payables module as a new invoice register. In the direct-import configurations we’ve seen, if the XML references a PO the ERP copies the PO’s coding onto the invoice, and if it doesn’t the invoice carries the vendor default. Configurations vary by ERP and partner, but either way it’s in the system in seconds.

Say that’s a €20,000 electric bill landing in PayScan. The header is perfect: vendor, date, number, total, VAT. The GL is the vendor default. The property is whatever the entity was mapped to in that configuration. Nobody looked at it, and the review your team used to do at capture, with the invoice on the screen, now has to happen after the fact inside the ERP, one invoice register at a time, by someone who has to notice it’s wrong. Most real estate operating expense isn’t on a PO, so the PO shortcut doesn’t rescue you.

There are three ways to wire this. The differences that matter are where coding happens, where review happens, and whether you’ve created a second system of record:

The first column is what the mandate makes easiest, and it’s the retrieval-solved, coding-not-solved outcome from the section above, delivered straight into your ledger.

The second column is the one I’d warn about most. When a firm realizes the direct path skips coding, the reflex is to put something in the middle: a capture tool, an inbox, a file drop. If that something doesn’t write into PayScan or Nexus natively, through the ERP’s API, respecting its vendor master, property lists, VAT and transaction types, and approval workflow, you’ve built a second system of record held together by exports. It works until it doesn’t, usually during close.

The third column is the only one where the e-invoice gets the same treatment as every other invoice: routed, coded, reviewed, then handed to Yardi through its API as a fully coded Yardi invoice register that PayScan approves like everything else (the same holds for NexusPayables and MRI). Native integration isn’t a feature here. It’s the whole point.

What should real estate AP teams do now?

1. Inventory your legal entities by country and find out who registered each one on which network. Start with the national e-invoicing directory where one exists (France’s is public), then your tax adviser and your current provider. If you don’t know, that’s your first finding.
2. For every shared entity, understand who is responsible for which properties and who should receive what. Then find out where those invoices are actually landing today.
3. Decide how you’ll handle invoices that aren’t yours: who redirects, how, and how it’s logged. This is a Critical step and requires communication to external parties.
4. Treat vendor-default coding on an e-invoice as a suggestion, not a posting. Route it through the same review your PDFs get. Our suggestion is use a best in class Real Estate coding tool for this step.
5. Ask your e-invoicing provider, whether they can deliver below the legal entity (by establishment, SIRET, or an internal routing code), and whether they support multiple lanes per entity.
6. If your ERP vendor offers an e-invoicing partner, ask where coding and review happen in that design, and what they mean by that is it simple matching or rule tables? Confirm anything you add in between writes into the ERP natively. If it needs a file export to get an invoice into your ERP, it’s a weak point. And as always keep pushing ERP for open access to best in class integration partners.

The mandates are here, and the networks will keep improving. But the assumptions underneath them (one owner, one entity, one vendor ID, one GL) aren’t going to change on their own. If you manage other people’s buildings, or your entities hold more than one, you have to build the routing and the coding yourself, or work with someone who has.

How PredictAP handles e-invoices

PredictAP is agnostic on both ends of the chain. Downstream, it writes into the payables platform the customer already runs (Yardi PayScan, NexusPayables or MRI). Upstream, it takes the e-invoice from whichever network the customer or their ERP chose, and it isn’t a network itself. That’s deliberate: retrieval is a compliance decision customers make for their own reasons, and the coding has to be right no matter which way they went.

PredictAP is doing this today with real estate customers receiving e-invoices in several EU countries, over more than one delivery path. Whichever network delivers the invoice, and however it arrives (email, SFTP or API), PredictAP receives it, stores the XML with the PDF, routes it to the right entity and team, predicts the line-level coding from the customer’s own posting history, holds anything low-confidence for a person, and writes the result into Yardi PayScan, NexusPayables or MRI through the ERP’s native API as a fully coded invoice: minutes after arrival when the network delivers by API, and within the same business day over SFTP. Invoices that belong to an external manager can be redirected by email and rejected from the queue in one audited step. The network handles retrieval. The Yardi invoice that shows up for approval is coded and reviewed, not a header with a vendor default on it.

FAQ

Is an emailed PDF an electronic invoice?

No. Under the EU definition, an e-invoice is issued, transmitted and received in a structured electronic format that a system can process automatically. A PDF attached to an email is a picture of an invoice; it isn’t structured data, and in Germany, Belgium, Poland, Italy and France it doesn’t satisfy the mandate. Two exceptions: a hybrid PDF such as Factur-X or ZUGFeRD counts because structured XML is embedded in the file, and Portugal treats a PDF issued by certified software with an ATCUD and QR code as an e-invoice, with a qualified electronic signature required from January 2027.

Is e-invoicing mandatory in the EU?

There is no single EU-wide domestic mandate yet. Among major real estate markets, domestic B2B e-invoicing is mandatory in Italy, Belgium, Poland, and France (receiving for all businesses, issuing phased by size); Romania also has one. Germany requires receiving now and issuing from 2027. Spain’s mandate is enacted but its start date depends on an order not yet published (expect late 2027 at the earliest). Portugal has no B2B mandate but requires certified software, ATCUD and QR codes, SAF-T reporting, and from 2027 a qualified signature on PDF invoices. The EU-wide ViDA package requires e-invoicing and digital reporting for covered cross-border B2B transactions from July 2030, based on the European standard.

What is the EU standard for e-invoicing?

EN 16931 is the European semantic standard for what an e-invoice must contain. It is expressed in syntaxes such as UBL and CII, and national formats like Peppol BIS, XRechnung and Factur-X are implementations of it. Italy’s FatturaPA and Poland’s FA(3) are national schemas that predate or sit alongside it.

Does e-invoicing replace invoice coding software?

No. E-invoicing delivers the invoice as structured data and may supply a vendor-default GL or copy PO coding. Real estate invoice coding, meaning the split across properties, entities, GL accounts, recoverability, and VAT treatment, still has to be predicted or entered. See What is a fully coded invoice? for the field-by-field breakdown.

Why do third-party property managers have a harder time with e-invoicing?

Because in practice a managed entity usually has one registered invoice address, and everything sent to it goes to whoever controls that address, not to whoever manages each building. Third-party managers end up receiving, sorting, and redirecting invoices that aren’t theirs.

Who receives an e-invoice when a property manager registers an owner’s legal entity?

In the implementations we’ve seen, invoices sent to a registered invoice address go to the receiver attached to that address. If the owner’s entity is represented by one shared address, the manager controlling it receives invoices for properties it doesn’t manage, and the owner and other managers won’t see them unless they’re forwarded or the entity is set up with separate addresses or reception lanes.

How do e-invoices get into Yardi, NexusPayables or MRI?

Either directly, where the accounting system imports the XML and copies coding from a PO if one is referenced, or through an intake and coding layer that receives the e-invoice by email, SFTP or API, routes it to the right entity and property, predicts the line-level coding, and then writes it into the ERP’s payables workflow (Yardi PayScan, NexusPayables, or MRI) through the ERP’s own API for approval. The direct path is faster; the natively integrated coded path is the one that keeps review in place without creating a second system of record.

Should we use our ERP’s e-invoicing partner?

For Retrieval, often yes. Decide separately where coding and review happen: a partner that delivers straight into the ERP typically leaves coding to a vendor default you’ve traded a coding gap for an integration gap. So use a Real Estate native coding tool to handle the retrieved invoices.

Does PredictAP work with the e-invoicing network our ERP uses?

Yes. PredictAP isn’t an e-invoicing network and doesn’t replace one. It sits between the network and the ERP: it takes the e-invoice however the network delivers it, codes and routes it, and writes it into Yardi PayScan, NexusPayables or MRI natively. You keep your network, your ERP, and your approval workflow.

What’s the risk of meeting the e-invoicing mandate without solving coding?

The errors that used to be caught at capture post instead, and surface later at a higher cost: recoverable expenses missed at CAM reconciliation, capital items expensed or the reverse, and VAT or transaction types that block input tax recovery. E-invoicing doesn’t create those errors; it removes the moment someone used to catch them.

Can PDF invoices still be used in the EU?

For a shrinking set of vendors and countries, yes. In clearance-model countries like Italy and Poland, a PDF is not a legally issued invoice. Expect PDF volume to fall each year as more mandates take effect, and plan for one workflow that handles both.

Sources

• European Commission, EU VAT Gap Report (2023 data): https://taxation-customs.ec.europa.eu/taxation/vat/fight-against-vat-fraud/vat-gap_en
• European Commission, adoption of the VAT in the Digital Age package (ViDA): https://taxation-customs.ec.europa.eu/news/adoption-vat-digital-age-package-2025-03-11_en
• French Ministry of the Economy, opening of the e-invoicing directory (annuaire de la facturation électronique): https://www.economie.gouv.fr/actualites/facturation-electronique-ouverture-de-lannuaire-dedie
• WiseTREND, e-Invoice Mandates 2026: https://www.wisetrend.com/blog/e-invoice-mandates-2026-state-of-adoption-top-10-countries/
• Finbite, E-Invoicing Mandates in Europe 2026: https://finbite.eu/en/e-invoicing-mandates-europe-2026/
• fiskaly, E-Invoicing in Europe 2026 roadmap: https://www.fiskaly.com/blog/e-invoicing-mandates-in-europe-2026
• European Commission, eInvoicing Country Factsheets: https://ec.europa.eu/digital-building-blocks/sites/spaces/DIGITAL/pages/467108874/eInvoicing%20Country%20Factsheets%20for%20each%20Member%20State%20and%20other%20countries