E-Invoicing Mandates 2026–2028: What Growing Businesses Need From Their Software

The finance manager of a 40-person wholesaler reads a short email on a Monday in September 2026. Her largest customer has just started issuing and receiving structured invoices, and its accounts-payable team asks that the 600 invoices she sends each month arrive as machine-readable files, not PDFs. (An illustrative scene, not a real company.)

Her system produces a PDF. Retyping 600 invoices at ten minutes each would cost 100 hours a month, and one wrong tax ID gets an invoice bounced.

E-invoicing is a data problem before it is a compliance problem. A growing list of governments now require structured invoices, files a computer can read without help, often routed through a network or a tax-authority platform, and software that cannot build them cleanly from the order record turns every invoice into manual work.

If you sell to other businesses, buy from them, or do both, the dates in this article may affect you even if you never leave your home country. A supplier abroad may start sending you structured invoices, and a customer may stop accepting your PDF.

This article explains how the e-invoicing models differ, maps the main mandates from 2026 to 2028 (and a little beyond), and lists what your invoicing or ERP software must do. Dates are checked against official and professional sources as of August 2026. Rules and deadlines in this area change often, so treat the timeline as a map, not as legal advice.

What counts as an e-invoice

A PDF sent by email is an electronic document, but it is not an e-invoice in the sense these laws use. An e-invoice is a file in a defined, machine-readable format, where every field has a fixed meaning: seller tax ID, buyer tax ID, line items, tax rate, tax amount, payment terms.

In Europe the common semantic standard is EN 16931. It says what data an invoice must carry. It is expressed in two main syntaxes, UBL and UN/CEFACT CII, both XML. Peppol BIS Billing 3.0, used in many countries, is built on UBL and follows EN 16931. Outside Europe, countries often define their own format, but many borrow the same ideas.

A hybrid file such as a PDF with an XML file embedded inside (Factur-X or ZUGFeRD) can also qualify, because the XML is the real invoice and the PDF is only a readable copy.

Three ways an e-invoice travels

The format answers "what is in the invoice". The model answers "how does it get from seller to buyer, and who sees it on the way". You will meet three models.

Post-audit

The seller issues a structured invoice and sends it by any agreed route. The tax authority is not in the loop at that moment. It receives data later, through periodic reports, or checks invoices during an audit. This is the lightest model for the seller, but mistakes are found after the fact.

Clearance

The invoice goes to a tax-authority platform first. The platform validates it, may give it a unique identifier and approval, and only then is it delivered to the buyer. Poland's KSeF and Saudi Arabia's integration phase work in this spirit. You get a clear status for every invoice, but you depend on the platform being reachable, so a fallback process is part of the design.

Peppol and the four-corner model

Peppol is an open network run by the OpenPeppol association. You do not connect to each customer. You connect to one certified access point. Your access point looks up the buyer's access point and passes the invoice across. Corner 1 is your system, corner 2 your access point, corner 3 the buyer's access point, corner 4 the buyer's system. Some countries add a fifth corner: a copy of the data goes to the tax authority.

Many countries mix these ideas. A country may use Peppol for exchange and add real-time reporting on top. That is why you should check the model of each market you trade in, not only the deadline. You can read more about the network at peppol.org.

The timeline, 2025 to 2030

The table lists the main mandates. It is a selection, not a complete list. Many countries have rules for B2G (business to government) that started earlier, and others are still drafting laws.

