EU E-Invoicing Mandates by Country: Dates, Formats and ERP Changes

EU e-invoicing mandates became live deadlines in 2026: Belgium and Croatia on January 1, Poland on February 1 and April 1, Greece on March 2 and October 1, and France on September 1. Germany's issuing obligation follows on January 1, 2027, for businesses whose prior-year turnover exceeded €800,000. The fine print bites before the dates do. Poland's KSeF accepts at most 180 invoices an hour from software that sends them one at a time, and it counts a supplier's invoice as received when KSeF assigns its number, not when your system downloads it (Ministry of Finance KSeF documentation).

This list covers domestic B2B e-invoicing and real-time invoice reporting in EU member states, plus the EU-wide dates in the VAT in the Digital Age (ViDA) directive. A country is in the main table only if its tax authority, or two independent advisers or software vendors, confirm its dates. Checked in September 2026. This is a practical summary, not legal or tax advice; each country's tax authority has the final word.

The list: EU e-invoicing mandates by country

Read the table once per legal entity, for the country where it is established, for both the invoices it issues and those it receives. Germany's and Croatia's mandates cover established businesses, so an entity that is only VAT-registered there should check its position with an adviser.

EU e-invoicing and real-time reporting mandates, as of September 2026
Country	Who	From	Format	Channel	What your integration must handle
Belgium	VAT-liable Belgian businesses invoicing each other (nearly all B2B)	January 1, 2026	Peppol BIS Billing 3.0 (UBL)	Peppol, through a service provider	A Peppol ID for you and every customer (scheme 0208 plus enterprise number, sometimes 9925 plus VAT number); invoices and credit notes over Peppol; inbound Peppol into accounts payable. einvoice.belgium.be
Croatia	VAT-registered taxpayers established in Croatia, for domestic invoices; businesses outside VAT receive from 2026	January 1, 2026; issuing outside VAT from January 1, 2027	Structured XML (eRačun)	Your own access point or an information intermediary; the free MIKROeRAČUN app outside VAT	A six-digit KPD code on every line; fiscalization on issue and on receipt; rejections and payment reports by the 20th of the following month. Porezna uprava
France	Every business must receive; large and mid-sized businesses also issue and e-report	September 1, 2026; small and micro businesses issue from September 1, 2027	UBL, UN/CEFACT CII or Factur-X	An approved platform (plateforme agréée)	Four new invoice mentions, the customer's SIREN, lifecycle statuses, e-reporting in ten-day periods. impots.gouv.fr
Germany	Businesses established in Germany invoicing each other	Receiving since January 1, 2025; issuing from January 1, 2027 if prior-year turnover exceeded €800,000; everyone from January 1, 2028	XRechnung, or ZUGFeRD 2.0.1 or later except the MINIMUM and BASIC-WL profiles	Agreed between the businesses; the rules set format and timing, not a platform	Reading and validating XML from any supplier now; issuing by 2027 or 2028. Federal Ministry of Finance
Greece	Businesses in Greece invoicing each other	March 2, 2026 if 2023 gross revenue exceeded €1 million (postponed from February 2); October 1, 2026 for everyone else, with a transition to December 31, 2026	Structured e-invoice, with its data reported to myDATA	A certified e-invoicing provider, or AADE's free timologio and myDATAapp tools	myDATA classification codes, VAT numbers with the EL prefix, and the MARK that AADE assigns to each invoice. KPMG
Hungary	Businesses issuing invoices under the Hungarian VAT Act	Real-time reporting since July 1, 2018; all invoices, consumer sales included, since January 4, 2021	Invoice data in NAV's XML schema 3.0	NAV's Online Számla API, called by your invoicing software	Reporting when the software finalizes each invoice, up to 100 per report, with no blind resends after a timeout. NAV
Italy	Domestic invoices, including to businesses and public bodies	In force	FatturaPA XML	SDI (Sistema di Interscambio), which checks each invoice before delivering it	Recipient codes (six characters for public bodies, seven for businesses), rejections, one registered receiving address. Odoo
Poland	Businesses issuing invoices in Poland	February 1, 2026 if 2024 sales exceeded PLN 200 million, VAT included; April 1, 2026 for the rest; January 1, 2027 for issuers invoicing up to PLN 10,000 a month	FA(3) XML	KSeF, the Ministry of Finance's clearance system	The KSeF number and UPO for each invoice, batch sessions for volume, offline modes with QR codes, accounts payable fed from KSeF. Ministry of Finance
Spain	Verifactu: businesses and the self-employed not on SII. B2B e-invoicing: all businesses, largest first	Verifactu: January 1, 2027 for corporate income taxpayers, July 1, 2027 for everyone else. B2B e-invoicing: expected October 2027 above €8 million turnover, October 2028 for the rest	Verifactu invoice records in XML; structured B2B e-invoices	Verifactu-compliant billing software; public or private platforms for B2B	A hash chain across invoice records, a QR code on each invoice, submissions of up to 1,000 records. KPMG
All member states (ViDA)	Intra-EU B2B supplies	Domestic mandates allowed since April 14, 2025; intra-EU e-invoicing with digital reporting from July 1, 2030; national systems aligned by January 1, 2035	Structured e-invoice	Each member state's digital reporting system	Intra-EU invoices issued within 10 days of the chargeable event. European Commission

