When you submit an invoice to eConnect, the document goes through a series of processing steps. How exactly this processing works depends on the file type (XML or PDF) and the quality of the submitted file. This article explains what happens behind the scenes.

eConnect has two fundamentally different processing routes:

XML processing (direct route): if you submit a valid UBL invoice (SI-UBL 2.0, Peppol BIS Billing 3.0 or another supported XML format), it is processed directly. The platform reads the structured data from the XML, validates it and routes the document to the receiver. This is the fastest and most reliable route.

PDF processing (conversion via IDR): if you submit a PDF invoice, it is processed by the Intelligent Document Recogniser (IDR). The IDR extracts invoice data via OCR and pattern recognition, and produces a UBL invoice based on the recognised data. This process is inherently less reliable than direct XML processing, as it depends on the quality of the PDF.

Tip: UBL submission is always preferred over PDF. It is faster, cheaper and more reliable. Ask your supplier or software package whether UBL export is available.

When submitting an XML file, eConnect goes through the following steps:

The platform automatically recognises which format the file follows based on the CustomizationID and XML schema. Supported formats include NLCIUS, BIS Billing V3, XRechnung, CII and Factur-X.

The invoice is validated against the rules of the recognised profile. This includes:

• Schema validation: does the XML comply with the UBL 2.1 or CII schema structure?
• Business rules: are calculations correct? Are mandatory fields filled? Do code list values match?
• Country-specific rules: are the correct NL-R-, DK-R- or other country rules followed?

Tip: getting the message that "no validation rules" were found? This usually means the CustomizationID in your XML is missing or not recognised. Without a recognisable profile, the validator cannot apply business rules. Check that your invoice contains a valid CustomizationID, such as that of NLCIUS or BIS Billing V3.

A notable feature of eConnect processing is the automatic repair of XML files. Known errors are corrected via XSL transformations. The platform essentially accepts any UBL; non-essential missing fields are filled with default values. This repair function is continuously developed based on customer feedback and is production-ready.

Examples of automatic repairs:

• Missing optional fields are populated with correct default values
• Known format errors in identifier fields are corrected
• Incomplete contact details are supplemented (if the supplier's ElectronicMail field is empty, eConnect automatically fills in [email protected], ensuring rejected invoices still reach the sender)

If the receiver supports a different format than the source format, the PSB automatically transforms the document. An NLCIUS invoice can, for example, be transformed to XRechnung if the receiver is a German government body. This is possible because all supported formats are based on the same semantic model (EN 16931).

Technical: when downloading an invoice via the API, you can specify the desired output format using the targetDocumentTypeId parameter. The PSB then transforms the document to that format.

ZUGFeRD and Factur-X are hybrid invoice formats: a PDF/A-3 file containing an embedded CII XML invoice. For these documents, the platform first tries to extract the embedded XML from the PDF. If the XML is valid, it is processed directly, just like a regular XML invoice. Only if the embedded XML turns out to be invalid does the system fall back to OCR processing via the IDR.

A ZUGFeRD invoice that passes external validators but is still processed via OCR indicates a problem with the embedded XML in the eConnect validation process. In that case, you can contact support.

Technical: the legacy platform can only store valid UBL invoices. When a ZUGFeRD invoice is processed as a PDF via the IDR, the IDR output must first be transformed to valid UBL (BIS Billing V3 or NLCIUS). If that transformation fails because the source data contains insufficient fields for a valid UBL invoice, the platform cannot store the invoice. In the PSB/Control, this is less of an issue because invoices are stored in their original format and only transformed upon delivery.

If you submit an XML file that is not valid, the system automatically falls back to the included PDF. This works as follows:

1. The platform first tries to process the XML component.
2. If the UBL is not valid, the included PDF is picked up as fallback.
3. The PDF is processed via the IDR route (OCR and pattern recognition).

This mechanism ensures that the invoice is always processed, even if the XML contains errors. However, it is a more expensive and slower route than direct XML processing.

SI-UBL 1.2 (Simplerinvoicing 1.2) was permanently discontinued as of 1 January 2024. Invoices in this format are rejected on the Peppol network. eConnect can sometimes still transform deprecated SI files received via email to valid NLCIUS, provided the essential data is present. If data is missing, validation may fail.

Note: are you receiving error messages when sending invoices? Check whether your software package still generates SI-UBL 1.2. If so, ask your vendor to upgrade to NLCIUS/SI-UBL 2.0 or BIS Billing V3.

Processing differs slightly between the legacy platform and PSB/Control:

• Legacy platform: an invoice is always first transformed to valid UBL (BIS Billing V3 or NLCIUS) before being stored. If that transformation fails, the invoice cannot be stored.
• PSB/Control: an invoice is validated and stored upon receipt. Transformation only takes place later when needed, for example when delivering to an ERP system. This means an invoice can be stored in the PSB, but a transformation error may occur later if the target format cannot be generated.

Want to check whether your XML file is processed correctly? Use the free eConnect Validator to test your invoice beforehand.

• The structure of a UBL invoice
• What is the difference between XML, UBL, BIS Billing V3 and NLCIUS?
• Important submission fields in UBL
• SEEF: the Standard Energy e-Invoice
• Download XML sample files
• From semantics to syntax