Country or region	What starts	Key dates	Model
Germany	Receive structured invoices; then issue them (domestic B2B)	Receive: all businesses since 1 Jan 2025. Issue: 1 Jan 2027 if prior-year turnover exceeds €800,000; 1 Jan 2028 for everyone	Format-based, no central platform
Belgium	Structured B2B invoicing between VAT-registered businesses	1 Jan 2026. Real-time reporting is planned for 2028	Peppol BIS 3.0 recommended
Croatia	B2B e-invoicing with real-time fiscalisation	1 Jan 2026 for VAT-registered businesses	Exchange plus reporting to the tax authority
Poland	KSeF national system	1 Feb 2026 for turnover above PLN 200m; 1 Apr 2026 for other VAT-registered businesses; micro-entrepreneurs and fines from 1 Jan 2027	Clearance
France	Receive via approved platforms; issue in phases	1 Sep 2026: every business receives; large and mid-sized companies issue. 1 Sep 2027: SMEs and micro-businesses issue	Approved platforms plus a central directory
Spain	B2B e-invoicing under Royal Decree 238/2026	Published 31 Mar 2026. 12 months (turnover above €8m) or 24 months (others) after a pending ministerial order. Separate Verifactu billing-software rules: 1 Jan 2027 and 1 Jul 2027	Public platform plus interoperable private ones
United Arab Emirates	National e-invoicing system	Voluntary from 1 Jul 2026; mandatory from 1 Jan 2027 for turnover of AED 50m and above; other businesses later in 2027	Peppol-based, accredited service providers
Saudi Arabia	ZATCA Phase 2 (integration) in waves	Wave 24 (above SAR 375,000): by 30 Jun 2026. Wave 25 (above SAR 187,500): by 1 Feb 2027	Clearance and reporting
Malaysia	MyInvois in phases by turnover	From 1 Aug 2024 for the largest. Businesses under RM1m exempt. The RM1m to RM5m tier has a penalty-free relaxation period to 31 Dec 2027	Validation by the tax authority
European Union	ViDA: e-invoicing and digital reporting for cross-border B2B	Adopted March 2025. Applies from 1 Jul 2030; member states may set earlier domestic rules	EN 16931 as the standard

Check your local rules. Thresholds are often based on the previous year's turnover, grace periods differ from enforcement dates, and some countries have already moved a deadline once or twice (Malaysia and Spain both did). Before you plan, read your tax authority's current guidance or ask your accountant.

How to read a mandate correctly

Four questions turn a headline into a plan.

• Receive or issue? Germany and France made receiving mandatory first. Even a small business must be able to open and process a structured invoice before it is forced to send one.
• Which transactions? Most mandates cover domestic B2B only. B2C sales and cross-border sales usually fall under separate rules, often e-reporting rather than e-invoicing.
• Which size? Turnover thresholds decide your wave. If you are close to a threshold, plan for the earlier date.
• When do penalties start? A grace period may let you test without fines. Poland, for example, applies its fines from January 2027, and Malaysia has a relaxation window for smaller taxpayers. Customers may still refuse invoices that do not comply, with or without fines.

The last point matters in practice. Even when the state is patient, a large customer's accounts payable team is not. If they must receive structured invoices, they will ask you for them.

What your invoicing or ERP software must handle

The mandates look different, but the demands on software are similar. This is the checklist to hold your system against.

Structured data, not a PDF with extra steps

The invoice must be generated as structured data from the order or sales record: EN 16931 in UBL or CII for Europe, or the local format elsewhere. The risky pattern is a system that builds a PDF and then asks a third-party tool to read the PDF back into XML. Every conversion loses precision. The better design produces the structured invoice from the same record that produces the PDF, so the two cannot disagree.

Master-data quality

Structured invoices are strict. A missing tax ID, a wrong country code or a free-text address in the wrong field gets the invoice rejected. Before any mandate date, clean up:

• customer and supplier tax IDs, with a validation check where the authority offers one;
• legal names and structured addresses, with country, city and postcode in separate fields;
• routing identifiers, such as a Peppol ID or a buyer reference, where the country uses them;
• tax categories and exemption reasons on every product and service.

Numbering, credit notes and corrections

Invoice numbers must be unique and sequential under most regimes, and a cleared invoice generally cannot be edited. A mistake is fixed with a credit note that refers to the original, then a new invoice. Your software needs a proper credit-note flow linked to the original invoice number, not a "delete and reissue" button. Partial credits, price corrections and returns all follow this path.

Status tracking and rejections

In a networked system, "sent" is not the end of the story. An invoice can be accepted, rejected, queued or approved for payment. Your software should store that status per invoice, show it to the people who chase payments, and alert someone when a rejection arrives. A rejection should come with a readable reason and a clear way to fix and resubmit, not a stack trace in a log.

The figure below follows one invoice through a clearance regime. It can bounce at two checkpoints, and both rejections end up in the same place: a data fix.

Archiving and audit trail

The legal original is now the structured file, so that is what you must keep, unaltered, for the legal retention period. Retention periods differ by country, and some have changed recently (Germany shortened its invoice retention to eight years in 2025). Look for immutable storage of the original file, a record of who changed what, and the ability to export on request for an audit.