Not in the table: Romania, Portugal, Latvia, Slovakia and Estonia, whose current dates we could not confirm from two independent sources in September 2026. For Romania, one integration detail is solid: RO e-Factura's message-list call at ANAF, the tax agency, looks back at most 60 days, so an inbound sync that fails unnoticed for longer can't reach older invoices through it (Odoo). Alert on the age of the last successful sync.

Belgium: find every customer's Peppol ID before the first run

Since January 1, 2026, structured e-invoices have been compulsory for nearly all transactions between Belgian businesses liable to VAT, sent over Peppol (einvoice.belgium.be, FPS Finance). In Peppol, a Belgian company is scheme 0208 plus its enterprise number, and invoices use the Peppol BIS Billing 3.0 profile, urn:fdc:peppol.eu:2017:poacc:billing:01:1.0 (Odoo, Microsoft Learn).

The job teams underestimate is the customer master. Check each Belgian customer's Peppol ID against the public Peppol Directory:

curl "https://directory.peppol.eu/search/1.0/json?participant=iso6523-actorid-upis::0208:0123456789"
curl "https://directory.peppol.eu/search/1.0/json?participant=iso6523-actorid-upis::9925:be0123456789"

Replace 0123456789 with the customer's enterprise number, digits only. From the documentation of phoss-directory, the software behind directory.peppol.eu, as of September 2026:

The API allows 2 queries a second and answers 429 above that, so pace a bulk check at one request a second.
A search with no match returns status 200 with an empty result, so test the response body, not the status code.
An entry appears only when the customer's Peppol provider publishes business details to the Directory. A miss means "ask the customer", not "can't receive".

The second line checks scheme 9925, the VAT number: BE plus the same ten digits. The open-source peppol-commons library treats 9925:BE0123456789 and 0208:0123456789 as one end user, and Dynamics 365 Finance addresses a Belgian customer by VAT number when it has no enterprise number (Microsoft Learn). A company registered only under 9925 fails the first lookup.

This week: export your Belgian customers with their enterprise numbers, run both lookups for each and store the participant ID that matched where the invoice export reads it.

Croatia: Fiscalization 2.0 reports both sides of each invoice

Since January 1, 2026, VAT-registered taxpayers seated or resident in Croatia must send and receive eRačuni, structured e-invoices, for domestic transactions. Businesses outside the VAT system must be able to receive them from the same date and must issue them from January 1, 2027 (Porezna uprava). For VAT-registered businesses, fiscalization, reporting the invoice data to the Tax Administration, applies on receipt as well as on issue.

Three requirements reach into your ERP rather than your provider:

A KPD code on every line. Each goods or service line needs its six-digit KPD (Klasifikacija proizvoda po djelatnostima) code (Porezna uprava). Put it on the item master so invoice lines inherit it, as Odoo's Croatian setup does (Odoo).
Fiscal numbering and identity. Odoo's documentation requires invoice numbers in the form sequence/business premises label/issuing device label, a business process type on each invoice and the personal identification number (OIB) of the user who sends it.
Messages after sending. A recipient can reject an eRačun, which notifies the eRačun system and the sender, and the Tax Administration expects a report once an invoice has been paid (same Odoo source). Both belong to monthly e-reporting, due by the 20th of the following month (Fiscal Solutions, ecosio), so accounts payable has to settle rejections before then.

