E-invoicing, answered plainly.

An e-invoice is a structured data document a machine can process without reading a layout — typically XML or JSON against a defined schema. A PDF, even a well-designed one, is a picture of an invoice: a human can read it, software cannot reliably extract it, and a tax authority cannot validate it. Almost every mandate in the 40 jurisdictions tracked here says explicitly that a PDF or a scan does not satisfy the obligation. This is the single most common misunderstanding at the start of a project.

Under clearance, the tax authority validates the invoice before it is legally issued — the invoice is not valid until the regulator returns an identifier such as an IRN, UUID or cryptographic stamp. A rejection blocks the sale, so the rejection path is the part you must build first. Under post-audit, you issue the invoice and the authority inspects later, which moves correctness from a gate to your own responsibility. Of the jurisdictions here, 21 run a clearance model. Getting this distinction wrong is what causes teams to under-scope: clearance is an operational dependency in your order-to-cash flow, not a reporting feature.

Peppol is a network and a set of specifications for exchanging documents between businesses through accredited access points — a four-corner model, where each party connects to a provider and the providers interoperate. It is infrastructure, not a law. A country can mandate e-invoicing without Peppol, or adopt Peppol without mandating it. 11 of the jurisdictions here use a Peppol-based model. Some add a fifth corner so the tax authority receives the data too, which is what "5-corner" means.

EN 16931 is the European standard defining the semantic data model of an invoice — which fields exist and what they mean — with national CIUS profiles narrowing it per country. PINT (Peppol International Invoice) is OpenPeppol's equivalent for use beyond Europe, with country specifications such as PINT-AE, PINT-OM, PINT-MY and JP PINT. They share ancestry, so mappings look similar, but they are not interchangeable: a valid EN 16931 invoice is not automatically a valid PINT-AE invoice.

40 of the 40 jurisdictions tracked here have at least one obligation already in force, and the rest have dated phases ahead. The honest answer is that "required" depends on your entity, turnover and document type — most mandates phase in by threshold rather than switching on at once. The country briefs list every phase with its date and threshold so you can locate your own entity.

It depends on the model. Decentralised Peppol regimes require you to reach the network through an access point, which in practice means a provider. Clearance regimes vary: some publish a direct API you may integrate with, others require an accredited intermediary. The UAE requires appointing an accredited service provider; Saudi Arabia lets you integrate with Fatoora directly. Our provider directory is deliberately neutral — Cloudare takes no reseller incentive and integrates whichever provider you choose.

Field mapping and master data, not the integration. The connection to a network or API is a well-understood piece of work. What consumes the schedule is producing correct values for every mandatory and conditional field: tax codes, place of supply, reverse-charge flags, buyer tax identifiers, HSN/SAC or equivalent classifications. Customer and vendor master records almost never hold the identifiers a clearance regime demands, so there is usually a data remediation workstream nobody budgeted for.

Under clearance regimes the practical consequence usually precedes the fine: an uncleared invoice is not a valid tax invoice, so your customer cannot recover input tax and may refuse to pay it. Penalties vary widely — Germany runs to EUR 5,000 per non-compliant invoice, Belgium uses a progressive EUR 1,500 / 3,000 / 5,000 ladder, Poland can reach a share of the VAT on the invoice. Several regimes open with a penalty-free or documented-effort period, but those windows close on a fixed date. Each country brief records the specific exposure.

It depends more on which country than which ERP. We track 12 platforms; SAP S/4HANA, Oracle Fusion and NetSuite ship statutory modules with real country coverage, while SME-tier systems typically rely on localisation packs or partner add-ons. Even where a native module exists it usually covers the format and not the whole obligation — archiving, rejection handling and the human-readable copy are frequently left to you. The ERP pages set out components and the known watch-outs per platform.

Retention runs from five to eleven years depending on the country, and the requirement is normally to keep the structured original rather than a rendering of it. Archiving the PDF you sent the customer is a common and expensive mistake: in an audit the authority asks for the file it validated, complete with its signature or stamp. Some regimes also require the archive to be held in-country. The archive period is listed on every country brief.

VAT in the Digital Age is the EU package that will require digital reporting of intra-EU B2B transactions from July 2030, with domestic reporting following in several member states. Its practical effect is already visible: member states without a domestic mandate are increasingly legislating straight to the ViDA timetable rather than building an interim national regime first, which is why several EU dates on this site cluster on 2030.

Every one of the 106 news entries cites a source, and every country record carries its regulator link plus a last-verified date shown on the page. Sources are primary regulator publications where available, otherwise established trade sources. Editorial policy is published in full on the About page. Where a date is proposed rather than legislated, the brief says so — several jurisdictions here are carrying expected dates that a pending instrument has not yet activated.