XML Invoice Format: A Complete Example and How to Validate It

An XML invoice is an invoice where every field sits inside a named tag instead of being printed on a page. The invoice number is in one tag, the issue date in another, each line item in its own block. Because every value is labelled, software reads the file directly. No OCR, no retyping, no guessing which number is the VAT. In Europe the tag names come from a standard, almost always UBL 2.1 or UN/CEFACT CII.

<cbc:ID>INV-2026-0042</cbc:ID>
<cbc:IssueDate>2026-03-01</cbc:IssueDate>
<cbc:DocumentCurrencyCode>EUR</cbc:DocumentCurrencyCode>
<cac:LegalMonetaryTotal>
  <cbc:PayableAmount currencyID="EUR">3872.00</cbc:PayableAmount>
</cac:LegalMonetaryTotal>

This guide gives you a complete invoice you can copy, the list of fields that are legally mandatory, the differences between the XML dialects you will meet, and the three validation layers your file has to survive before it reaches a customer.

1. A complete XML invoice example

Below is a full UBL 2.1 invoice that follows the Peppol BIS Billing 3.0 profile. This is not a trimmed illustration. It contains every element the Peppol validation rules require, so you can paste it into a file, change the values, and validate it. One seller, one buyer, one line item, 21% Belgian VAT.

<?xml version="1.0" encoding="UTF-8"?>
<Invoice xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2"
         xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
         xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2">

  <!-- Which rulebook this invoice follows -->
  <cbc:CustomizationID>urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0</cbc:CustomizationID>
  <cbc:ProfileID>urn:fdc:peppol.eu:2017:poacc:billing:01:1.0</cbc:ProfileID>

  <!-- Header -->
  <cbc:ID>INV-2026-0042</cbc:ID>
  <cbc:IssueDate>2026-03-01</cbc:IssueDate>
  <cbc:DueDate>2026-03-31</cbc:DueDate>
  <cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>
  <cbc:DocumentCurrencyCode>EUR</cbc:DocumentCurrencyCode>
  <cbc:BuyerReference>PO-8891</cbc:BuyerReference>

  <!-- Seller -->
  <cac:AccountingSupplierParty>
    <cac:Party>
      <cbc:EndpointID schemeID="0208">0123456789</cbc:EndpointID>
      <cac:PartyName>
        <cbc:Name>Webbureau Leuven BV</cbc:Name>
      </cac:PartyName>
      <cac:PostalAddress>
        <cbc:StreetName>Diestsestraat 12</cbc:StreetName>
        <cbc:CityName>Leuven</cbc:CityName>
        <cbc:PostalZone>3000</cbc:PostalZone>
        <cac:Country><cbc:IdentificationCode>BE</cbc:IdentificationCode></cac:Country>
      </cac:PostalAddress>
      <cac:PartyTaxScheme>
        <cbc:CompanyID>BE0123456789</cbc:CompanyID>
        <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme>
      </cac:PartyTaxScheme>
      <cac:PartyLegalEntity>
        <cbc:RegistrationName>Webbureau Leuven BV</cbc:RegistrationName>
        <cbc:CompanyID schemeID="0208">0123456789</cbc:CompanyID>
      </cac:PartyLegalEntity>
    </cac:Party>
  </cac:AccountingSupplierParty>

  <!-- Buyer -->
  <cac:AccountingCustomerParty>
    <cac:Party>
      <cbc:EndpointID schemeID="0208">0987654321</cbc:EndpointID>
      <cac:PartyName>
        <cbc:Name>Bakkerij Peeters NV</cbc:Name>
      </cac:PartyName>
      <cac:PostalAddress>
        <cbc:StreetName>Grote Markt 3</cbc:StreetName>
        <cbc:CityName>Antwerpen</cbc:CityName>
        <cbc:PostalZone>2000</cbc:PostalZone>
        <cac:Country><cbc:IdentificationCode>BE</cbc:IdentificationCode></cac:Country>
      </cac:PostalAddress>
      <cac:PartyLegalEntity>
        <cbc:RegistrationName>Bakkerij Peeters NV</cbc:RegistrationName>
        <cbc:CompanyID schemeID="0208">0987654321</cbc:CompanyID>
      </cac:PartyLegalEntity>
    </cac:Party>
  </cac:AccountingCustomerParty>

  <!-- How the buyer should pay -->
  <cac:PaymentMeans>
    <cbc:PaymentMeansCode>30</cbc:PaymentMeansCode>
    <cac:PayeeFinancialAccount>
      <cbc:ID>BE68539007547034</cbc:ID>
    </cac:PayeeFinancialAccount>
  </cac:PaymentMeans>

  <!-- VAT breakdown: one subtotal per rate -->
  <cac:TaxTotal>
    <cbc:TaxAmount currencyID="EUR">672.00</cbc:TaxAmount>
    <cac:TaxSubtotal>
      <cbc:TaxableAmount currencyID="EUR">3200.00</cbc:TaxableAmount>
      <cbc:TaxAmount currencyID="EUR">672.00</cbc:TaxAmount>
      <cac:TaxCategory>
        <cbc:ID>S</cbc:ID>
        <cbc:Percent>21</cbc:Percent>
        <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme>
      </cac:TaxCategory>
    </cac:TaxSubtotal>
  </cac:TaxTotal>

  <!-- Document totals -->
  <cac:LegalMonetaryTotal>
    <cbc:LineExtensionAmount currencyID="EUR">3200.00</cbc:LineExtensionAmount>
    <cbc:TaxExclusiveAmount currencyID="EUR">3200.00</cbc:TaxExclusiveAmount>
    <cbc:TaxInclusiveAmount currencyID="EUR">3872.00</cbc:TaxInclusiveAmount>
    <cbc:PayableAmount currencyID="EUR">3872.00</cbc:PayableAmount>
  </cac:LegalMonetaryTotal>

  <!-- Line item -->
  <cac:InvoiceLine>
    <cbc:ID>1</cbc:ID>
    <cbc:InvoicedQuantity unitCode="HUR">40</cbc:InvoicedQuantity>
    <cbc:LineExtensionAmount currencyID="EUR">3200.00</cbc:LineExtensionAmount>
    <cac:Item>
      <cbc:Name>Website redesign</cbc:Name>
      <cac:ClassifiedTaxCategory>
        <cbc:ID>S</cbc:ID>
        <cbc:Percent>21</cbc:Percent>
        <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme>
      </cac:ClassifiedTaxCategory>
    </cac:Item>
    <cac:Price>
      <cbc:PriceAmount currencyID="EUR">80.00</cbc:PriceAmount>
    </cac:Price>
  </cac:InvoiceLine>