Businesses outside VAT can use MIKROeRAČUN, the Tax Administration's free application, instead of a provider, although public procurers can't. Everyone else builds an access point or uses an information intermediary.

This week: export your active items and count those without a KPD code. Then ask your intermediary which KPD code list version it validates against, how rejections reach your ERP, whether it sends payment reports or you do, and how it fiscalizes the invoices you receive.

Poland: the KSeF limits that shape your design

KSeF has been mandatory since February 1, 2026 for businesses with 2024 sales above PLN 200 million, VAT included, and since April 1 for everyone else. Issuers below PLN 10,000 a month may stay outside it until the end of 2026 but must accept their suppliers' KSeF invoices, and there are no penalties for errors in 2026 (Ministry of Finance).

The Ministry's integrator guide sets these production limits per context (usually the taxpayer's tax number, NIP) and IP address, as of September 2026:

KSeF production API limits, as of September 2026
Operation	Endpoint	Requests per hour
Send one invoice in an interactive session	`POST /sessions/online/{ref}/invoices`	180 (and 10 a second, 30 a minute)
Open a batch session	`POST /sessions/batch`	60
List invoice metadata for incremental download	`POST /invoices/query/metadata`	20
Start an invoice export package	`POST /invoices/exports`	20
Download one invoice by KSeF number	`GET /invoices/ksef/{ksefNumber}`	64

Over a limit, KSeF answers 429 with a Retry-After header, and repeated breaches lengthen the block. The windows roll, so nothing resets on the hour. The test environment's limits are ten times production's while DEMO copies production, so load-test on DEMO. Spreading requests across IP addresses to gain capacity is logged as a possible attack and can get the context blocked.

A worked example: the month-end run

An illustrative example. A distributor issues 1,200 invoices in its month-end billing run.

Sent one at a time in an interactive session, the run takes at least 1,200 ÷ 180 = 6.7 hours, and the 181st send inside any rolling hour gets a 429.
Sent as a batch, it's one session: one request to open it, part uploads that don't count against the limits, one request to close it, then status checks. A batch session holds up to 10,000 invoices in up to 50 ZIP parts of 100 MB each before encryption, 5 GB in total (KSeF invoice verification).

Five rules that change your data model

The receipt date is KSeF's, not yours. An invoice is received on the date KSeF assigns its number, whenever your system downloads it. Anything keyed to the receipt date, such as payment terms, needs that timestamp, which makes it a posting-date question as much as a technical one (see carrying posting and document dates separately).
Duplicates are checked on business data. KSeF rejects a second invoice with the same seller NIP, invoice type and invoice number with error 440, "Duplikat faktury", and keeps that uniqueness for ten full years after the year of issue. Branches or units invoicing under one NIP must agree a numbering scheme (KSeF invoice verification).
Midnight changes the mode. If an invoice's issue date (P_1) is earlier than the day KSeF accepts it, KSeF marks it offline even when sent as online. In an interactive session, acceptance is the moment you send, so a nightly job for invoices dated the 3rd that sends after midnight produces offline invoices. In a batch session it's when the session opened, so opening it before midnight keeps the run online (KSeF automatic offline mode).
Corrections wait for the original's number. A correcting invoice can be sent only after the invoice it corrects has a KSeF number (KSeF offline modes).
Size limits. 1 MB per invoice, or 3 MB with attachments, which need a batch session and prior consent in e-Urząd Skarbowy.

Offline invoices and the QR code

The guide lists three offline modes (KSeF offline modes): offline24, your choice at any time, due in KSeF by the next business day after the issue date; announced unavailability, due by the next business day after it ends; and an announced failure, due within seven business days after it ends. Copies handed over outside KSeF, such as PDFs, carry a QR code linking to KSeF's verification page, and offline invoices carry a second code proving the issuer's identity through a KSeF certificate.

The first code is a link you can build from data you already hold (KSeF QR codes):

import base64, hashlib

def ksef_verification_url(invoice_xml_bytes, seller_nip, issue_date):
    # issue_date is the invoice's P_1 date; hash the exact file sent to KSeF
    digest = hashlib.sha256(invoice_xml_bytes).digest()
    token = base64.urlsafe_b64encode(digest).decode("ascii").rstrip("=")
    return "https://qr.ksef.mf.gov.pl/invoice/{}/{}/{}".format(
        seller_nip, issue_date.strftime("%d-%m-%Y"), token)

