Skip to main content

Why can’t I send my invoice as an UBL via Peppol?

  • Updated

Sometimes an invoice cannot be sent via Peppol in OkiOki. This almost always has one of two root causes:

  1. The XML file is formally invalid (structure / Peppol rules)
  2. The invoice is content‑wise invalid for Peppol (wrong customer identification, 0208 vs 9925, wrong VAT number, …)

This article explains how you can check what is going wrong and who needs to fix it.

1. First question: how was the invoice created?

Start by checking how the invoice ended up in OkiOki:

  • A. The invoice was uploaded as an external UBL/XML file
    → It may contain both structural and content errors.
  • B. The invoice was created directly in OkiOki
    → The XML structure is correct; any errors are in the content (customer / Peppol data).

Then go to the appropriate section below.

2. Uploaded XML file (external UBL)

2.1 What OkiOki does – and does not – do

  • OkiOki generates and validates UBL files that are created inside OkiOki.
  • Uploaded UBL files are not modified.
  • If a single Peppol rule is violated, the upload is rejected.

Typical message in OkiOki:

“The sending failed – the uploaded document is not compatible with the required Peppol standard.”

In that case the error has to be fixed in the software that generated the XML file.

2.2 Quick self‑check (3 minutes with ecosio)

  1. Download the XML file from OkiOki.
  2. Go to the free ecosio validator:
    https://ecosio.com/en/peppol-e-invoice-xml-document-validator/
  3. Choose: “OpenPeppol UBL Invoice (2024.11) (aka BIS Billing 3.0.18)”.
  4. Upload your XML file.
  5. Check the errors listed in the report.

In most cases the validator tells you exactly which field or tag is wrong.

2.3 Common formal errors

  • Missing or invalid data
    • VAT number, country code, totals, dates (must be YYYY‑MM‑DD), …
  • Wrong Peppol flavour
    • Invoices and credit notes must use Peppol BIS Billing 3.0.x.
  • File issues
    • Extension is not .xml
    • File size > 10 MB (Peppol limit)
    • Encoding is not UTF‑8
  • Broken XML structure
    • Missing or unclosed tags
    • Incorrect special characters or entities

2.4 What to send to your software vendor

Provide your vendor with:

  • the original .xml file,
  • the validator report (or a screenshot of the errors),
  • the name and version of your invoicing or accounting package.

They need to fix the problem in their application; afterwards you create a new invoice and try again.

3. Invoice created in OkiOki: Peppol content errors

For invoices created within OkiOki, the XML structure is guaranteed to be valid.
If sending via Peppol still fails, the root cause is almost always in the content:

  1. Mandatory customer fields are missing or invalid
  2. The “addressing” (receiver) in the UBL does not match the real customer
  3. The Peppol address (endpoint) in the UBL does not match the address used by OkiOki (e.g. 0208 vs 9925)
  4. VAT number and endpoint do not belong together

Below are the most common scenarios.

3.1 Missing or incorrect customer data

Peppol requires a minimum set of correct customer data:

  • name and address,
  • country code,
  • company number and/or VAT number.

If any of these are empty or clearly invalid, the Peppol network can reject the invoice.

What you can do

  • Check the customer record in your source system (or in OkiOki if the invoice is created there).
  • Complete missing data or correct mistakes (e.g. BE prefix, number of digits).
  • Regenerate the invoice and send it again via Peppol.

3.2 0208 vs 9925: wrong endpoint

In Belgium the most commonly used Peppol identifiers are:

  • 0208:xxxxxxx → company number (BCE), without BE
  • 9925:BExxxxxxxxxx → VAT number, with BE

How does OkiOki choose the Peppol address?

  • If a customer is registered on 0208, OkiOki will always send to 0208:company number.
  • OkiOki sends to 9925 only if:
    • the customer is not registered on 0208,
    • but is registered on 9925,
    • and there is no specific alternative address (GLN, …) configured.
  • A specific GLN or other Peppol address, if present, takes precedence.

This logic cannot be overridden manually on individual contacts.

When does this break?

When the endpoint in the UBL does not match the address OkiOki uses. Example:

  • OkiOki sends to 0208:0891483844,
  • but your XML file contains:
xml<cac:AccountingCustomerParty>
  <cac:Party>
    <cbc:EndpointID schemeID="9925">BE0891483844</cbc:EndpointID>
  </cac:Party>
</cac:AccountingCustomerParty>

Routing and content then conflict, and the Peppol network rejects the document.

Solution

  1. Check (or ask your customer / their Peppol provider) which Peppol ID is actually registered:
    • 0208:company number,
    • or 9925:BExxxxxxxxxx,
    • or another identifier (GLN, …).
  2. Adjust your invoicing software so that:
    • for a 0208 customer, both the Peppol address and the field
      cac:AccountingCustomerParty > cac:Party > cbc:EndpointID
      use 0208,
    • 9925 is only used when 0208 does not exist but 9925 does.
  3. Regenerate the invoice and resend it via Peppol.

3.3 Wrong receiver / VAT number (receiver mismatch)

Another common content issue is that the receiver in the UBL does not match the real customer:

  • incorrect VAT number,
  • wrong customer selected,
  • or an old invoice duplicated without fully updating customer data.

Technically, your Peppol provider may show messages like:

“Receiver does not match the receiver or endpoint passed in the UBL.”

What you can do

  1. Download the XML file of the invoice.
  2. In the UBL, check:
    • cac:AccountingCustomerParty > cac:PartyName (customer name),
    • cac:PartyTaxScheme > cbc:CompanyID (VAT number),
    • cbc:EndpointID (customer’s Peppol address).
  3. Compare this with the real customer data and with the official Peppol registration.
  4. Correct the customer record in your software, regenerate the invoice and send it again.

4. Whom to contact, and when?

Contact your own software vendor when:

  • you are working with an uploaded external XML file,
  • the ecosio validator reports errors,
  • or the UBL content (customer, endpoint) does not match what you entered in that package.

Contact OkiOki support when:

  • your UBL is valid according to the validator,
  • the endpoint data (0208/9925/GLN) in the UBL matches the official Peppol registration,
  • but sending via OkiOki still fails.

In that case, please send us:

  • the XML file,
  • a screenshot of the error message in OkiOki,
  • the customer’s VAT number and company number.

This allows us to investigate the remaining issue in the Peppol network (SMP/SML).

With these steps you can determine why your invoice cannot be sent via Peppol and who (you, your software vendor or OkiOki) needs to take action to solve the problem permanently.

Related articles

Comments

0 comments

Please sign in to leave a comment.