Overview

Supported e-invoice formats, XML syntaxes, and output types in the Beliq API.

Beliq supports the main EN 16931–based e-invoice formats used in Europe, plus Italy FatturaPA, Spain Facturae, and Slovenia e-SLOG (national XML formats, not EN 16931). This page explains standards, formats, profiles, and outputs in practical terms.

EN 16931 — the foundation

EN 16931 is the European baseline for e-invoicing. It defines:

• A common invoice data model
• Business rules every compliant invoice must satisfy
• Two XML syntaxes — UBL 2.1 and CII D16B

All EN 16931–derived formats on this page share the same semantic baseline. Italy FatturaPA (FPR12 ordinaria, Agenzia delle Entrate XSD) and Spain Facturae (3.2.2, MINECO XSD) are separate national XML formats validated against their authority XSD artifacts — not against EN 16931 Schematron.

XML syntaxes

Both XML syntaxes represent the same business data. The right choice depends on your target standard:

• XRechnung accepts both UBL and CII
• ZUGFeRD/Factur-X require CII (embedded in PDF)
• Peppol BIS 3.0 requires UBL
• Italy FatturaPA uses the authority FatturaElettronica XML schema (FPR12 ordinaria and related types) — not UBL or CII
• Spain Facturae uses the authority Facturae 3.2.2 XML schema — not UBL or CII

Standards and CIUS

Profiles

Profiles control how much detail is included in the generated invoice. Not all profiles apply to all standards:

For Italy FatturaPA, use standard: "fatturapa" with profile: "ordinaria" (or omit profile — it defaults to ordinaria). Beliq performs XSD validation against the published schema graph and does not run EN 16931 Schematron on this route. SDI submission, signing, and interchange operation are out of product scope — you integrate with your own channel provider.

For Spain Facturae, use standard: "facturae" with profile: "ordinaria" (or omit profile). Beliq performs XSD validation against the MINECO 3.2.2 schema and does not run EN 16931 Schematron. VeriFactu real-time reporting, FACe B2G submission, and XAdES signing are out of product scope — you integrate with your own intermediary.

For Slovenia e-SLOG, use standard: "eslog" with profile: "eracun" (or omit profile). Beliq performs XSD validation against the GZS/ePOS e-SLOG 2.0 schema and does not run EN 16931 Schematron. UJP submission, e-route provider services, and XML-DSig signing are out of product scope; you integrate with your own intermediary. See the Slovenia e-SLOG format reference.

For best EU-wide interoperability, use the peppol profile with standard: "peppol-bis". For Germany-only invoicing, use xrechnung. The Factur-X profiles let you trade structured detail for simpler payloads when the receiver supports it; pick extended-ctc-fr when the recipient requires the French B2B reform overlay.

Document types: invoice vs. credit note

Beliq currently supports two document types, selected via the documentType field on the invoice payload (defaults to "invoice" when omitted):

Credit notes against a standard that does not accept them (today: fatturapa and facturae) are rejected at /v1/generate with DOCUMENT_TYPE_STANDARD_MISMATCH. The error details.creditNoteCapableStandards lists the standards that accept CreditNote payloads in the deployed engine.

If you omit profile, Beliq picks the default for the chosen standard (xrechnung for xrechnung, peppol for peppol-bis, ordinaria for fatturapa and facturae, eracun for eslog, en16931 for ZUGFeRD/Factur-X). Combinations that cannot satisfy the standard’s rules — for example standard: "peppol-bis" with profile: "extended" — are rejected with the PROFILE_STANDARD_MISMATCH error.

Factur-X 1.08 profile coverage — all five profiles

Beliq supports all five Factur-X 1.08 profiles (1.09 upgrade in progress) (MINIMUM, BASIC_WL, BASIC, EN16931, EXTENDED) plus the EXTENDED-CTC-FR overlay. The Schematron and per-profile XSDs come from two sources, both pinned by Beliq with per-file SHAs:

• Primary source — FNFE-MPE / FeRD joint pack at fnfe-mpe.org/factur-x/ — covers BASIC_WL, EN 16931, EXTENDED, and the EXTENDED-CTC-FR overlay through public unauthenticated download.
• Secondary source — Mustangproject core-2.22.0 (Apache-2.0) — re-publishes the MINIMUM and BASIC profile artifacts that FNFE-MPE distributes only behind an email-gated information-package download. Mustangproject is listed by FNFE-MPE itself as a recommended downstream consumer; the SHA-pinned per-file paths are recorded in facturx_schematron.secondarySource.

Documents arriving with any of the five CustomizationIDs are validated against the matching profile rules through the same XSD + Schematron pipeline — there is no operator action needed.