The hash covers the exact bytes you sent. If your system re-renders the XML later, even with different whitespace, the hash changes and the code on the PDF stops matching. Store the sent file, its hash, the KSeF number and the UPO, KSeF's official confirmation of receipt, against each invoice (Odoo).

This week: count the invoices in the busiest hour of your largest billing run last quarter. Above 180, the integration needs batch sessions. On the purchasing side, the Ministry asks for incremental downloads no more often than every 15 minutes for each party, export packages for volume, and users served from your own copy rather than from KSeF (KSeF API limits).

France: platforms, four new mentions and ten-day e-reporting

Since September 1, 2026, every business in France must be able to receive e-invoices, and large and mid-sized businesses must issue them and transmit transaction data. Small and micro businesses issue from September 1, 2027. Invoices travel through an approved platform (plateforme agréée) that you choose (impots.gouv.fr), in UBL, UN/CEFACT CII or Factur-X (Odoo, Microsoft Learn).

Four mentions become mandatory on invoices (economie.gouv.fr): the customer's SIREN, the delivery address when it differs from the billing address, whether the invoice covers goods, services or both, and the option to pay VAT on debits where you've chosen it. Each is a field your ERP may not have today.

The customer's SIREN matters twice. Domestic sales between French businesses go through e-invoicing, while sales to consumers, cross-border sales and payment data for transactions where VAT is due on payment go through e-reporting (Microsoft Learn). In Dynamics 365 Finance, an invoice to a customer without a SIREN is routed to e-reporting, so a French business customer with a blank SIREN quietly leaves e-invoicing.

E-reporting runs on fixed periods. Under the standard VAT regime, transaction data goes by ten-day period: the 1st to the 10th, the 11th to the 20th and the 21st to month-end (same Microsoft source, Odoo). Microsoft's documentation puts payment data on monthly periods and resends a changed period as a rectifying transmission that replaces the earlier one.

In the XML, identifiers carry scheme codes: 0002 for SIREN, 0009 for SIRET and 0225 for the routing address (Business Central, Dynamics 365 Finance).

This week: count your French business customers whose SIREN is missing or isn't nine digits. In a customer export with names in column A and SIREN in column C, this counts them, ignoring spaces:

=SUMPRODUCT((A2:A5000<>"")*(LEN(SUBSTITUTE(C2:C5000," ",""))<>9))

Then ask your platform which lifecycle statuses it sends back, and map each one to a field on the invoice record.

Germany: receive now, issue from 2027 or 2028

Since January 1, 2025, businesses in Germany must be able to receive e-invoices from other German businesses. Until December 31, 2026, any issuer may still send paper or, with the recipient's consent, a PDF. An issuer whose previous-year turnover was €800,000 or less keeps that option through 2027, and from January 1, 2028 everyone issues e-invoices. The Ministry's letters of October 15, 2024 and October 15, 2025 set out the details (Federal Ministry of Finance). The test uses the prior year, so 2026 turnover decides 2027.

XRechnung, and ZUGFeRD from version 2.0.1, qualify, except ZUGFeRD's MINIMUM and BASIC-WL profiles (same source). A supplier's ZUGFeRD PDF in one of those two profiles isn't an e-invoice under the rules, so check what arrives. KoSIT, which publishes the XRechnung rules, also publishes a free validator. Its configuration of August 31, 2026 covers XRechnung 3.0.2 with version 1.3.16 of the CEN rules for EN 16931 (KoSIT). Anyone with Java 11 or later can run it on a UBL or CII file:

curl -L "https://repo1.maven.org/maven2/org/kosit/validator/1.6.3/validator-1.6.3-standalone.jar" --output validator-1.6.3-standalone.jar
curl -L "https://github.com/itplr-kosit/validator-configuration-xrechnung/releases/download/v2026-08-31/xrechnung-3.0.2-validator-configuration-2026-08-31.zip" --output validator-configuration.zip
unzip validator-configuration.zip
java -jar validator-1.6.3-standalone.jar -s scenarios.xml -r "$PWD" -h supplier-invoice.xml