Connectivity and APIs

Your system has to talk to something outside: an access point, an approved platform or the tax authority's API. Ask how it connects. A good setup supports more than one provider, lets you change provider without rebuilding invoices, retries safely after a timeout, and never sends the same invoice twice. Authentication certificates and tokens also expire, so someone must own that renewal.

More than one country

If you sell across borders, you face different formats, models and deadlines at once. The software should treat country rules as configuration, not as a branch of custom code, so that adding a market does not mean rewriting invoicing. Multi-currency, multi-entity numbering and per-country tax rules need to work together.

A readiness checklist

Use this as a quick self-assessment. If you answer "no" or "don't know" to several of these, start sooner rather than later.

• We know which mandates apply to us, by country and by our own turnover.
• We know whether each one is receive-only, issue, or both, and when penalties start.
• Our system can produce a structured invoice (EN 16931 or the local format) directly from the order.
• Tax IDs and structured addresses are complete for at least our top customers and suppliers.
• Credit notes link to the original invoice and carry the required reference.
• We can see a status for every sent invoice and get alerts for rejections.
• Received structured invoices can be read automatically, not retyped.
• The original structured files are stored unaltered for the legal period.
• We have a named owner for the access-point or platform connection and its certificates.
• We have tested the whole flow in a sandbox before the deadline.

A six-step project plan

For most growing businesses, the work fits into one quarter or two. This order keeps it manageable.

1. Map your obligations. List each country you invoice in or buy from, the mandate, your wave and the penalty start date. Put the nearest date on the calendar and work backwards.
2. Audit your invoice flow. Trace how an invoice is created, approved, sent, paid and archived today. Note every manual step and every tool involved.
3. Fix the master data. Clean tax IDs, addresses and tax categories. This step is boring and takes the longest, so start it first.
4. Choose your connection. Decide between a certified access point or approved platform, a direct integration to the tax authority, or a provider bundled with your software. Compare price per invoice, support, uptime and exit terms.
5. Configure and test. Set up formats, numbering and credit-note flows. Run realistic cases in a sandbox: normal sale, discount, return, rejection, partial credit, foreign customer.
6. Go live gradually and monitor. Start with a few customers, watch rejection rates and fix the causes. Train the finance team on what a rejection means and who handles it.

Common mistakes to avoid

• Waiting for the deadline month. Provider onboarding, certificates and testing queues all stretch near deadlines.
• Treating it as an IT-only task. Finance owns the rules, sales owns the customer data and IT owns the connection. All three have to be in the room.
• Buying a PDF converter. It can look compliant on day one and fail on the first credit note.
• Ignoring incoming invoices. Receive obligations often start first, and automatic processing of supplier invoices is where most of the time savings are.
• Forgetting the next country. A design that works for one market but cannot be extended will be redone within two years.

Back to the wholesaler. Her system now builds the structured invoice from the same order record as the PDF, checks tax IDs when a customer is created, and keeps a status for every invoice. The 600 invoices go out without retyping. The few that bounce each month arrive with a readable reason, and a clerk fixes the buyer's missing reference and resubmits the same day. The 100 hours of retyping are gone, and so is the Monday surprise.

Key takeaways

• An e-invoice is a structured, machine-readable file, not a PDF. In Europe the common standard is EN 16931, in UBL or CII syntax.
• Know the model per country: post-audit, clearance or Peppol-style exchange, sometimes with extra reporting.
• Main dates: Belgium and Croatia January 2026, Poland February and April 2026, France September 2026 (SMEs September 2027), Germany issuing from 2027 and 2028, the EU cross-border rule in July 2030. Spain, the UAE, Saudi Arabia and Malaysia are phasing in on their own schedules.
• Your software needs structured generation, clean master data, credit notes, status tracking, archiving and flexible connectivity.
• Deadlines move and thresholds differ, so check your local rules with your tax authority or accountant before you commit.
• Start with the data and the receiving side; both are needed whatever connection you pick.

Anichur Rahaman is a software architect and the creator of StoreConsole. He designs commerce and ERP systems for growing businesses, with a focus on event-driven architecture, data integrity and self-hosted operations.