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 support@econnect.eu, 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.

eConnect never recognises a sales order (order document) as an invoice and does not automatically convert it to an invoice. If you submit a sales order where an invoice is expected, the document will be rejected.

The supplier must provide a correct invoice document themselves: a UBL Invoice with the correct InvoiceTypeCode. eConnect does not modify the source document and does not perform this conversion.

Exception — orderflip: via the orderflip feature, order data can serve as the basis for preparing a draft invoice. This is a separate user action, not an automatic conversion of a sales order to a final invoice. The supplier must complete that draft invoice themselves and submit it as a final invoice document (UBL Invoice + InvoiceTypeCode).

Note: do not confuse document type recognition with reference recognition. A sales order number that needs to be recognised on an invoice (as OrderReference or order_reference) is a reference field, not the document type itself. eConnect reads that order number from the invoice and links it as a reference, but this does not change the document type.

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.

If a UBL is rejected (because it is not valid), eConnect will still process the other attachments in the same email, such as a PDF. The sender receives an email with:

• the notification that the UBL invoice will not be processed, including the error message;
• the notification that any other attachments in the email will be attempted for processing.

Note: this error message on the XML invoice cannot be suppressed as long as other attachments in the same email are being processed.

Example -- BR-AE-10 (Reverse Charge): a UBL with VAT category AE (Reverse Charge) without BT-121 (VAT exemption reason code) or BT-120 (VAT exemption reason text) triggers validation rule BR-AE-10. With category AE, at least one of these fields must be present. The UBL is rejected, an included PDF is processed via the IDR fallback, and the error message about the UBL remains visible in the email to the sender.

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.

eConnect processes UBL fields upon receipt as submitted in the source UBL and does not modify their content. There is no customer-configurable field mapping on the receiver side to rewrite submitted values. Missing or incorrect values must be corrected by the sender in the source UBL. eConnect only corrects known technical format errors and populates non-essential optional fields with default values (see automatic XML repair above).

A concrete example with an incoming intra-community credit note (delivery fields):

Both fields are processed by eConnect upon receipt as submitted. BT-80 is only mandatory when a Deliver-to-address group (BG-15) is included in the invoice. eConnect does not provide a receiver-side mapping to rewrite BT-72 or BT-80. Corrections to missing or incorrect values are made by the sender in the source UBL.

Custom correction via consultancy (not self-service): eConnect can, via consultancy, configure the RBE (rule/business engine) for automatic corrections on the flow. This is bespoke work through eConnect consultancy, not something the customer configures themselves. There is no customer-configurable self-service rewriting of UBL fields on the receiver side.

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