It writes supplier-invoice-report.html and supplier-invoice-report.xml. A ZUGFeRD invoice is a PDF with CII XML embedded, so extract the XML first. The configuration picks rules by the specification ID in the file: XRechnung, or plain EN 16931 (urn:cen.eu:en16931:2017, the ID ZUGFeRD's EN 16931 profile declares). A ZUGFeRD BASIC or EXTENDED file matches no scenario and gets only a default report, which says nothing about whether the invoice is valid (KoSIT scenarios, Mustang profile list).

This week: run the validator on five e-invoices your suppliers sent last month, and note which formats, versions and profiles arrive. That list is your receiving specification.

Spain and Greece: two timetables that moved

Spain: Verifactu in 2027, B2B e-invoicing after it

Royal Decree-law 15/2025, published on December 3, 2025, moved the Verifactu rules of Royal Decree 1007/2023 back a year: billing software must meet them from January 1, 2027 for companies that pay corporate income tax and from July 1, 2027 for everyone else (KPMG, RSM). Businesses on SII, Spain's immediate VAT reporting system, are outside the rules (Microsoft Learn), as are those under a regional regime such as TicketBAI (Odoo). Compliant software shapes the integration:

Each invoice record carries a SHA-256 fingerprint chained to the previous one, so records must be created in order and the last fingerprint kept (Odoo, Invopop).
The invoice carries a QR code anyone can check against the AEAT, Spain's tax agency.
A submission holds up to 1,000 records. Each AEAT response sets a wait before the next, usually 60 seconds in Odoo's implementation, but a full batch of 1,000 goes without waiting.
Software producers self-certify with a declaración responsable. Odoo publishes its own, so ask your vendor for theirs.

Royal Decree 238/2026, adopted on March 24, 2026 under the Crea y Crece law (Law 18/2022), then makes structured e-invoices mandatory between businesses, through a public or a private platform: first above €8 million turnover, a year later for everyone else. As reported in September 2026, its technical ministerial order takes effect on October 1, 2026, putting the dates at October 2027 and October 2028 (peppol.nu, The Invoicing Hub).

Greece: two phases, and a start date moved after it passed

The first phase covers businesses whose 2023 gross revenue exceeded €1 million. Due on February 2, 2026, it was moved on February 17 to March 2, with existing systems allowed in parallel until May 3. For everyone else the date is October 1, 2026, with a transition to December 31, 2026 (KPMG, Zepos & Yannopoulos). Invoices go through a certified provider or AADE's free timologio and myDATAapp tools, and their data reaches myDATA, the platform of the Independent Authority for Public Revenue (AADE):

Each invoice carries myDATA's invoice type, VAT category and income classification codes, plus payment method codes (Invopop GOBL).
Greek VAT numbers start with EL, not the ISO country code GR, followed by the nine-digit AFM (same source). A check that builds the prefix from the country code rejects every Greek customer.
AADE assigns each invoice a MARK, a registration number GOBL keeps among the official AADE codes. Store it with the invoice, like a KSeF number.

This week: count customers whose VAT number starts with GR, confirm which provider sends your Greek invoices, and put the Spain question below to your billing vendor.

Italy and Hungary: lessons from systems already running

Italy: one receiving address, and rejections as routine

SDI's checks take from seconds to a day. A failed invoice comes back rejected, to be corrected and resent. A passed one gets up to six delivery attempts, 12 hours apart, and if all fail it is accepted anyway and you send the customer a copy yourself (Odoo).
The recipient code tells SDI where to deliver: six characters for a public body, seven for a business, or 0000000 plus a certified email (PEC) address when a business customer's code is unknown (Microsoft Learn).
Register one telematic address for all incoming e-invoices, such as your provider's destination code, on the Agenzia delle Entrate portal under Fatture e Corrispettivi (same Odoo source).

Hungary: handle the response that never arrives

Hungarian businesses have reported invoice data in real time to NAV, the tax authority, since July 1, 2018 (Microsoft Learn), and for all invoices since January 4, 2021. NAV's interface specification spells out what any reporting integration needs:

A reporting token is valid for 5 minutes, and one report holds at most 100 invoices.
An invoice counts as issued when your software finalizes it, and reporting must follow at once. Batching is acceptable only when software, with no human step, collects invoices closed within one token's lifetime.
NAV's gateway times out after 60 seconds without returning a transaction ID, yet the data may still be saved within the next 5 minutes. Resending blindly creates a double report.

NAV's accepted recovery procedure, as pseudo-code:

submit manageInvoice (up to 100 invoices, one token)
if a transactionId comes back:
    check queryTransactionStatus as usual
else (timeout, no transactionId):
    wait 5 minutes from the submission
    call queryTransactionList for a short recent window, for example the last 10 minutes
    for each transactionId your system doesn't know:
        call queryTransactionStatus with returnOriginalRequest = true
        match the returned invoice data to your invoices and store the ID
    if no unknown transactionId was found:
        resubmit the report immediately

The same lost-response problem, and the patterns that stop retries from creating duplicates in any integration, are covered in our guide to connecting business systems.

The EU layer: ViDA from 2025 to 2035

Council Directive (EU) 2025/516, the VAT in the Digital Age package, was adopted on March 11, 2025 (EUR-Lex). Its e-invoicing dates, from the European Commission:

ViDA e-invoicing milestones
Date	What changes
April 14, 2025	The directive enters into force; member states may mandate domestic e-invoicing under its conditions.
July 1, 2030	Digital reporting of cross-border B2B transactions, based on e-invoices, starts; intra-EU invoices are due within 10 days of the chargeable event.
January 1, 2035	Domestic real-time reporting systems must be aligned with the EU model.

The 10-day rule reaches operations: invoice customers in other member states at month-end and early-month deliveries are billed more than 10 days later. To measure it, export last quarter's invoices to those customers with the delivery date in column B and the invoice date in column C. This returns the share invoiced more than 10 days after delivery:

=SUMPRODUCT(--((C2:C2000-B2:B2000)>10))/COUNT(C2:C2000)

Delivery date only stands in for the chargeable event, so have your tax adviser confirm the right date for each flow. A high share means billing has to move closer to shipping before 2030.

Readiness worksheet and questions for your provider

Fill in one copy per legal entity, with whoever owns invoicing and whoever owns the ERP. The defaults are ours.

E-invoicing readiness worksheet
Question	Our default	Where the answer comes from
Are customer identifiers complete?	A dedicated field for each scheme: Peppol ID under 0208 or 9925 (Belgium), SIREN and SIRET (France), NIP (Poland), recipient code or PEC (Italy), VAT number with EL (Greece)	A customer-master export and a count of blanks
What you store per invoice	The official ID (KSeF number, SDI transaction number, NAV transaction ID, myDATA MARK), the exact file sent, its hash and every status change	Your provider's API and status messages
Rejections and corrections	Rejections land in the exception queue the day they arrive; each correction cites the original's official ID	Your provider's rejection messages
Receiving	Invoices enter accounts payable from the official channel, with the official receipt date	Accounts payable and your provider
Peak volume	Invoices per hour in your largest run, checked against each system's limits	Last year's busiest billing day
Archive	The structured file as sent or received, not only the PDF	Your adviser, for each country's retention period

What that queue should contain, and who works it, is covered in our integration guide. Then put these questions to your ERP vendor or e-invoicing provider:

Questions the vendor won't volunteer
Ask	A good answer	A worrying answer
Poland: do you send KSeF invoices in batch or interactive sessions?	Batch for runs, interactive for single invoices, and a stated plan for your peak hour	"One by one, it's instant"
Germany: which XRechnung version and validator configuration do you test against?	XRechnung 3.0.2 with a KoSIT configuration released in 2026	"We generate ZUGFeRD", with no profile named
France: which lifecycle statuses come back, and where do they land?	A list of statuses, each mapped to an invoice field	"You can see them in our portal"
Spain: when does your Verifactu version ship, and where is your declaración responsable?	A release date before your start date, and the signed declaration	"We'll be ready in time"
Belgium: how do you find a customer's Peppol ID?	A Directory or SMP lookup under 0208 and 9925, with a fallback when both miss	"Customers send it to us"

If you also invoice in Saudi Arabia, our ZATCA Phase 2 wave list is the equivalent reference there.

If your invoicing runs through an ERP or a custom billing system in more than one of these countries, bring the completed worksheet and a month of invoice volumes by country. We'd start with the identifiers in your customer master and your peak hourly volume. In our systems integration work, those two decide most of the design.