- Why This Playbook Exists
- Stage 1: Confirm Legal Scope Per Entity
A practical, source-linked playbook to prepare your finance and IT operations for mandatory e-invoicing. Built around the order the work actually has to happen, not the order a vendor demo presents it.
Quick Answer Preparing for e-invoicing is a six-stage project: confirm legal scope per entity, map your invoice data to a structured format (UBL, CII, Factur-X, or FA(3)), pick a transmission model (Peppol network vs. national clearance portal), register with the relevant authority or access point, run end-to-end tests against the official validator, then cut over with a fallback plan. Most small businesses can complete this in 8 to 14 weeks if the data already exists in an ERP.
Key Takeaways
- The single biggest delay in e-invoicing rollouts is data quality, not technology. Missing VAT IDs, inconsistent customer master data, and unstructured line items are the top reasons go-live slips.
- EY's four-step framework puts global tax policy and governance ahead of technology selection.
- The Peppol BIS Billing 3.0 specification uses UBL 2.1 and is the default for Belgium, the Nordics, and increasingly France (where the DGFiP became the national Peppol authority in July 2025).
- Receive-side capability is mandatory in Germany, Belgium, and France before issuance is. If your business only buys, not sells, in those countries, you still have an obligation.
- The cheapest mistake to avoid: failing to validate sample invoices against the official schema before signing a vendor SOW.
Why This Playbook Exists
Most "how to prepare for e-invoicing" content reads like a vendor's homepage. It tells you e-invoicing is faster and better and lists the compliance regimes its product happens to cover. That is not preparation. That is sales material.
A real preparation plan answers six questions in the right order:
- Which entities are in scope, and on what date?
- What is the required structured format for each entity's transactions?
- Which transmission model applies (centralized clearance, Peppol exchange, or hybrid)?
- What does your current invoice data look like, and what is missing?
- How will you test the end-to-end flow before regulators are watching?
- What happens if the connection fails on go-live day?
The rest of this page walks through each question with concrete tasks and the most common failure points.
Stage 1: Confirm Legal Scope Per Entity
Before any technology decision, build a one-page table of every legal entity, its VAT registrations, and its mandate exposure. The work is dull. It is also the only step that catches the biggest mistake in cross-border rollouts: forgetting that a holding company in country A still has receive-side obligations when it buys services from a supplier in country B.
For each entity, document:
- Legal name and VAT registration number per country
- Annual turnover (last fiscal year, in local currency)
- Mandate go-live date that applies based on turnover or business size
- Whether the obligation is issue, receive, or both
- Any exemptions claimed (size threshold, sector, B2C-only)
- Affiliated entities (subsidiaries, branches) inside the same mandate
If your business operates across multiple jurisdictions in 2026, this table will quickly show you that there is no single deadline. France mandates issue capability from 1 September 2026 for large and mid-sized businesses. Belgium mandates Peppol exchange from 1 January 2026. Poland requires KSeF onboarding from 1 February 2026 for large taxpayers. Each of those is a different project with its own format.
| Country | First 2026 Deadline | Issue or Receive? | Required Format |
|---|---|---|---|
| Belgium | 1 January 2026 | Both | Peppol BIS Billing 3.0 (UBL) |
| Poland (KSeF) | 1 February 2026 (large) | Both | FA(3) XML via KSeF |
| Spain (VeriFactu) | 1 January 2026 (corporates) | Issue (certified software) | Verifiable XML |
| Saudi Arabia (Wave 24) | 30 June 2026 | Both | Signed XML / PDF-A3+XML |
| France | 1 September 2026 (large + mid) | Receive (all) + Issue (large/mid) | UBL 2.1 / CII / Factur-X |
| Germany | Already required (receive) | Receive now, issue from 2027/2028 | XRechnung / ZUGFeRD / Factur-X |
Read our country-by-country e-invoicing mandates guide for the full deadline matrix, including exemptions and grace periods.
Stage 2: Pick the Right Structured Format
E-invoicing mandates do not accept PDFs as compliant invoices. They require structured data, which means an XML or JSON document that follows a published schema. The schema differs by jurisdiction, but the family of options is small.
UBL 2.1 / EN 16931: The default European structured format. UBL (Universal Business Language) is the underlying XML vocabulary. EN 16931 is the European semantic standard that defines which fields and code lists are mandatory. Peppol BIS Billing 3.0 is the most common profile sitting on top of both. If your business operates in Belgium, the Nordics, the Netherlands, or increasingly France, this is the format you will spend the most time with.
UN/CEFACT CII (Cross Industry Invoice): A separate XML format permitted in France and used inside the Factur-X hybrid container.
Factur-X / ZUGFeRD: A hybrid format. A human-readable PDF/A-3 carries an embedded CII XML payload. The PDF is what your customer sees in their email; the XML is what their accounting system imports. France and Germany both accept Factur-X. For SMBs, this format is the gentlest entry point because the PDF surface stays familiar.
FA(3): Poland's XML schema for the KSeF clearance system. Replaces the older FA(2) from 1 February 2026.
ZATCA XML / PDF-A3: Saudi Arabia's format under the Fatoora platform. Requires cryptographic signing.
Indian IRP JSON: India's e-invoice schema submitted to the Invoice Registration Portal.
For most SMBs in the EU, the format question simplifies to Peppol BIS 3.0 (UBL) plus Factur-X as a hybrid fallback for German and French counterparties who have not yet migrated to pure XML. If you operate in Poland or Saudi Arabia, you need a separate format track per country.
Stage 3: Pick a Transmission Model
There are three operational models in production today. They are not interchangeable.
Centralized clearance. The tax authority operates a portal that receives every invoice, validates it, and either approves or rejects it before the buyer ever sees it. Italy's SdI, Poland's KSeF, Saudi Arabia's Fatoora, and India's IRP all use this model. You connect once to a national platform.
Decentralized exchange. Buyer and seller exchange invoices peer-to-peer through certified access points on a shared network. The most common example is Peppol. Belgium adopted this model in 2026. The tax authority sees no invoices in the basic 4-corner version; in Peppol's 5-corner model, the access points report a copy or summary to the tax authority in near-real time.
Hybrid PDP model. France's choice. Businesses connect through certified Partner Dematerialization Platforms (PDPs), which both transmit invoices and report transaction data to the DGFiP. France's DGFiP also became the Peppol authority for France in July 2025, which means PDPs increasingly use Peppol under the hood.
For most SMBs in EU markets, the decision tree is straightforward:
| Where You Operate | Default Model | Connection Point |
|---|---|---|
| Belgium, Netherlands, Norway, Sweden, Finland | Peppol exchange | Certified Peppol Access Point provider |
| France | Hybrid via PDP | Certified PDP (some are also Peppol APs) |
| Poland | Centralized clearance | Direct integration with KSeF |
| Italy | Centralized clearance | Direct or via intermediary to SdI |
| Saudi Arabia | Centralized clearance with signing | Integration with Fatoora platform |
| Germany | Decentralized (XRechnung, ZUGFeRD); Peppol optional | Email + EN 16931 capability minimum |
Stage 4: Map Your Current Invoice Data
This is the stage that determines whether your project finishes on time. Pull a representative sample of recent invoices (we recommend 50, covering at least every customer type and tax scenario) and check them against the EN 16931 mandatory fields. The common gaps:
- Buyer VAT number missing or in non-standard format. EN 16931 requires the buyer VAT ID in mandates that scope B2B. If your CRM does not store VAT IDs as a structured field, you have a data project before you have an e-invoicing project.
- Line items without unit prices and quantities split out. Many SMB invoicing tools store a total per line. EN 16931 wants quantity, unit code, unit price, line total, and tax breakdown per line.
- Tax categories not mapped to UNCL5305 codes. EN 16931 uses a specific code list (S, E, AE, K, G, O, Z, etc.) for VAT categories. If your invoices say "VAT 21%" as text, that has to map to a structured code.
- Currency codes not following ISO 4217. "EUR" is fine; "Euro" or "€" alone is not.
- Payment terms in free text. "Net 30" is human-readable but does not produce a structured due date. EN 16931 wants a specific payment-due date and structured payment instructions.
- Bank account in IBAN format. Most EU mandates require IBAN, not local routing numbers.
Build a gap list before talking to any vendor. The cost of fixing customer master data inside your existing CRM is usually lower than letting a vendor's "data cleansing add-on" fix it for you.
Stage 5: Register With the Relevant Authority or Access Point
Once you know the format and transmission model, the registration step is mostly paperwork. The order matters:
- Centralized clearance (Italy, Poland, Saudi Arabia, India): Register your business and authorized users directly with the tax authority. Poland's KSeF, Saudi Arabia's Fatoora, and India's IRP all require explicit onboarding. Expect identity verification, role assignment, and certificate issuance for signing.
- Peppol countries: Choose a certified Peppol Access Point provider. The provider registers your business in the Peppol directory (SMP). Your Peppol ID is the equivalent of your phone number on the network. You do not register with the tax authority directly in basic 4-corner Peppol; the access point handles routing.
- France: Select a certified PDP. The PDF list is maintained by the DGFiP. Each PDP can also act as a Peppol AP for inbound foreign traffic.
- Belgium: Same Peppol process. The Belgian government does not require a separate tax authority registration for the 2026 invoicing obligation; CTC reporting in 2028 will require additional registration.
If you operate in two or three Peppol countries, one access point usually covers all of them. If you operate in a Peppol country and a centralized clearance country, you will likely run two separate connections.
Stage 6: Run an End-to-End Test Before Go-Live
Most failed go-lives share a pattern: the business assumes the vendor's "compliance certification" means their specific invoices will validate. It does not. Vendor certification covers the schema. Your data still has to fit the schema.
Build a four-step test:
- Generate a real invoice from your ERP for a real customer, then export it in the target structured format.
- Validate the file against the official schema. Peppol publishes a free Peppol validator that catches schema and business-rule errors. EN 16931 has its own validation artifacts. KSeF has a Polish-language validator. ZATCA has a sandbox.
- Transmit the file through your access point or to the clearance portal in test mode.
- Reconcile the response. Centralized portals return a unique invoice ID or rejection reason. Peppol returns an MLR (Message Level Response). Match this back to your AR system.
Repeat for every distinct invoice type your business issues: standard goods, services, mixed VAT rates, exports, intra-EU supplies, credit notes, advance payments, and final settlements. A surprising number of businesses pass the first test only to discover that their credit notes use a slightly different document type code (UNCL1001: 380 for invoice, 381 for credit note) that breaks on receive side.
Original Research: The Real Cost of an SMB E-Invoicing Rollout
We cross-referenced published cost benchmarks from Avalara's e-invoicing guide, Sovos's e-invoicing buyer materials, and Pagero's Billentis-summary publications, then mapped them against a typical EU SMB (50 to 250 employees, single ERP, three EU jurisdictions).
| Cost Bucket | Typical SMB Range | Notes |
|---|---|---|
| ERP / billing system data cleanup | 40-160 hours internal | Master data fixes dwarf the technology spend |
| Vendor / access point subscription | EUR 1,200 - EUR 6,000 per year | Per-transaction pricing common above 5,000 invoices |
| Implementation services | EUR 2,000 - EUR 15,000 | One-time; scales with number of mandates |
| Internal IT testing time | 30-80 hours | Most of it spent on credit-note edge cases |
| Tax authority / PDP registration | Free to EUR 500 | KSeF, Fatoora, IRP have no platform fee |
| Annual recurring training and updates | EUR 500 - EUR 2,500 | Required because mandates keep changing |
The hidden cost most vendor decks omit: time spent reconciling rejected invoices in the first 90 days post go-live. Plan for at least one full-time-equivalent week to chase down rejection reasons, which usually trace back to missing buyer data rather than vendor errors.
Stage 7: Plan Your Fallback for Day One
Every centralized clearance system has had at least one outage. KSeF, SdI, and the IRP have all experienced multi-hour disruptions in their first 18 months. Most regulations include fallback rules; few SMBs read them before they need them.
Concrete fallback elements to document before go-live:
- The platform's official downtime notification feed (RSS, status page, or email).
- The local tax authority's stated grace window for delayed transmission. Italy allows 12 days; Poland allows up to 7 business days with documentation; India has a 30-day reporting window.
- A queue mechanism in your ERP that holds invoices generated during downtime and releases them once the platform recovers.
- A clear escalation path internally for unrejected-but-not-acknowledged invoices.
- A communications template for affected customers.
Common Failure Modes That Delay Go-Live
We pulled the most-cited go-live failures from EY, Sovos, and Avalara case writeups, plus practitioner posts on community sites:
- VAT IDs stored as free text. A surprising share of legacy ERPs treat the buyer VAT number as a description field, not a structured one. The first KSeF test rejects show this immediately.
- No buyer email or Peppol ID for SMB counterparties. The buyer must be discoverable in the directory; otherwise the message bounces.
- Inconsistent unit codes. "Hours," "hrs," and "h" all need to map to a single UNECE Recommendation 20 code (HUR for hour).
- Multi-currency invoices missing tax-currency lines. Most mandates require both transaction currency and tax-in-local-currency lines.
- Embedded PDFs in Factur-X that are not actually PDF/A-3. PDF/A-3 is the only flavor that legally embeds the XML payload. Older PDF/A profiles get rejected.
- Signing certificates expired or wrong type. Saudi Arabia and several Latin American mandates require specific certificate types issued by approved certificate authorities.
- Treating credit notes as invoices. Wrong document type code; instant rejection on receive side.
When This Guide Isn't For You
If your business operates exclusively in the United States and does not invoice cross-border into any country with a mandate, you have no immediate compliance obligation. Some U.S. state governments mandate B2G e-invoicing for vendors selling to the state, but there is no federal B2B mandate. The voluntary Federal Reserve Business Payments Coalition exchange is a useful preparatory step but is not mandatory.
If you are a sole proprietor invoicing only individuals (B2C), most current mandates target B2B and do not apply. France's e-reporting requirement and Spain's VeriFactu are the exceptions to review with a local accountant.
If your annual revenue is well below every applicable threshold (under EUR 22,000 in Germany, INR 5 crore in India, SAR 375,000 in Saudi Arabia, PLN 200 million in Poland for the first wave), you may have more time than you think. Use the buffer to clean up master data, not to delay the project further.
How We Verified This
The format references (UBL 2.1, EN 16931, Peppol BIS 3.0) are taken from the official Peppol BIS Billing 3.0 documentation and the European Commission's eInvoicing documentation pages. The mandate deadlines were cross-checked against EY, BDO, KPMG, and Avalara tax alerts published between October 2024 and March 2026. Cost ranges were aggregated from Avalara's published guide, Sovos's buyer materials, and the 2024 Billentis Global E-Invoicing and Tax Compliance Report summaries.
Frequently Asked Questions
How do you prepare an e-invoice?
A compliant e-invoice is generated by exporting your invoice data from your ERP or billing system into the required structured format (UBL, CII, FA(3), Factur-X, or a national variant), validating the file against the official schema for the destination jurisdiction, then transmitting it through the approved channel: a Peppol access point, a national clearance portal, or a certified PDP. The PDF you used to send by email is no longer the legal invoice in most 2026 mandates; the structured file is.
Is e-invoicing difficult to set up?
For a single-jurisdiction SMB using a modern cloud invoicing tool, set-up is usually a matter of enabling the right output format and registering with an access point or portal: typically 1 to 4 weeks of work. For a multi-entity business with custom or legacy ERP systems and operations in three or more mandate countries, expect 3 to 6 months. The difficulty almost always comes from data quality, not technology.
What is the first step in the e-invoicing process?
The first step is confirming legal scope. You need to know exactly which of your legal entities is in scope, by what date, and whether the obligation is to issue, receive, or both. Without that table, every subsequent technology decision is uninformed. EY's published four-step framework puts tax policy and governance first for the same reason.
What are the 5 most important things to put on an invoice?
For a structured e-invoice, the EN 16931 mandatory fields include: seller and buyer identification (legal name plus VAT ID), invoice number and issue date, line items with quantity, unit price and tax breakdown, total amount with VAT broken out by rate, and payment terms with a structured due date and bank account in IBAN format. Many mandates add specific local codes (currency code per ISO 4217, unit codes per UNECE Rec 20, VAT category codes per UNCL5305).
Can I use a PDF as an e-invoice?
A plain PDF is not a compliant e-invoice under any of the major 2026 mandates. The hybrid Factur-X / ZUGFeRD format is the exception: it is a PDF/A-3 file with structured XML embedded inside, so the recipient gets both a human-readable PDF and a machine-readable XML payload. France and Germany accept Factur-X for B2B traffic.