Belgium E-Invoicing Software | Electronic Invoicing & Tax Reporting Solution

Belgium E-Invoice XML Format Requirements Explained 2026

Belgium e-Invoice XML

Belgium e-Invoice XML is the technical foundation of every compliant B2B invoice transmitted through Belgium’s Peppol network from January 2026. The XML format — based on Universal Business Language (UBL) 2.1 structured according to the Peppol BIS Billing 3.0 profile — defines not just what data an invoice must contain, but precisely how that data must be structured in machine-readable XML so that every Access Point, every ERP system, and every VAT authority can process it consistently.

This guide explains the Belgium e-Invoice XML format requirements, the UBL standard it is built upon, the mandatory XML elements every compliant invoice must include, and the most common XML errors that cause Access Point validation rejection. The Advintek Belgium e-invoicing platform provides certified XML generation and validation for Belgian businesses across all ERP environments.

What Is the Belgian Peppol XML Invoice Format?

    XML as the Machine-Readable Standard

    The Belgian Peppol invoice format uses XML as the basis for all structured invoice documents. XML allows invoice data to be expressed in a hierarchical, tag-based structure that is both human-readable and machine-processable — enabling automated validation, automated ingestion into accounts payable systems, and automated VAT reporting without manual data re-entry at any stage of the invoice lifecycle.

    UBL 2.1 — The Underlying XML Standard

    The Peppol XML format for Belgium is built on UBL 2.1 (ISO/IEC 19845:2015), the international XML standard for business documents. UBL defines the available XML elements, their data types, their permitted values, and the hierarchical document structure within which they must appear. The Peppol BIS Billing 3.0 profile constrains UBL 2.1 further — specifying which elements are mandatory, which are optional, and which are prohibited for the Belgian B2B invoicing context.

    Schema Validation and Namespace Requirements

    Every Belgian Peppol invoice document must declare the correct UBL 2.1 XML namespace and the BIS Billing 3.0 customisation identifier in the document root element. These declarations allow the receiving Access Point to identify the document type and apply the correct validation rules. A document that omits the required namespace declarations or uses an incorrect customisation identifier will fail schema validation immediately, regardless of the accuracy of its data content.

    UBL 2.1 and the Peppol XML Standard

    The Role of UBL in the Peppol Framework

    UBL invoice Belgium is the standardised XML vocabulary that makes cross-border invoice exchange possible without bilateral format negotiations. Because both the Belgian sender and the German or French recipient’s ERP systems understand UBL 2.1, they can exchange structured invoices through the Peppol network without needing to know anything about each other’s internal data formats. The UBL standard covers both the Invoice document type (for standard sales invoices) and the CreditNote document type (for credit notes).

    The Relationship Between UBL, BIS Billing 3.0, and the Belgian Profile

    Understanding the Belgian Peppol XML invoice format requires understanding the layered relationship between UBL, BIS Billing 3.0, and any Belgian national extensions. UBL 2.1 provides the base XML vocabulary. BIS Billing 3.0 applies the European Peppol profile constraints. Belgium’s SPF Finances may specify additional national business rules that apply to Belgian transactions specifically — these business rules are enforced by Access Point validation in addition to the BIS Billing 3.0 schema check.

    Mandatory Invoice XML Fields for Belgium

    Document-Level Mandatory Elements

    Belgium XML invoice document root must include: the customisation identifier identifying the BIS Billing 3.0 profile, the profile identifier, a unique invoice number, the invoice date, the document currency code, and the accounting customer and supplier party elements containing their respective identification and address data. Every element must contain valid data in the correct XML data type and format — a date in the wrong format is treated as an invalid element, not as a data error.

    Supplier and Buyer Party Elements

    In a Belgian Peppol invoice, the supplier party element (AccountingSupplierParty) must contain the supplier’s Party Tax Scheme element carrying the Belgian VAT number, the Party Legal Entity element carrying the Enterprise Number, the PostalAddress element with the full registered address, and the PartyName element with the legal entity name. The buyer party element (AccountingCustomerParty) must contain equivalent identification elements for the buyer. Platforms including Epicor Prophet 21 Belgium and Workday Belgium require specific configuration to output all required party elements correctly.

    Line-Level XML Elements

    Each InvoiceLine element must contain: a unique line identifier (ID), the invoiced quantity with unit of measure code, the line net amount, the Item element containing the product description and applicable tax category, the Price element containing the unit price, and the TaxTotal element at line level carrying the VAT category, rate, and calculated tax amount. Missing any of these line-level elements or using an incorrect unit of measure code causes validation rejection for the affected line.

    Peppol Access Point Validation Requirements

    Schema Validation

    The first layer of Belgian Peppol invoice validation is schema validation — checking that the XML document conforms to the UBL 2.1 schema for Invoice or CreditNote documents and includes all elements required by the BIS Billing 3.0 profile. Schema validation rejects documents with missing mandatory elements, incorrect data types, invalid enumerated values, and structural hierarchy errors.

    Business Rule Validation

    The second validation layer applies business rules defined in the BIS Billing 3.0 specification — arithmetic consistency rules, VAT number format rules, and date logic rules. Failures are returned as coded error messages identifying the specific rule that failed.

    Belgian National Rules

    National rules are additional validation requirements specific to the Belgian Peppol implementation — for example, rules around Enterprise Number format, specific VAT treatment requirements for Belgian transactions, or Belgian-specific mandatory reference fields. These national rules are applied after schema and BIS business rule validation and are enforced by the Belgian Access Point infrastructure.

    Generating Peppol-Compliant XML From ERP Systems

    Native ERP XML Generation

    Modern ERP platforms generate Belgium e-Invoice XML through Peppol connector modules that transform the ERP’s internal invoice data into conformant UBL 2.1 documents. Businesses running Oracle JD Edwards Belgium or Infor CloudSuite Belgium must confirm that their platform’s Peppol connector module generates XML that conforms to the BIS Billing 3.0 schema for Belgian transactions specifically, since some connectors generate generic UBL that does not include all Belgian mandatory elements.

    International Context for XML E-Invoicing

    Belgian businesses operating across multiple markets benefit from understanding how XML-based e-invoicing works in other jurisdictions. The Malaysia e-Invoicing framework uses its own XML standard through the MyInvois platform, offering a useful comparison point for how structured invoicing obligations are implemented outside the EU.

    Middleware and Transformation Layers

    When an ERP system cannot generate compliant Belgium e-Invoice XML natively, a middleware transformation layer extracts invoice data from the ERP’s internal format and transforms it into a conformant UBL 2.1 BIS Billing 3.0 document. This need is especially common among businesses with complex distribution structures — those managing agent, dealer, and distributor e-Invoicing relationships often deal with layered invoicing chains that make field mapping and data transformation more demanding. The transformation layer must handle all required field mappings, data format conversions, and enumerated value substitutions before the XML document is submitted to the Access Point for validation. Producing a valid electronic invoice XML at this stage requires the transformation layer to handle all required field mappings, data format conversions, and enumerated value substitutions before the document is submitted to the Access Point for validation.

    Common UBL Validation Errors and Fixes

    Namespace and Customisation Identifier Errors

    The most common Belgium e-Invoice XML error category involves incorrect or missing namespace declarations and customisation identifiers in the document root element. ERP systems that generate generic UBL 2.1 documents without the BIS Billing 3.0 customisation identifier will fail schema validation immediately. The fix requires updating the XML template or ERP configuration to include the correct BIS 3.0 namespace and profile identifier in every generated document.

    Date Format Errors

    BIS Billing 3.0 requires all dates to be expressed in ISO 8601 format (YYYY-MM-DD). ERP systems that generate dates in regional formats (DD/MM/YYYY or MM-DD-YYYY) produce XML that fails schema validation. This fix is typically applied at the ERP connector configuration level — the connector must apply a date format transformation before embedding date values in the XML output.

    VAT Amount Arithmetic Errors

    Arithmetic inconsistencies between line-level VAT amounts and the invoice-level VAT total are among the most frequent Belgium e-Invoice XML validation failures. These arise when the ERP applies rounding logic differently at line level versus invoice total level, creating small but validation-breaking discrepancies. The fix requires aligning the ERP’s rounding methodology with the BIS 3.0 arithmetic rules throughout the invoice calculation chain.

    Conclusion

    Belgium e-Invoice XML compliance requires more than adding an XML export option to an existing invoicing system — it requires understanding the precise structural requirements of UBL 2.1, the mandatory field constraints of BIS Billing 3.0, and the Belgian-specific national rules that apply on top of the European standard. Businesses that approach Belgium e-Invoice XML implementation with a detailed understanding of these requirements consistently achieve Access Point validation compliance faster and with fewer post-go-live corrections. Advintek’s XML validation and ERP integration team supports Belgian businesses through every stage of their Belgium e-Invoice XML implementation.

    Frequently Asked Questions

    Q1. What XML standard does Belgium use for Peppol e-invoicing?

    Belgium uses UBL 2.1 XML structured according to the Peppol BIS Billing 3.0 profile for all mandatory B2B e-invoices.

    Q2. Can a business generate UBL XML manually without ERP integration?

    Yes, but manual generation is error-prone and unscalable. ERP integration or certified middleware is strongly recommended for volume invoicing.

    Q3. What is the most common Belgium e-invoice XML validation error?

    Missing or incorrect namespace declarations and customisation identifiers in the document root element are the most frequent schema validation failures.

    Q4. How does a business know which XML elements are mandatory for Belgian Peppol invoices?

    The BIS Billing 3.0 specification and Belgian national implementation guidelines published by OpenPeppol and SPF Finances define mandatory XML elements.

    Q5. Are Belgian Peppol credit notes in the same XML format as invoices?

    Credit notes use the UBL CreditNote document type — a slightly different root element — but follow the same BIS Billing 3.0 field and validation requirements.

    Q6. How should a business test its XML generation before going live?

    Submit representative XML documents through the Peppol sandbox environment and review Access Point validation responses for schema and business rule errors.

    Source by:
    Image by Gemini