</Invoice>

Four details in this file trip up most first attempts:

• Element order is fixed. UBL is defined by an XSD schema with a strict sequence. Putting cac:InvoiceLine before cac:LegalMonetaryTotal is not a style choice. It breaks the file.
• CustomizationID is the rulebook. It tells the receiver which validation rules apply. Get it wrong and the invoice is rejected by the network before a human sees it.
• Every amount needs a currency attribute. A bare 3872.00 without currencyID fails schema validation.
• The VAT breakdown must reconcile. TaxSubtotal/TaxableAmount has to equal the sum of the line net amounts at that rate. Cent rounding differences are the single most common rejection we see.

Paste this file into our Invoice Viewer to see it rendered as a readable document, or into the Peppol Validator to run the real rule set against it. For a field-by-field walkthrough of every UBL element, including VAT categories, unit codes and attachments, see our UBL invoice format guide.

2. The fields that are legally mandatory

UBL defines hundreds of optional elements. EN 16931, the European standard behind every compliant e-invoice, narrows that down to a core set that must always be present. Each field has a BT number in the standard. These are the ones you cannot leave out of a Peppol invoice.

Peppol adds two rules on top of EN 16931 that catch people out. A buyer reference or a purchase order reference is mandatory, so an invoice with neither is rejected. And both electronic addresses must be present, even though EN 16931 itself treats them as optional. If you are mapping your own data model to the standard, our EN 16931 field mapper shows the full BT-to-UBL correspondence.

3. XML invoice formats, and how to tell them apart

"XML invoice" is not one format. It is a family of incompatible schemas that all happen to use XML. If a customer sends you a file and you do not know what it is, the root element and the customization identifier tell you within seconds.

UBL and CII carry the same EN 16931 data with different tag names. That means a mechanical conversion between them is possible, and it is what most Access Points do internally. XRechnung is not a third syntax. It is a national profile that narrows EN 16931 and can be expressed in either UBL or CII. FatturaPA sits outside EN 16931 entirely and needs a real transformation, not a rename.

Not sure what you have? Drop the file into our format detector. To pull the XML out of a hybrid PDF, use the ZUGFeRD XML extractor. To move a CII file onto Peppol, use the CII to UBL converter.

4. XML vs. PDF vs. EDI

The line that matters for compliance is structured versus unstructured. A PDF looks like an invoice, but to software it is a picture of text. It has no idea which number is the total and which is the VAT.

Hybrid formats are a useful bridge during a transition. Recipients with modern software extract the XML, everyone else reads the PDF. They are widely used in Germany and France. They are not a substitute for Peppol delivery in Belgium. If you need to show an XML invoice to a human, our Peppol to PDF converter renders it as a readable document.

5. How to validate an XML invoice

A file that opens without error in a browser is not a valid invoice. Peppol invoices pass through three independent validation layers, and each one rejects different things. Most developers discover the second and third layers the hard way.

6. Creating XML invoices without writing XML

Hand-building UBL is possible, and the example above shows it is not mysterious. It is still rarely the right use of your time. Namespace handling, element ordering, VAT edge cases and Schematron updates are ongoing maintenance, not a one-off task. Most teams send flat data to an Access Point and let it produce and validate the XML.

With the e-invoice.be API you post plain JSON. No namespaces, no tag ordering, no Schematron.

POST https://api.e-invoice.be/api/documents/
Authorization: Bearer YOUR_API_KEY
Content-Type: application/json

{
  "document_type": "INVOICE",
  "invoice_id": "INV-2026-0042",
  "invoice_date": "2026-03-01",
  "due_date": "2026-03-31",
  "currency": "EUR",
  "vendor_name": "Webbureau Leuven BV",
  "vendor_tax_id": "BE0123456789",
  "vendor_address": "Diestsestraat 12, 3000 Leuven, BE",
  "customer_name": "Bakkerij Peeters NV",
  "customer_tax_id": "BE0987654321",
  "customer_peppol_id": "0208:0987654321",
  "items": [
    {
      "description": "Website redesign",
      "quantity": 40,
      "unit_price": 80.00,
      "tax_rate": 21.00
    }
  ]
}

That request produces exactly the UBL document shown in section 1. The API runs all three validation layers before delivery and returns the rule code if anything fails, so you fix problems before the invoice leaves your system. You can download the generated XML for your archive at any time. Incoming invoices arrive as the same flat JSON through a webhook, with the original XML attached.

If you are not a developer, you never touch any of this. Create an account, register your enterprise number, and send invoices from the dashboard or by email. The account and your Peppol ID are free. Every invoice you send or receive is billed per invoice, starting at €0.25. See the API integration guide for full code examples, or the Peppol registration guide to get set up.

7. Frequently asked questions