← Indietro

Country-Specific Invoice Formats: Italy, Germany, France, and Poland

Four EU countries have introduced national invoice formats with their own structures, validation rules, and submission platforms. If your invoices touch any of these countries, you will need to convert between the national format and the formats your own systems produce. This page explains each format, its mandate status, and how this converter handles it.

Quick Comparison

Italy — FatturaPA and the SDI Platform

Italy was the first EU country to mandate electronic invoicing for all domestic B2B transactions. Every invoice between Italian VAT-registered entities must be submitted through the SDI (Sistema di Interscambio), a central government clearance hub run by the Agenzia delle Entrate.

FatturaPA is the XML format SDI accepts. It has its own schema and namespace — it does not use UBL or CII syntax — but its data fields largely overlap with EN 16931 terms. The key structural differences that affect conversion are:

• Italian VAT nature codes (N1–N7) for non-standard VAT, instead of EN 16931 category codes
• CodiceFiscale and IdFiscaleIVA for party identification, instead of UBL schemeID attributes
• Mandatory CodiceDestinatario (7-char SDI routing code) or PEC address for B2B delivery
• Date format YYYY-MM-DD — same as UBL, no conversion needed
• Amounts use dot as decimal separator and two decimal places — same as UBL

This converter supports: FatturaPA → CII, FatturaPA → UBL 2.1, FatturaPA → Human Readable PDF. Also: UBL → FatturaPA, CII → FatturaPA.

Germany — XRechnung

XRechnung is Germany's national CIUS of EN 16931. It is mandatory for invoices to federal authorities and is being rolled out to state and municipal authorities. The format makes several EN 16931 optional fields mandatory and restricts some code lists to German-specific subsets.

Key differences from standard UBL that affect conversion:

• Leitweg-ID (BT-10 buyer reference): mandatory in XRechnung, optional in standard UBL. Every German public buyer has a Leitweg-ID that must appear in the invoice. Without it, the ZRE portal rejects the document.
• BT-34 / BT-49 (endpoint IDs): XRechnung requires both seller and buyer Peppol endpoint identifiers when the document is delivered via Peppol. The scheme 0201 is used for German Leitweg-IDs in Peppol context.
• Payment means code: XRechnung only accepts codes 30 (credit transfer) and 58 (SEPA credit transfer) for the standard billing process. Code 1 (instrument not defined) is not accepted.
• No CreditNote via UBL in XRechnung 3.x: CreditNote documents use a separate XRechnung profile and document type ID.

This converter supports: UBL 2.1 output fully compatible with XRechnung requirements when the source data includes Leitweg-ID and German-specific fields. The converter does not inject a Leitweg-ID that is not present in the source — that value must come from your data.

France — Factur-X

Factur-X is a hybrid invoice format: a PDF/A-3 file with an embedded CII XML file attached inside it. The PDF layer is for human reading; the XML layer carries the structured data for automated processing. Both layers must be consistent — amounts, dates, and party details must match between the PDF and the XML.

Factur-X defines six conformance profiles from minimal to full EN 16931 compliance:

France's B2B e-reporting mandate (phasing in from 2026) requires at minimum the EN 16931 profile. BASIC WL and MINIMUM profiles do not satisfy the B2B mandate.

This converter supports: Factur-X → FatturaPA, Factur-X → UBL 2.1. Also: UBL → Factur-X. When converting from Factur-X, the embedded CII XML is extracted and used as the source; the PDF wrapper is not carried into the target.

Poland — KSeF and SKEF

Poland's KSeF (Krajowy System e-Faktur) is a national clearance platform similar to Italy's SDI. From 2026, all Polish VAT-registered businesses must issue B2B invoices through KSeF. The invoice format KSeF accepts is defined by the FA(2) schema — commonly referred to as SKEF in conversion contexts.

SKEF is structurally different from UBL and CII. Key mapping considerations:

• Polish NIP (tax identification number) is the primary party identifier — equivalent to VAT number but stored in a different XML path than UBL BT-31.
• KSeF assigns a unique KSeF number to each accepted invoice. This number is not present in the source UBL — it is returned by the platform after submission.
• SKEF uses Polish-specific VAT rate codes (23, 8, 5, 0, ZW, NP, OO) that must be mapped to EN 16931 category codes when converting to UBL or CII.
• Date and amount formatting follows ISO standards, so that part of the conversion is straightforward.

This converter supports: UBL → SKEF. This path converts a UBL 2.1 invoice into the SKEF XML structure ready for KSeF submission. The converter maps EN 16931 business terms to their KSeF FA(2) equivalents and flags any fields that KSeF requires but the UBL source did not include.

Choosing the Right Path for Cross-Border Invoices

When an invoice crosses between two of these countries — for example, a French supplier invoicing an Italian buyer — neither party's native format is directly accepted by the other's platform. The practical workflow is to convert the source format to UBL first, validate against EN 16931, and then convert from UBL to the target country format. See the Conversion Matrix for the exact paths this tool supports.

Continue Reading

• European eInvoicing Overview
• EN 16931 — semantic model and compliance
• Peppol BIS 3.0 — identifiers and validation
• Conversion matrix — every supported path
• implementation-guide — onboarding steps for ERP/accounting teams