Promotion of any Factur-X profile to fully-verified in Beliq’s status taxonomy still requires a public negative unit-test corpus from FNFE-MPE. That gap is tracked as an upstream gap and reviewed quarterly.

Output formats

Hybrid PDF output applies only to ZUGFeRD and Factur-X. fatturapa and peppol-bis return XML only from /v1/generate.

PDF/A-3 hybrid invoices

ZUGFeRD and Factur-X produce PDF/A-3b documents that contain:

• A visual PDF rendering of the invoice (human-readable)
• An embedded XML attachment (factur-x.xml) containing the structured data (machine-readable)

This lets people read the invoice as a PDF while systems process the embedded XML from the same file.

MIME types and file extensions

Validation pipeline

Every invoice processed by Beliq is validated using the path that matches its format:

• EN 16931 routes (UBL / CII / Factur-X / XRechnung / Peppol / ZUGFeRD XML) — XSD, then EN 16931 Schematron, then CIUS/profile Schematron, then optional France CTC overlay as described below.
• Schema-checked national formats (FatturaPA, Facturae, e-SLOG) — XSD only against the authority schema graph bundled in the engine. EN 16931 Schematron and BR-* rule IDs do not apply; no machine-readable business rules are published for these formats, so XSD structural validation is the highest check available.

For EN 16931–based documents, processing follows:

Input → XSD Schema Validation → EN 16931 Schematron → CIUS / Profile Schematron → France CTC overlay (optional) → Result

1. XSD validation — structural correctness: UBL 2.1, CII D16B, Factur-X 1.08 / ZUGFeRD 2.x CII D22B (per-profile XSD subset where applicable), or the Schema-checked national formats: Italy FatturaPA (VFPR12 and related authority XSD), Spain Facturae (MINECO 3.2.2 XSD), Slovenia e-SLOG (GZS/ePOS e-SLOG 2.0 XSD). For FatturaPA, Facturae, and e-SLOG, validation ends after this step (no Schematron layer exists for these formats).
2. EN 16931 Schematron — core business rules (BR-01 through BR-72 and beyond)
3. CIUS / profile Schematron — country- or network-specific rules (e.g. BR-DE-* for XRechnung, PEPPOL-EN16931-R* for Peppol BIS 3.0, FX-* for the four Factur-X 1.08 profiles)
4. France CTC overlay — when the document carries an AFNOR XP Z12-012 Flux 2 BusinessProcess code (S8 / B8 / M8) or you opt in via franceCtc=true, Beliq additionally runs the FNFE-MPE BR-FR-CTC Flux 2 Schematron, plus the EXTENDED-CTC-FR overlay when the document is in the EXTENDED profile

The CIUS / profile layer that runs depends on the document’s CustomizationID: a Peppol BIS 3.0 URN triggers the OpenPeppol Schematron, an XRechnung URN triggers the KoSIT Schematron, and a Factur-X 1.08 URN triggers the matching FX profile Schematron. FatturaPA documents are identified by FatturaElettronica XML roots and the authority schema set — not by CustomizationID. See validation artifacts for the specific versions in use, and the Peppol BIS Billing 3.0 reference for what the peppol profile produces.

Cross-format conversion

Beliq can convert an invoice from one EN 16931-family format to another via POST /v1/convert. Supported pairs:

• CII ↔ UBL (any profile) — round-trip via Mustang cii2ubl and Helger en16931-ubl2cii.
• ZUGFeRD ↔ Factur-X — same syntax, profile-URN swap only.
• XRechnung CII ↔ XRechnung UBL (syntax swap; preserves the XRechnung CIUS).
• Peppol BIS UBL → plain EN 16931 UBL — strips cbc:EndpointID blocks as an acceptable loss (the count is reported back in X-Lost-Elements-Count).
• Hybrid ZUGFeRD / Factur-X PDF in, hybrid PDF out — the source PDF’s visual envelope is re-used; the engine extracts the embedded CII, runs the conversion, and re-wraps via Mustang --action combine.

The route fails closed rather than silently dropping fields when the target cannot represent something the source carried. The two cases today are France CTC Flux 2 BusinessProcess codes on a UBL-syntax target (opt-in: ?dropFranceCtcOverlay=true) and synthesising Peppol endpoints from a non-Peppol source (no opt-in — use /v1/generate instead).

Out of scope. FatturaPA, Facturae, KSeF, and SDI messaggio sources or targets are not supported — those are national formats with no published EN 16931-equivalent converter. Use /v1/generate to produce them from structured JSON, and /v1/validate to check existing documents.

Common unit codes (UN/ECE Rec. 20)

Common VAT category codes

Common payment means codes (UNTDID 4461)