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.

Example -- BR-CO-18 / BR-Z-01 / BR-Z-05 (Zero rated): a UBL with VAT category Zero rated (Z) on an invoice line, document allowance or document charge, without a matching, complete VAT breakdown (BG-23), triggers validation rule BR-CO-18 (breakdown missing), BR-Z-01 (no breakdown line with category Z) or BR-Z-05 (VAT rate for category Z is not 0). Here too the dual-path applies: the UBL is rejected on these rule(s), while an included PDF in the same email is still processed and lands in the Inbox. The fault lies in the submitted UBL from the sender or their software package -- eConnect does not adjust VAT breakdowns. Correction requires a new, corrected UBL (complete Z breakdown, rate 0, lines and totals consistent); providing only the PDF is not a structural substitute on the Peppol/native UBL path. First-line detail: support/troubleshooting-sending.md § VAT total calculation.

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.

Example -- mixing of home address and PO box (PostalAddress) on the invoice display: an address on the invoice display that shows a mix of home address and PO box data is not a mix created by eConnect upon receipt. eConnect passes UBL address fields (cac:PostalAddress) through 1:1 and does not rewrite or normalise addresses. If the source UBL mixes home address and PO box components within one PostalAddress block, the display follows that source.

A typical mixing pattern in the source UBL:

• cbc:StreetName = street and house number (home address)
• cbc:AdditionalStreetName = postal code of the home address, in the wrong field
• cbc:BuildingName = PO Box N (the canonical PO box field in UBL is cbc:Postbox)
• cbc:PostalZone = postal code of the PO box

The invoice display then often shows the street line together with PostalZone/CityName, producing a visual "mixed address" without eConnect combining or correcting any fields. Both address components can be correct on their own, but combining them in a shared address block with crossed-over postal codes is a mapping error in the source UBL.

Action: open the source UBL and check the PostalAddress children of the relevant party. The supplier corrects the mapping: either a consistent home address (StreetName with matching PostalZone), or a PO box in the correct PO box field (Postbox) with the matching postal code -- not both mixed with crossed-over postal codes. Once the source UBL is correct, the display resolves itself.

Example -- credit invoice "Payee/receiver = own organisation": with credit versus debit, AccountingSupplierParty and AccountingCustomerParty do not switch. The direction (payable or receivable) is in the document type and the sign of PayableAmount, not in reversed parties. eConnect does not adjust party roles and does not automatically re-apply a prior Payee correction when the source UBL is already correct -- same passthrough principle as above. Worked out with example: Credit note variants.

Search variants: "credit invoice Payee", "credit invoice Payee own organisation", "Supplier Customer switch credit".

Example -- IBAN or bank account (PaymentMeans) on Peppol receipt: the IBAN and other payment details on an invoice received via Peppol come from the supplier's source UBL, usually in cac:PaymentMeans / cac:PayeeFinancialAccount (payment method and account number; possibly a different payee via PayeeParty, for example with factoring). eConnect does not fill in this account number itself and does not modify the content of the submitted value -- the same 1:1 passthrough applies here too. If the IBAN on a PDF display differs from the structured XML data, the difference lies in what the supplier put in the UBL compared to the PDF, not in an adjustment by eConnect.

Action for an incorrect or differing IBAN: contact the supplier for a corrected e-invoice with the correct IBAN in the UBL. Check via an XML download whether the PaymentMeans/IBAN field actually differs. Also check the submission channel: the Peppol icon and the scan icon (Scan & Recognition) on the platform show the difference between XML submission and PDF recognition (see Icons on the platform). For an e-invoice via Peppol there is no IDR/scan recognition on the IBAN -- that path only applies to PDF submission via Scan & Recognition.

Example -- multiple bank accounts concatenated in one PaymentMeans field: sometimes supplier matching on IBAN fails because the passed-through UBL has multiple account numbers concatenated in cac:PayeeFinancialAccount/cbc:ID (for example IBAN1 directly followed by IBAN2, as one string instead of separate account blocks), and possibly also multiple BIC codes concatenated in cac:FinancialInstitutionBranch/cbc:ID. This originates from the source UBL or the supplier's mapping: eConnect passes the XML through 1:1 and does not split or normalise IBAN/BIC on the Peppol/XML path. For the same invoice via PDF (Scan & Recognition), OCR usually recognises the account numbers as separate, correct accounts in the generated UBL -- the difference lies in the source path (incorrectly concatenated UBL versus OCR recognition), not in an arbitrary platform error.

Action: check the submission channel (Peppol icon versus scan icon). For submission via Peppol/XML, the passthrough above applies: show the PaymentMeans field via an XML download and have the supplier correct the source UBL with separate PaymentMeans/PayeeFinancialAccount blocks, or a single correct primary IBAN per block. If a PDF also arrives from the same sender, OCR may temporarily provide usable, separate IBANs -- the structural solution remains correcting the source UBL. Do not confuse this with IDR-IBAN validation via the verification store: that is a separate PDF recognition path.

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.