Ask three vendors what “the Peppol format” is and you will hear EN 16931, UBL and Peppol BIS Billing 3.0. All three are right: they are layers. Peppol document formats stack a semantic standard (EN 16931), a syntax (UBL 2.1 or UN/CEFACT CII) and a profile that narrows both down (Peppol BIS Billing 3.0, XRechnung); national schemas such as ISDOC sit outside the stack. This guide from our Peppol hub sorts the layers out and says plainly what our own certified Access Point accepts; how the network works is explained separately.
One semantic model (EN 16931), two syntaxes (UBL 2.1, CII), many profiles (CIUS)
EN 16931-1 is the European core-invoice standard: roughly 160 business terms plus the rules that bind them, published by CEN in 2017 under Directive 2014/55/EU. The model is syntax-neutral; companion specifications bind it to UBL 2.1 (CEN/TS 16931-3-2) and UN/CEFACT CII D16B (CEN/TS 16931-3-3), the two syntaxes EU public bodies must be able to receive.
A CIUS (Core Invoice Usage Specification) may only restrict the standard: mandatory terms, shorter code lists, national rules. Anything that adds terms is an extension. “EN 16931 compliant” therefore says nothing about whether a channel accepts the file: a valid XRechnung in CII still bounces off a Peppol receiver that registered UBL only.
| Format | Syntax | Through Peppol as is? |
|---|---|---|
| Peppol BIS Billing 3.0 (OpenPeppol CIUS) | UBL 2.1 (CII optional) | Yes, network-wide |
| XRechnung 3.0 (DE, KoSIT CIUS) | UBL 2.1 or CII | Yes, to German receivers |
| ZUGFeRD / Factur-X (hybrid) | CII in PDF/A-3 | No, map the XML to UBL |
| ebInterface 6.1 (AT) | own XML | No |
| ISDOC 6.0.2 (CZ) | own XML | No, mapping needed |
| FatturaPA (IT, SDI) | own XML | No, SDI is the channel |
| NLCIUS / SI-UBL 2.0 (NL) | UBL 2.1, own CIUS | Yes, as its own document type; BIS 3.0 with NL-R rules runs alongside |
| EHF Billing 3.0 (NO) | UBL 2.1 on BIS 3.0 | Yes, with NO-R rules |
| OIOUBL 2.1 (DK, NemHandel) | UBL 2.0 | No, Peppol BIS 3.0 runs alongside |
| KSeF FA(3) (PL) | own XML | No, B2G platform PEF uses BIS 3.0 |
| PINT (EU, A-NZ, JP, SG, MY, AE, OM) | UBL 2.1 | Yes, where registered |
Peppol BIS Billing 3.0: customization and profile IDs, what it adds to EN 16931
Peppol BIS Billing 3.0 is OpenPeppol’s CIUS of EN 16931 and the billing format of the whole network. Two header identifiers tell the receiving Access Point how to validate a document:
cbc:CustomizationID=urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0cbc:ProfileID=urn:fdc:peppol.eu:2017:poacc:billing:01:1.0
The specification is released in May and November: 3.0.21 was published on 20 May 2026 and became mandatory on 17 August 2026, following 3.0.20 (mandatory from 23 February 2026). What the BIS adds to the bare standard:
- Syntax decision. UBL 2.1 Invoice and CreditNote are mandatory for every receiver; CII D16B is optional (a receiver “can register in the SMP to receive CII invoices alongside the mandatory UBL version”), so UBL is the safe default.
- Peppol rules (
PEPPOL-EN16931-R,PEPPOL-COMMON-R): endpoint IDs with a valid EAS scheme, GLN format, consistent rounding. - Country rules by country code (DE, DK, GR, IS, IT, NL, NO, SE): a Dutch supplier, for instance, needs a KVK or OIN identifier. There is no SK block; Slovak specifics live in the Tax Data Document.
Our own certified Access Point accepts and delivers this, plus Peppol BIS Self-Billing 3.0 (profile urn:fdc:peppol.eu:2017:poacc:selfbilling:01:1.0); we passed OpenPeppol’s SK Billing 3.0.20 and SK Self-Billing 3.0.1 conformance suites in May 2026.
Slovakia: BIS Billing 3.0 plus the Tax Data Document (TDD SK), there is no PINT-SK
Act no. 385/2025 Coll. does not invent a Slovak format. From 1 January 2027 VAT payers must issue structured e-invoices (§ 85o of the VAT Act) and practically every business must be able to receive them through a certified delivery service (§ 71 par. 5). The structured document is an EN 16931 invoice, in practice UBL 2.1 Peppol BIS Billing 3.0, and the “digitálny poštár” is a certified Peppol Access Point (details in the mandate guide). Three things are Slovak-specific:
- Participant IDs. Companies are addressed as
0245:plus the DIČ digits, no “SK” prefix (9950:SK…is test-network only); check any company with the free Peppol ID checker. - The Tax Data Document. OpenPeppol publishes the Slovak Republic Tax Data Document 1.0.0 (released 14 April 2026): a separate XML document (root element
TaxData, customization IDurn:peppol:taxdata:sk-1, profileurn:peppol:taxreporting) “sent by the sender or the receiver, to tax authorities to report an invoice”. The Access Point derives it from the invoice and sends it to the Financial Administration as the fifth corner of the 5-corner model; ours does this automatically for domestic invoices from Slovak VAT payers. - No PINT-SK. OpenPeppol’s PINT specialisations (listed below) include no Slovak entry; the Slovak conformance suite is simply “SK Billing 3.0”.
In one line: UBL BIS 3.0 is the format, Peppol is the delivery, TDD is the report.
Germany and Austria: XRechnung, ZUGFeRD/Factur-X, ebInterface and how they relate to Peppol
Germany runs on XRechnung, the CIUS operated by KoSIT: version 3.0 has been in force since 1 February 2024 and stays valid until at least 31 July 2027. It comes in UBL 2.1 or CII and travels over Peppol to Leitweg-ID addresses (0204:) and companies (9930:DE…). Receiving e-invoices has been mandatory for domestic B2B since 1 January 2025; issuing follows in 2027 and 2028. The Federal Ministry of Finance’s letter of 15 October 2024 names XRechnung and ZUGFeRD from version 2.0.1, except the MINIMUM and BASIC-WL profiles, as compliant formats (Rn. 25) and leaves the channel to the parties, e-mail included (Rn. 36). More in E-invoicing in Germany.
Austria has obliged the federal government’s suppliers to send structured e-invoices since 1 January 2014 (§ 5 IKTKonG), via the USP portal or Peppol. On Peppol the federal government lists Peppol BIS Billing 3.0 UBL Invoice and CreditNote; all federal recipients share one participant ID, 9915:b, and the department is derived from the order reference. ebInterface, the Austrian XML standard of AUSTRIAPRO’s e-billing working group, is accepted in versions 4.3 to 6.1 by upload or web service, but it is not a Peppol document type. See E-invoicing in Austria.
A BIS Billing 3.0 invoice therefore reaches German and Austrian Peppol receivers unchanged (DE-R rules permitting). The reverse direction needs mapping: our API does not accept XRechnung in CII, ZUGFeRD or Factur-X; we map them to UBL 2.1 on request, priced by scope.
Czechia: ISDOC 6.x, who maintains it, why it is not a Peppol format and how conversion works
ISDOC (Information System Document) is the Czech national e-invoice schema, currently version 6.0.2 of 23 March 2022. Defined by ICT Unie, it is now maintained by the Czech Ministry of the Interior. ISDOCX bundles the XML with attachments; 6.0.2 added ISDOC.PDF, the XML embedded in a PDF/A-3.
Its legal footing is B2G only: government resolution no. 347/2017 obliges central state administration bodies to accept e-invoices in the Directive 2014/55/EU formats (UBL 2.1, CII) and ISDOC/ISDOCX 5.2 or higher since 31 December 2018, and § 279 par. 5 of the public procurement act 134/2016 extended EN 16931 receipt to all contracting authorities by 1 April 2020. There is no Czech B2B mandate; Czech firms meet Peppol through Slovak, Austrian or German customers.
ISDOC is not a Peppol format: Access Points register only EN 16931 document types. It must be mapped to UBL 2.1 BIS Billing 3.0 first, with known traps: ISDOC document types (including the non-tax zálohová faktura, type 4, and the daňový doklad k přijaté platbě, type 5) do not map one-to-one onto UNCL1001 codes, and VAT regime flags become EN 16931 VAT categories. Our portal imports and exports ISDOC 6.0.2 for Czech accounting packages; the API accepts UBL only. More in E-invoicing in Czechia.
Other national profiles: FatturaPA, NLCIUS, OIOUBL, EHF, FA(3), PINT for non-EU
- Italy: FatturaPA. Every invoice passes through the Agenzia delle Entrate’s Sistema di Interscambio (SDI); e-invoicing has been mandatory since 1 January 2019. FatturaPA is a national XML aligned with EN 16931, and SDI converts incoming European-standard invoices into it.
- Netherlands: NLCIUS / SI-UBL 2.0. SI-UBL 2.0 implements NLCIUS; Peppol BIS 3.0 is the preferred format for public bodies. No B2B mandate.
- Denmark: OIOUBL. The UBL 2.0-based NemHandel format; OIOUBL 3.0 was cancelled in January 2026 and the Danish Business Authority plans to migrate NemHandel to a Peppol BIS-based format (Nemhandel BIS 4) by mid-2029. The 2022 Bookkeeping Act requires digital bookkeeping systems to send and receive e-invoices via NemHandel and Peppol.
- Norway: EHF. The national CIUS on Peppol BIS Billing 3.0 with the NO-R rules; DFØ authorises Norwegian Access Points and runs the ELMA registry, a Peppol SMP.
- Poland: FA(3) and PEF. B2B invoices go through the KSeF clearance platform in the Ministry of Finance’s FA(3) structure (the only permitted structure since 1 February 2026); the B2G platform PEF operates inside the Peppol network on BIS Billing 3.0.
- PINT outside the EU. The Peppol International Invoice is OpenPeppol’s template for invoice specifications across jurisdictions; specialisations carry a suffix on the customization ID (for example
@eu-1). PINT BIS Billing 1.1.3 and the EU, A-NZ, Japan, Malaysia, Singapore, UAE and Oman specialisations were published in June and July 2026. The Peppol network supports PINT; our Access Point works with BIS Billing 3.0.
Mandates per country: E-invoicing mandates by country.
Invoice type codes and document types: 380, 381, 383, 388, self-billing 389, orders and despatch advice (education only)
The business meaning of a UBL document sits in BT-3, the invoice type code from UN/CEFACT list 1001. BIS Billing 3.0 allows 27 invoice codes and five credit-note codes and tells receivers to process every invoice code like a 380 and every credit-note code like a 381. The codes that matter in Slovak practice:
| Code | Meaning | UBL message | Slovak usage |
|---|---|---|---|
| 380 | Commercial invoice | Invoice | Standard faktúra |
| 381 | Credit note | CreditNote | Dobropis |
| 383 | Debit note | Invoice | Ťarchopis |
| 384 | Corrected invoice | Invoice | Not yet enabled for Slovak parties; our Access Point rejects it for now |
| 386 | Prepayment invoice | Invoice | Rare in Slovakia: a zálohová faktúra is a payment request, not a VAT document; the tax document to a received payment is 388 |
| 388 | Tax invoice | Invoice | Tax document to a received payment |
| 389 | Self-billed invoice | Invoice | Buyer issues for the supplier (Self-Billing BIS) |
| 261 | Self-billed credit note | CreditNote | Self-billing counterpart of 381 |
| 393 | Factored invoice | Invoice | On the network, not in our composer |
Self-billing is a separate Peppol BIS with reversed roles (the customer sends, the supplier receives); our Access Point supports it.
The Peppol network also supports the post-award documents Order, Order Response, Despatch Advice and Catalogue, plus Message Level Response (MLR) and Invoice Response, with which a buyer accepts or rejects an invoice. These are educational here: Verteco Peppol is a billing service and does not process them. For every sent invoice you see two statuses: the Peppol delivery status (an MLS delivery receipt where the receiving Access Point returns one) and the Financial Administration’s reporting status; see Peppol status messages.
Hybrid PDF/XML formats explained
A hybrid e-invoice is a PDF/A-3 with the structured XML embedded as an attachment: people read the PDF, software reads the XML. ZUGFeRD (Germany) and Factur-X (France) are technically identical; the current joint release of FeRD and FNFE-MPE is Factur-X 1.09.2 / ZUGFeRD 2.5.2 (4 August 2026). The profiles run from MINIMUM and BASIC WL through BASIC to EN 16931 and EXTENDED. The BMF letter of 15 October 2024 excludes MINIMUM and BASIC-WL and makes the XML the leading part (Rn. 31): where PDF and XML differ, the XML counts.
On Peppol, hybrids do not travel as hybrids: the network carries the UBL document, and a PDF rendering can ride along as an embedded attachment (BG-24, base64), which our Access Point accepts and makes downloadable. A plain PDF without XML is not an e-invoice at all (Electronic invoicing explained); until 30 June 2030 a Slovak supplier may still e-mail an invoice, but only with the recipient’s consent and only as EN 16931 XML (see Peppol transition until 2030).
Validate before you send: Schematron, rule IDs like BR-CO-15, Slovak UBL samples
A Peppol invoice is validated in stages, each with its own rule-ID prefix:
- XML schema (XSD): well-formed UBL 2.1 Invoice or CreditNote.
- EN 16931 rules:
BR-(mandatory terms),BR-CO-(calculations),BR-CL-(code lists),BR-DEC-(decimals). BR-CO-15 reads “Invoice total amount with VAT (BT-112) = Invoice total amount without VAT (BT-109) + Invoice total VAT amount (BT-110)”, a classic rounding failure. - Peppol rules:
PEPPOL-EN16931-R…andPEPPOL-COMMON-R…. - Country rules:
DE-R-,NL-R-,NO-R-and the rest, triggered by country codes. - UBL syntax rules:
UBL-SR-(cardinality) andUBL-CR-(warnings).
Every rule is fatal (rejected) or a warning (delivered); the rules ship as Schematron files with each BIS release.
Our engine (UBL XSD, EN 16931 and Peppol BIS 3.0 Schematron) checks inbound and outbound documents; the same check is open without an account as a public validator on the portal (files up to 3 MB), with rule IDs translated into plain language. The portal also carries a set of validated Slovak UBL samples (invoice, credit note, debit note, reverse charge, embedded PDF and more) and a free sandbox on the Peppol test network, so your ERP integration can be tested end to end; samples and the API reference are in the developer documentation.
Next step. Whatever your software exports today, the destination for Slovak e-invoicing is UBL 2.1 Peppol BIS Billing 3.0 through a certified Access Point that generates the TDD for you. Register your company on the Verteco Peppol portal: receiving without the Data archive is free (fair use up to 1 000 received invoices a month), the complete service costs 2 € + VAT per company per month from 1 January 2027, and the validator and sandbox are open to everyone.
