Common error messages when sending invoices via eConnect with causes and solutions.
When sending an invoice via the eConnect platform you may encounter an error message. Most errors are related to missing or incorrect data in the invoice. Below you find the most common messages, their cause and how to resolve them.
This generic error message is triggered by the pre-send validation in the platform UI. The platform checks before sending whether the identifier value (e.g. OINO, Chamber of Commerce number) matches the expected format. If that check fails, this error message appears.
Common example: schemeID 0190 (OINO) requires exactly 20 digits. If the value contains a prefix — for example NL:OINO:00000001001932779000 instead of just 00000001001932779000 — validation fails.
Note: this error can also occur for invoices created via the API, not only for manually created invoices.
Solution: check the identifier values and remove any prefixes or invalid characters. The value must exactly match the expected format for the schemeID (e.g. 20 digits for OINO, 8 digits for Chamber of Commerce number).
If a supplier places an apostrophe before the OIN number in the XML (a known Excel artefact), Peppol routing fails. The legacy platform does recognise the invoice and delivers it internally — the recipient sees no invoice in their accounts payable inbox but receives a notification email with a link.
Solution: ask the supplier to enter the OIN number without an apostrophe in the XML and to check the Excel export settings.
The platform validates every invoice against the applicable Peppol and NLCIUS standards before sending. Error codes starting with BR (Business Rule) indicate which rule was not met.
Your own organisation (the supplier) is not correctly selected in the invoice. This happens when the supplier field has been manually modified or when the organisation has not yet been activated.
Solution: click the pencil icon next to "Supplier" and reselect your organisation. If your organisation has not yet been activated, do so first via Add and activate an organisation.
You have added an attachment in an unsupported format. The platform only accepts PDF, PNG and JPEG as attachment formats. Word documents, Excel files and other Office formats are not accepted.
Solution: export the file to PDF and add the PDF version as an attachment.
The unit you entered for an invoice line is not recognised as a valid UN/ECE code. This occurs when you use an abbreviation or custom name.
Solution: use a standard unit from the dropdown, such as "Pieces" (EA), "Hours" (HUR) or "Days" (DAY).
The identifier type for "OrganisationID" differs from the identifier type for "Send via". For example: OrganisationID is set to OIN, but "Send via" is set to Chamber of Commerce.
Solution: make sure both fields use the same identifier type. When invoicing government bodies, set both to OIN/OINO. When invoicing a company, use Chamber of Commerce (0106) for both.
The supplier's VAT number is missing from the invoice.
Solution: enter your VAT number in the organisation settings.
Does your organisation have no VAT number (for example a foundation, government body or healthcare provider that exclusively provides VAT-exempt services)? Do not use the dummy value NL000000000B01. Instead, choose VAT category 'O' — outside scope of VAT when creating the invoice. With category 'O', the obligation to enter a VAT number is removed and the invoice complies with the Peppol standard. See also Reverse charge VAT and VAT category O for an explanation of the VAT category codes.
Foundations, certain government bodies and healthcare providers that exclusively provide VAT-exempt services have no VAT number. When creating an invoice via the platform, the requirement to fill in a supplier VAT number will appear.
Solution: select VAT category 'O' — outside scope of VAT (UNCL5305 code O, "Services outside scope of tax") in the invoice form. With category 'O', the UI requirement for the VAT number field is removed and the invoice can be sent without a supplier VAT number.
Do not use dummy VAT numbers such as NL000000000B01 — that is not the intended solution for this scenario. Category 'O' is the correct choice for organisations without a VAT obligation.
Distinction 'E' and 'O': VAT category 'E' (Exempt from VAT) is intended for VAT-liable organisations that invoice a specific VAT-exempt transaction. Category 'E' does require a VAT number. Category 'O' is for organisations that have no VAT obligation at all.
When invoicing the Dutch central government (Basisfactuur Rijk, via Digipoort), an IBAN number is required.
Solution: enter your IBAN number in the payment details of the invoice. It is generally recommended to always include an IBAN on your invoice, as this will become more widely required in the future.
This error occurs when the CompanyID (the PartyLegalEntity field in the UBL) contains a VAT number instead of a Chamber of Commerce number or OIN. This is not allowed: the NLCIUS validation requires Dutch parties to always use a Chamber of Commerce number (schemeID 0106) or OIN (schemeID 0190) as CompanyID. NL-R-003 applies to the supplier, NL-R-005 to the customer.
The confusion arises because the EndpointID (the Peppol address used for routing) may contain a VAT number (schemeID 9944). An invoice with a VAT number as EndpointID is delivered correctly via the Peppol network, but is still rejected if the same VAT number is also in the CompanyID.
Technical: EndpointID and CompanyID are two separate fields with their own purpose. The EndpointID determines routing via Peppol and accepts any type from the EAS code list (including 9944 for VAT numbers). The CompanyID identifies the legal entity and must always be a Chamber of Commerce number (0106) or OIN (0190) for Dutch parties.
Solution: check the UBL your system generates and ensure the CompanyID contains a Chamber of Commerce number or OIN, even if the EndpointID is a VAT number. Both fields must refer to the same organisation but may use a different identifier type.
Tip: the ViDA legislation is gradually making the relationship between EndpointID and CompanyID stricter. Make sure your integration is set up correctly now, so you are not caught off guard by future regulatory changes.
These EN 16931 validation rules check whether the VAT breakdown and invoice totals are mutually consistent. The values are calculated by the sending software package — these are not fields you can correct in the eConnect UI.
Common cause: rounding VAT per line instead of per VAT rate, or a mismatch between line amounts and discounts at invoice level.
Solution: contact the supplier of the sending software package for a correction. eConnect cannot adjust these values because the calculation is fixed in the supplied XML.
VAT category E vs. O: does the organisation have no VAT number (foundation, government body, healthcare)? Use category O (outside scope of VAT) — see the section "VAT-exempt organisations: category O" above. Category E always requires a VAT number.
R120 is a calculation rule that checks whether LineExtensionAmount = (Quantity × PriceAmount ÷ BaseQuantity) + surcharges − discounts. R120 does not explicitly prohibit negative amounts; validation fails when the calculation is not balanced. This commonly occurs when a line discount (AllowanceCharge at line level) exceeds the item price.
Solution: use the net credit amount directly as PriceAmount and omit the AllowanceCharge element on the line. See the article on surcharges and discounts for details and an XML example.
Belgian Peppol IDs can take two forms:
0208:9925:BE + 10 digits)VAT number format: BE followed by exactly 10 digits (add leading zeros if necessary). Verify the VAT number via the VIES validation tool of the European Commission (ec.europa.eu/taxation_customs/vies).
Peppol option not appearing for Belgian debtor? Check with which identifier type the debtor is registered on Peppol. Some Belgian organisations are only registered via 0208: (KBO/company number) and not via 9925: (VAT). In that case try the KBO number: the VAT number without BE in front of it.
Other: negative price lines are not permitted for Belgian invoices; use a negative quantity with a positive price.
BR-DE- error codes* are German country-specific validation rules for XRechnung.
Missing Leitweg-ID (EAS 0204): common when invoicing German government bodies. Request the Leitweg-ID from the contracting authority and add it as an identifier with schemeID 0204.
PDF not accepted: since 1 January 2025, Germany has an obligation to receive e-invoices. A plain PDF is often no longer sufficient. Send the invoice as XRechnung or ZUGFeRD.
KSeF rejection: often caused by an invalid FA_VAT XML format. The eConnect PSB normally handles the correct transformation to the Polish KSeF format.
Certificate errors: can occur if the KSeF certificates are not correctly installed or have expired.
Rate limiting: KSeF applies limits on the number of requests. eConnect uses batch processing to prevent this.
UWV applies its own validation rules on top of the standard Peppol/NLCIUS validation.
0000000419177124900000000004172892677000Solution per UWV code: fill in the missing field on the invoice. UWV001 series concerns mandatory supplier fields; UWV002 series concerns identification elements.
This message appears in the Outbox when the invoice could not be delivered to the recipient via the Peppol network. Possible causes:
If delivery fails, you can resend the invoice and correct the EndpointID.
The supplier field contains no data. This happens when your organisation is not selected or has not been activated.
Solution: click the pencil icon next to the supplier field and select your organisation. Has your organisation not been activated yet? Follow the steps in Add and activate an organisation.
The VAT number must be entered without spaces, dots or hyphens, including the country code. The correct format for the Netherlands is NL123456789B01. Belgian VAT numbers must be entered as BE followed by exactly 10 digits, without separators.
If the entered amount disappears when you move to the next step, the field probably contains characters that are not allowed. The amount field only accepts digits with a comma as decimal separator. Enter amounts as 100,00, not as € 100,00 or 100.00.
This message appears when you manually upload an XML invoice and the supplier EndpointID field is missing from the file. In the platform UI, this is the "Partij-ID" field under "Supplier".
Solution: select a value from your own organisation using the dropdown. If the dropdown does not show the correct result, select the supplier again so the link is refreshed.
If an invoice cannot be sent and remains in the "Drafts" folder, check two things:
The eConnect platform sometimes uses a namespace prefix in generated UBL invoices (e.g. <urn:Invoice xmlns:urn="...">). Both forms — with and without prefix — are technically valid XML.
A recipient rejecting invoices based on the namespace prefix is not Peppol-compliant. The namespace prefix is not configurable per recipient.
Message to customer: the invoice is technically correct. The recipient must use a correct XML parser that handles both prefix and default namespaces. Rejection based on namespace prefix is not permitted within Peppol.
EBMS error codes such as EBMS:0003 and EBMS:0004 are AS4 transport errors in communication between Access Points. Customers see SentError or SentRetry in the platform — the EBMS code itself is not visible in the customer interface.
Action: refer the customer to TechSupport. TechSupport can view the error details via the audit trail and Application Insights.
Error code status 40 means the document was not processed successfully. Two possible causes:
Diagnostics: an eConnect employee must investigate in CloudWatch which processing steps the document went through.
Via the Resend option in the Outbox, you can resubmit a previously sent invoice. Before actually sending, you can still modify fields such as the reference (PO number, OrderReference). The invoice is then resent with the same invoice number but with the corrected reference.
This is the recommended approach when a recipient rejects an invoice due to an incorrect PO number or other reference error. It avoids the need to create a credit note and a new invoice.
In the current Peppol BIS Billing 3.0 and NLCIUS, only 1 order reference (OrderReference) per invoice is supported. This is a limitation stemming from the European standard EN 16931. If an invoice covers multiple orders, the supplier must send separate invoices.
AdditionalDocumentReference can contain additional references of other types (project, contract or buyer reference), but not multiple OrderReferences.
Future: the revised EN 16931-1:2026 (formally approved by CEN on 13 March 2026) adds support for multiple purchase orders per invoice. This is expected to be incorporated in a future version of the Peppol standard (possibly BIS Billing 4.0). Until then, the current limitation of 1 OrderReference per invoice applies in BIS Billing 3.0 and NLCIUS.
If an invoice is rejected due to a missing or unknown order number, two levels must be distinguished.
1. A reference is mandatory under EN 16931. A reference -- order number or another reference (BuyerReference, contract or project reference) -- is required. An invoice without any reference does not comply with the basic rules of the standard.
2. eConnect does not reject on the content of the reference by default. The only situation in which the platform rejects on this point is when no reference is present at all.
3. Customer-specific configuration may be stricter. The actual rejection depends on the recipient's configuration. In a specific setup, an invoice may be rejected if the reference is unknown at that recipient. This is configuration-dependent and not standard behaviour of the eConnect platform.
Action:
An invoice with final status InvoiceSentError (after a 4xx validation error) does not attempt further delivery. Only 5xx errors are retried (maximum 8 attempts, approximately 35 hours). For a 4xx error, only one attempt is made; nothing further is sent to the recipient.
There is no DELETE endpoint for sales invoices (salesInvoice). A sent or rejected sales invoice is an audit-relevant event and remains available in the audit trail for 90 days. If the invoice was incorrect, raise a credit note or corrective invoice via the standard accounting flow.
Validation errors such as TaxInclusiveAmount '-1.336061E6' is not a valid xs:decimal occur because the source system serialises a numeric amount in scientific notation (e.g. -1.336061E6 for -1,336,061.00). UBL amount fields are of type xs:decimal, which does not allow E-notation.
Common cause: the source system stores amounts internally as double/float and uses the default string conversion, which automatically switches to exponent notation for very large or very small values.
Solution on the customer side: update the source system so that amounts are always written as plain decimal strings (e.g. via decimal/BigDecimal types or a locale-independent decimal pattern, without thousands separators and without E-notation).
On the eConnect side: cannot be corrected automatically -- the value is already incorrect in the supplied XML. Refer to the supplier of the software package.
Still getting an error that is not described here? Contact us via support.econnect.eu.
Contact support