--- title: "E-invoicing formats" description: "Every e-invoicing format, explained: EN 16931, UBL 2.1, UN/CEFACT CII, Peppol BIS Billing 3.0 and PINT, Factur-X and ZUGFeRD, XRechnung, FatturaPA, Facturae, KSeF FA(3), ZATCA, MyInvois — which ones Flowie sends and receives, and a link to every official specification." canonical: "https://docs.get-flowie.com/reference/formats" source: "https://docs.get-flowie.com/reference/formats.html" --- # E-invoicing formats API Reference # E-invoicing formats An **e-invoicing format** is the machine-readable structure an invoice travels in — not a PDF of an invoice, but the invoice itself as data a buyer's system can book without retyping. There are only **two XML syntaxes** that matter in Europe ([UBL 2.1](<#ubl>) and [UN/CEFACT CII](<#cii>)), one semantic standard on top of them ([EN 16931](<#en16931>)), and then a long tail of **national profiles** — [Factur-X](<#hybrid>), [ZUGFeRD](<#hybrid>), [XRechnung](<#national>), [FatturaPA](<#national>), [Facturae](<#national>), [KSeF FA(3)](<#national>), [ZATCA](<#clearance>), [MyInvois](<#clearance>) — that constrain the same data for one country's tax administration. This page is the complete map, and says exactly which of them Flowie produces, accepts and delivers. You do not have to pick one Send [`POST /v1/documents/send`]() your invoice as JSON and Flowie renders the syntax the destination requires — Peppol BIS Billing 3.0 UBL for the Peppol network, the country-native format where the tax administration mandates one. Already have XML? Deposit [UBL](<#ubl>), [CII](<#cii>) or a [Factur-X PDF](<#hybrid>) and Flowie validates and routes it as-is. The `format` field is documented under [what Flowie handles](<#flowie>). ## The short answer, by country If you only read one section, read this one. In 2026 the format question resolves to four cases: * **You are sending inside the EU over Peppol** (Belgium, the Netherlands, the Nordics, Ireland, most B2G) → [Peppol BIS Billing 3.0](<#peppol>), which is UBL 2.1 constrained to EN 16931. This is the default Flowie emits. * **You are sending to a country with its own clearance platform** (Italy, Poland, Romania, Spain, Saudi Arabia, India, Malaysia, Egypt, Turkey) → the [national format](<#clearance>) that platform accepts, cleared before or as the invoice is delivered. * **You are sending in France or Germany** → a [hybrid Factur-X / ZUGFeRD PDF](<#hybrid>), or plain [CII](<#cii>)/[UBL](<#ubl>), or [XRechnung](<#national>) for German public buyers. All three are legal; the buyer's capability decides. * **You do not know** → send JSON and let Flowie resolve the recipient's capability from the network directory. That is what [`POST /v1/directory/verify`]() answers. Per-country mandates, deadlines and the exact network each one runs on are documented in the [compliance section](<../compliance/index.html>) — 47 jurisdictions, with a [coverage matrix](<../compliance/index.html#matrix>) you can sort by network. ## The four layers: model, syntax, profile, network Almost every argument about e-invoicing formats is two people talking about different layers. An invoice on the wire is four decisions stacked, and each is independent of the others: Layer| What it fixes| Examples ---|---|--- **1\. Semantic model** | Which business terms exist and what they mean — `BT-1` is the invoice number, `BT-9` the due date. No syntax at all. | [EN 16931](<#en16931>), the semantic core of every European format **2\. Syntax** | How those terms are serialised into a file a parser can read. | [UBL 2.1](<#ubl>) (OASIS), [UN/CEFACT CII D16B](<#cii>) **3\. Profile / CIUS** | Which optional terms become mandatory, which code lists are allowed, which national identifiers are required. A _CIUS_ narrows EN 16931; an _extension_ adds to it. | [Peppol BIS Billing 3.0](<#peppol>), [XRechnung](<#national>), [Factur-X EN 16931 profile](<#hybrid>), [PINT](<#peppol>) **4\. Network / transport** | How the file reaches the buyer and the tax administration. | Peppol AS4 4-corner, Italy's SDI, France's PA/PDP, Poland's KSeF, Saudi Fatoora "Is XRechnung a format?" It is a _profile_ (layer 3) that can be carried in either syntax (layer 2) and always satisfies the same semantic model (layer 1). That is why an XRechnung invoice and a Peppol BIS invoice can be byte-different and still carry identical business content — and why converting between them is a mapping exercise, not a re-keying one. Flowie holds the semantic model once, in the [document data model](), and renders the layers below it. ## What Flowie handles Two directions, one endpoint each. On the way **out** , the `format` field on [`POST /v1/documents/send`]() declares what you are handing us: `format`| What you send| What Flowie does ---|---|--- `json` | The canonical [Flowie document model]() in the `document` field. | Renders EN 16931-compliant UBL 2.1 (Peppol BIS Billing 3.0 customisation), then delivers it in the destination's native format. `ubl-xml` | Your own UBL 2.1 `Invoice` or `CreditNote` XML in `xml`. | Validates against the EN 16931 and national schematrons, then routes it. Your bytes stay the emitted original. `cii-xml` | UN/CEFACT `CrossIndustryInvoice` XML — including the XML extracted from a Factur-X or ZUGFeRD PDF. | Same: CII schematrons, then routing. `auto` | A file in `file.content` and no opinion about it. | Sniffs the magic bytes and the XML root element — `CrossIndustryInvoice` → CII, `Invoice`/`CreditNote` → UBL, `%PDF` → PDF — and picks the pipeline. This is the safe default. `raw` | Anything else — a PDF, a scan, a spreadsheet. | Stores it as-is, no network routing, no structured validation. Announce CII as CII A Factur-X deposit is **CII, not UBL**. Declaring `format: "ubl-xml"` for it runs the wrong schematron and reports a perfectly valid invoice as broken. If you are not certain, use `auto` — the root element decides, and it is never wrong. On the way **in** , every document you receive is available in three shapes from [the document endpoints](): the **original** artefact exactly as the sender deposited it (the Factur-X PDF, if that is what they sent), the **structured XML** , and the normalised **JSON** that [webhooks]() carry. You never have to parse a syntax you do not want to support. On the French leg, the AFNOR XP Z12-013 flow declares its syntax explicitly — `CII`, `UBL`, `Factur-X` for invoices, plus `CDAR` for lifecycle statuses and `FRR` for e-reporting. See the [French integration playbook](<../compliance/fr/integration.html>). ## Format catalogue Every e-invoicing format you are likely to meet, what it actually is, where it is required, and whether Flowie handles it. Click a column header to sort. Format | What it is | Where it matters | Flowie | Official reference ---|---|---|---|--- [**EN 16931**](<#en16931>) | Semantic model (not a file format) | EU-wide baseline; every European profile is a CIUS of it | Native | [European Commission]() [**UBL 2.1**](<#ubl>) | XML syntax (OASIS) | Peppol, Denmark, Norway, Netherlands, Saudi Arabia, Malaysia, Turkey | Send & receive | [OASIS UBL 2.1]() [**UN/CEFACT CII**](<#cii>) (D16B) | XML syntax (Cross Industry Invoice) | France, Germany, and the XML inside every Factur-X / ZUGFeRD PDF | Send & receive | [UNECE XML schemas]() [**Peppol BIS Billing 3.0**](<#peppol>) | CIUS of EN 16931 in UBL 2.1 | The Peppol network — 30+ countries, the EU default | Send & receive | [OpenPeppol BIS 3.0]() [**Peppol PINT**](<#peppol>) | Global billing template + per-jurisdiction specialisations | Australia, New Zealand, Japan, Singapore, UAE, and the EU PINT profile | Send & receive | [PINT Billing]() [**Factur-X**](<#hybrid>) | Hybrid PDF/A-3 with embedded CII XML | France — the format most French suppliers will emit | Send & receive | [FNFE-MPE]() [**ZUGFeRD**](<#hybrid>) | The same hybrid standard, German edition | Germany — B2B, interchangeable with Factur-X | Send & receive | [FeRD]() [**XRechnung**](<#national>) | German CIUS of EN 16931 (UBL or CII) | Germany — mandatory for federal B2G, widely used B2B | Send & receive | [KoSIT / XÖV]() [**FatturaPA**](<#national>) | Italian national XML schema (pre-dates EN 16931) | Italy — every B2B, B2C and B2G invoice, cleared through SDI | Send & receive | [Agenzia delle Entrate]() [**Facturae**](<#national>) | Spanish national XML, signed with XAdES | Spain — B2G via FACe, alongside the Crea y Crece B2B rollout | Send & receive | [facturae.gob.es]() [**KSeF FA(3)**](<#national>) | Polish national XML schema | Poland — mandatory B2B clearance through KSeF from 2026 | Send & receive | [Ministerstwo Finansów]() [**ISDOC**](<#national>) | Czech UBL-derived XML, in use since 2009 | Czechia — public sector accepts ISDOC and Peppol BIS | Send & receive | [ISDOC specification]() [**OIOUBL**](<#national>) | Danish UBL profile, pre-dating Peppol | Denmark — NemHandel, legacy public-sector ERPs | Send & receive | [oioubl.info]() [**EHF**](<#national>) | Norwegian profile, now a thin layer over Peppol BIS | Norway — B2G since 2012 | Send & receive | [DFØ / Anskaffelser]() [**Finvoice**](<#national>) | Finnish bank-led XML standard | Finland — bank channels, alongside Peppol BIS | Send & receive | [Finance Finland]() [**ebInterface**](<#national>) | Austrian XML standard | Austria — accepted alongside Peppol BIS on the federal portal | Send & receive | [ebInterface]() [**ZATCA e-invoice**](<#clearance>) | UBL 2.1-based XML, cryptographically stamped | Saudi Arabia — Fatoora clearance and reporting | Send & receive | [ZATCA]() [**MyInvois**](<#clearance>) | UBL 2.1 in XML or JSON | Malaysia — LHDN clearance, phased by turnover | Send & receive | [MyInvois SDK]() [**GST e-invoice (INV-01)**](<#clearance>) | JSON schema registered with an IRP for an IRN | India — B2B above the turnover threshold | Send & receive | [GST e-Invoice portal]() [**ETA e-invoice**](<#clearance>) | JSON/XML submitted to the tax authority | Egypt — universal B2B/B2G clearance | Send & receive | [Egyptian Tax Authority]() [**UBL-TR (e-Fatura)**](<#clearance>) | Turkish UBL 2.1 customisation | Türkiye — e-Fatura and e-Arşiv | Send & receive | [GİB e-Fatura]() [**UN/EDIFACT INVOIC**](<#legacy>) | Pre-XML EDI message | Retail, automotive and logistics supply chains | On request | [UNECE EDIFACT]() [**PDF / scan**](<#legacy>) | Not an e-invoicing format | Nowhere, legally, once a mandate is live | Stored as-is | — **Send & receive** means Flowie renders the format on the way out and normalises it on the way in — you work in JSON and never touch the schema. Country-by-country detail, including which network carries which format, is in the [coverage matrix](<../compliance/index.html#matrix>). ## EN 16931 — the European semantic standard **EN 16931 is not a file format.** It is the semantic data model that says what an invoice contains: 164 business terms (`BT-1`…) grouped into business groups (`BG-1`…), plus roughly 200 business rules that say when each is required and how the totals must add up. Every European e-invoicing format is a constraint on it. It exists because of EU Directive 2014/55/EU, which obliged public buyers across the Union to accept electronic invoices in a common standard. **EN 16931-1:2026 was published in May 2026 and formally withdrew the 2017 edition** , with a migration period while profiles catch up — so a document that validates against a 2017-era schematron will keep validating for now, and the practical change arrives when each national profile republishes against the new edition. The companion **CEN/TS 16931-2** lists the syntaxes that comply with it, and there are exactly two: [UBL 2.1](<#ubl>) and [UN/CEFACT CII](<#cii>). Everything else in Europe is a profile of one of those two. Flowie exposes the model directly: the [business-terms referential](<../compliance/fr/business-terms.html>) lists all 164 BTs, what each maps to in UBL and CII, and which ones France additionally requires. Validation failures come back naming the business term, not the schematron step — see [the error catalog](). ## UBL 2.1 — the XML syntax most networks speak **UBL (Universal Business Language) 2.1** is an OASIS standard defining XML schemas for the whole procurement chain — orders, despatch advices, invoices, credit notes. Its `Invoice` and `CreditNote` documents are one of the two EN 16931-compliant syntaxes, and the one the Peppol network chose. An EN 16931 UBL invoice announces its profile in two elements at the top of the document: [code] urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0 urn:fdc:peppol.eu:2017:poacc:billing:01:1.0 [/code] `CustomizationID` is the _profile_ — the CIUS the document claims to satisfy. `ProfileID` is the _business process_ it belongs to. Get either wrong and a compliant access point will reject the document before a human sees it. Flowie writes both for you when you send `format: "json"`, and validates them when you deposit your own XML. UBL is also the base of several national formats that pre-date or extend the European standard — [OIOUBL](<#national>) (Denmark), [ISDOC](<#national>) (Czechia), [UBL-TR](<#clearance>) (Türkiye), [ZATCA](<#clearance>) (Saudi Arabia) and [MyInvois](<#clearance>) (Malaysia). ## UN/CEFACT CII — the other compliant syntax **CII (Cross Industry Invoice)** is UN/CEFACT's XML syntax, standardised in schema release **D16B**. Its root element is `rsm:CrossIndustryInvoice`, and it carries the same EN 16931 business terms as UBL in a different tree — three top-level sections (`ExchangedDocument`, `SupplyChainTradeTransaction` and the header context) instead of UBL's flatter layout. CII matters far more than its market share suggests, because it is the XML embedded inside every [Factur-X and ZUGFeRD](<#hybrid>) PDF — which makes it the dominant syntax in France and Germany, the two largest e-invoicing markets in continental Europe. Telling them apart in one line Read the root element. `` → CII. `` or `` in a UBL namespace → UBL. That is exactly what Flowie's `format: "auto"` does, and why it is a safer choice than declaring the syntax yourself. ## Factur-X & ZUGFeRD — the hybrid PDF formats **Factur-X** (France) and **ZUGFeRD** (Germany) are the same standard published by two bodies — [FNFE-MPE]() and [FeRD]() — under two names. A Factur-X invoice is a **PDF/A-3 file with a CII XML attachment embedded inside it** : a human opens the PDF and reads an invoice; a machine opens the same file, pulls out `factur-x.xml`, and books it. One artefact, both audiences, no reconciliation problem. The standard defines a ladder of profiles, from _MINIMUM_ and _BASIC WL_ (too thin to be a legal invoice on their own) through _BASIC_ and _EN 16931_ (the fully compliant core) to _EXTENDED_ (adds terms beyond EN 16931). France's B2B reform accepts Factur-X at the EN 16931 profile and above. Flowie treats the PDF as the original: deposit a Factur-X and the embedded CII is extracted, mapped and validated, while the **PDF you sent stays the artefact returned as the original document** — which is what AFNOR XP Z12-013 requires of a French emitter, and what an auditor will ask for. See the [France overview](<../compliance/fr/index.html>) and the [Germany page](<../compliance/de.html>) for the two mandates. ## Peppol BIS Billing 3.0 and PINT **Peppol BIS Billing 3.0** is a CIUS of EN 16931 expressed in UBL 2.1, and it is the single most widely deployed e-invoicing profile in Europe. It is what travels the Peppol network's four-corner model: you send to your access point, your access point delivers to the recipient's, and an SMP lookup resolves who that is. Flowie is an access point, so [sending]() is one API call. **PINT (Peppol International)** is the newer, global generalisation: a common billing template that each jurisdiction specialises rather than fork. PINT specialisations are live or landing in [Australia and New Zealand](<../compliance/au.html>) (PINT A-NZ), [Japan](<../compliance/jp.html>) (JP PINT), [Singapore](<../compliance/sg.html>) (InvoiceNow), [the UAE](<../compliance/ae.html>) (PINT AE, on a five-corner model that adds the tax authority as a corner) — and in the EU, as [PINT EU](), the successor profile to BIS Billing 3.0. Reachability is per document type A recipient registered on Peppol advertises which document types it accepts. Before you send, ask [`POST /v1/directory/verify`]() with the _type you will actually send_ — a participant reachable for invoices is not automatically reachable for credit notes or orders. ## National European formats and CIUS Most EU countries either use Peppol BIS as-is or narrow it with a national CIUS. A handful run formats that pre-date the European standard and are still legally required. ### XRechnung (Germany) The German CIUS of EN 16931, maintained by [KoSIT](). Mandatory for invoices to federal public buyers, and the reference profile for the B2B mandate phasing in through 2028. XRechnung can be carried in either UBL or CII, and adds German specifics — _Leitweg-ID_ routing, mandatory buyer contact details. Details on the [Germany page](<../compliance/de.html>). ### FatturaPA (Italy) Italy's national XML schema, cleared through the _Sistema di Interscambio_ (SDI) for every B2B, B2C and B2G invoice. It pre-dates EN 16931 and is not a CIUS of it: it has its own element names, its own _TipoDocumento_ codes (TD01–TD29) and its own outcome messages (_esiti_) that come back asynchronously after submission. Flowie maps the canonical model onto it and surfaces the esiti as [lifecycle events]() — see the [Italy overview](<../compliance/it/index.html>) and the [TD explorer](<../compliance/it/document-types.html>). ### The rest, briefly * **[Facturae]()** (Spain) — national XML with a mandatory XAdES signature, used for B2G through FACe while the Crea y Crece B2B framework rolls out. [Spain →](<../compliance/es.html>) * **[KSeF FA(3)]()** (Poland) — the schema for the national clearance platform; an invoice has no legal existence until KSeF assigns it a number. [Poland →](<../compliance/pl.html>) * **RO e-Factura** (Romania) — a national CIUS of EN 16931 cleared through ANAF. [Romania →](<../compliance/ro.html>) * **[ISDOC]()** (Czechia) — a UBL-derived national standard from 2009; public buyers accept it and Peppol BIS. [Czechia →](<../compliance/cz.html>) * **[OIOUBL]()** (Denmark) — the Danish UBL profile carried over NemHandel, still alive in legacy public-sector ERPs. [Denmark →](<../compliance/dk.html>) * **EHF** (Norway) — now essentially Peppol BIS with Norwegian identifiers. [Norway →](<../compliance/no.html>) * **[Finvoice]()** (Finland) — a bank-led standard delivered through banking channels alongside Peppol. [Finland →](<../compliance/fi.html>) * **[ebInterface]()** (Austria) — accepted on the federal e-invoicing portal next to Peppol BIS. [Austria →](<../compliance/at.html>) * **[UBL.BE]()** (Belgium) — the Belgian Peppol BIS profile, now that the B2B mandate is live and HERMES has been retired. [Belgium →](<../compliance/be.html>) ## Clearance and reporting formats outside the EU Outside Europe the dominant model is **clearance** : the invoice is submitted to the tax administration and only becomes valid once it comes back stamped, numbered or signed. The format is whatever that platform's schema says, and it is rarely EN 16931. * **[Saudi Arabia — ZATCA / Fatoora]()** : UBL 2.1-based XML with a cryptographic stamp, a UUID and a QR code; standard invoices are cleared before issuance, simplified ones reported after. [Saudi Arabia →](<../compliance/sa.html>) * **[Malaysia — MyInvois]()** : UBL 2.1 in XML or JSON, validated by LHDN, which returns a UUID and a QR code. [Malaysia →](<../compliance/my.html>) * **[India — GST e-invoice]()** : the INV-01 JSON schema registered with an Invoice Registration Portal, which returns the IRN and a signed QR code. [India →](<../compliance/in.html>) * **[Egypt — ETA]()** : JSON/XML documents submitted to the tax authority for near-real-time clearance. [Egypt →](<../compliance/eg.html>) * **[Türkiye — e-Fatura / e-Arşiv]()** : UBL-TR, a Turkish customisation of UBL 2.1, through the GİB. [Türkiye →](<../compliance/tr.html>) * **Israel — ITA allocation number** : no new document format; invoices above a threshold need an allocation number requested from the tax authority before they are deductible. [Israel →](<../compliance/il.html>) * **China — fully digital e-fapiao** : issued inside the STA's Golden Tax IV platform rather than exchanged between trading partners. [China →](<../compliance/cn.html>) Flowie's job on these is the same in every case: you send the canonical JSON, and the country connector produces the platform's schema, submits it, and reports the outcome back as lifecycle events you can subscribe to. What differs is _when_ the invoice becomes legally valid — which is why [the lifecycle endpoint](), not the send response, is the thing to watch in a clearance country. ## Legacy EDI, and why a PDF is not an e-invoice **UN/EDIFACT INVOIC** and **ANSI X12 810** are the pre-XML EDI invoice messages, still carrying enormous volume in retail, automotive and logistics. They are structured and machine-readable, so they solve the same problem — but they are not EN 16931 syntaxes, and a mandate that names UBL or CII will not accept them. Bridging is a mapping project; talk to us if you have an EDI backbone to keep. A **PDF invoice, including one sent by email, is not an electronic invoice** under any current mandate — nor is a scan, nor a spreadsheet. The test every regulation applies is whether the invoice can be processed automatically without re-keying, which a flat PDF cannot. This is the single most common misconception in e-invoicing projects, and the reason [Factur-X](<#hybrid>) exists: it keeps the PDF a human wanted _and_ the data the regulation requires in one file. Flowie will happily store a flat PDF with `format: "raw"` — it just will not route it as a compliant invoice. ## Which format should I send? * **Building a new integration** → send `format: "json"`. You describe the invoice once; Flowie renders the right syntax per destination and re-renders it when a country changes its profile. * **Your ERP already emits UBL or CII** → deposit it with `ubl-xml` / `cii-xml`. Your bytes remain the emitted original, which matters for audit. * **Your ERP emits Factur-X or ZUGFeRD PDFs** → send the PDF with `format: "auto"`. The embedded CII is extracted and validated; the PDF stays the original. * **You are selling into Germany** → XRechnung for public buyers, Factur-X/ZUGFeRD or plain CII/UBL for B2B. [Germany →](<../compliance/de.html>) * **You are selling into Italy, Poland, Romania, Spain or a Gulf/Asian clearance country** → send JSON and let the country connector produce the national schema. The format is not really your choice there; the platform's schema is the contract. [Coverage matrix →](<../compliance/index.html#matrix>) * **You do not know what the recipient accepts** → [`POST /v1/directory/verify`]() before you send. ## Frequently asked questions ### What is the difference between UBL and CII? They are two XML syntaxes for the same semantic content. UBL 2.1 is an OASIS standard used by Peppol and most Northern European networks; UN/CEFACT CII is used in France and Germany and is the XML embedded in Factur-X and ZUGFeRD PDFs. Both are listed by CEN/TS 16931-2 as compliant with EN 16931, so an invoice can be converted from one to the other without losing business content. The root element tells them apart: `CrossIndustryInvoice` for CII, `Invoice` or `CreditNote` for UBL. ### Is Factur-X the same as ZUGFeRD? Yes — technically the same hybrid PDF/A-3 standard, published jointly by FNFE-MPE in France and FeRD in Germany under two names. A ZUGFeRD file is a valid Factur-X file and vice versa, at the same profile level. The names differ for governance and market reasons, not technical ones. ### Is XRechnung a Peppol format? No. XRechnung is a German CIUS of EN 16931; Peppol BIS Billing 3.0 is OpenPeppol's CIUS of the same standard. XRechnung documents are commonly _transported_ over the Peppol network, which is why the two are often confused, but they are different profiles with different mandatory fields — notably the German _Leitweg-ID_. ### Is a PDF invoice an electronic invoice? No. Under EU Directive 2014/55/EU and the national mandates that follow it, an electronic invoice must be issued, transmitted and received in a structured format that allows automatic processing. A PDF — or a scan, or an emailed image — does not qualify, however it was produced. A hybrid Factur-X/ZUGFeRD PDF does qualify, because the structured XML travels inside it. ### Do I have to convert my invoices myself? No. Send the canonical JSON model to [`POST /v1/documents/send`]() and Flowie produces whatever the destination requires. Conversion only becomes your problem if you insist on depositing finished XML for a country whose profile you have not implemented. ### Does EN 16931-1:2026 break my integration? Not on its own. The 2026 edition was published in May 2026 and formally withdrew the 2017 edition, but national profiles adopt it on their own timetable and validation keeps accepting the current profile versions during the migration. Anything that does change lands in the [changelog](<../changelog.html>) before it reaches you. ### Which formats does Flowie support? On input: the canonical JSON model, UBL 2.1, UN/CEFACT CII, and Factur-X/ZUGFeRD PDFs (plus any file stored as-is with `format: "raw"`). On output: Peppol BIS Billing 3.0 and PINT for the Peppol network, and the national format required by each of the 47 jurisdictions documented under [compliance](<../compliance/index.html>) — Factur-X and CII for France, XRechnung and ZUGFeRD for Germany, FatturaPA for Italy, KSeF FA(3) for Poland, Facturae for Spain, ZATCA for Saudi Arabia, MyInvois for Malaysia, and the rest of the [catalogue](<#catalogue>) above. ## Official references Primary sources, in the order the layers stack. When a national profile and this page disagree, the national profile wins — tell us and we will fix the page. * [European Commission — compliance with the eInvoicing standard]() (EN 16931, and [how to obtain a copy]()) * [OASIS — Universal Business Language 2.1]() * [UNECE — UN/CEFACT XML schemas (Cross Industry Invoice)]() * [OpenPeppol — BIS Billing 3.0]() · [PINT Billing]() · [PINT EU]() · [Peppol eDelivery (AS4)]() * [FNFE-MPE — Factur-X]() · [FeRD — ZUGFeRD]() * [KoSIT — XRechnung]() * [Agenzia delle Entrate — FatturaPA]() * [DGFiP — spécifications externes B2B]() (France) * [Ministerstwo Finansów — KSeF]() · [Facturae]() · [ISDOC]() · [OIOUBL]() · [Finvoice]() · [ebInterface]() · [UBL.BE]() * [ZATCA]() · [MyInvois SDK]() · [India GST e-invoice]() · [Egyptian Tax Authority]() · [GİB e-Fatura]() And on this site: [the send endpoint](), [the canonical document model](), [document & invoice types](), [47 country guides](<../compliance/index.html>), and [all 164 EN 16931 business terms](<../compliance/fr/business-terms.html>).