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).

General rule -- enter only the numeric value; the platform adds the schemeID prefix automatically. This applies to every identification scheme, not just OINO. If the user also enters the prefix manually (e.g. 0088:1234567890123 while the scheme is already set to GLN/0088), format validation fails. GLN example (schemeID 0088, GS1): select schema GLN and enter only the GLN digits in the value field -- not 0088: in front.

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.

When sending errors occur from 4PS, the cause is often not immediately clear. Do not assume upfront that a missing PSB connection (Peppol Service Bus) is the cause.

Steps:

1. TechSupport establishes the cause. Do not route directly to sales based on an assumption.
2. Cause is a missing active PSB connection at eConnect? Then the next step is sales for PSB onboarding. Do not give the customer 4PS configuration advice — without a PSB connection there is nothing to configure.
3. Cause is something else? Handle it via the relevant error message or solution on this page (or in the 4PS integration pages).

In short: diagnosis by TechSupport always comes before the sales route. The sales route (PSB onboarding) only applies when TechSupport has established that a missing PSB connection is the cause.

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 with a MIME type that is not permitted in the current Peppol BIS Billing V3 validation. The following attachment types are supported (BT-125):

application/xml is not permitted as an attachment MIME type in the current BIS Billing V3 validation. XML as an attachment belongs to EN 16931-1:2026 and a future Peppol version (possibly BIS Billing 4.0) — do not add an XML attachment to resolve BR-CL-24.

Common cause (Business Central, Unit4 ERPx and other ERPs): the ERP automatically embeds attachments linked to the posted invoice, or exports incomplete UBL blocks. An unsupported attachment type (e.g. a Word document) causes BR-CL-24; missing BT-122 leads to BR-52; a credit transfer without IBAN leads to BR-61; empty tags lead to PEPPOL-EN16931-R008. Multiple codes at once point to the payload/ERP export, not an eConnect environment outage. You can validate in advance via the Document Validator.

Solution:

1. Check which attachments are linked to the invoice in the ERP (Business Central: Posted Sales Invoice > Attachments).
2. Remove or replace attachments with a non-permitted type -- e.g. convert a Word document to PDF.
3. Resend the invoice.

BR-52 occurs when an additional document block (BG-24) is present without a Supporting document reference (BT-122). This is common in ERP UBL export, for example Unit4 ERPx in test or pilot.

Solution: provide an ID (BT-122) for each attachment or document reference, or omit the incomplete attachment block. The fix is in the ERP UBL export, not in eConnect.

BR-61 occurs when Payment means type code (BT-81) is a credit transfer (e.g. SEPA or local/non-SEPA credit transfer, codes such as 30 or 58) without a Payment account identifier (BT-84, usually IBAN). This is EN 16931 BR-61.

Solution: enter an IBAN or account number in the payment details, or do not send a credit-transfer code until an account number is included.

PEPPOL-EN16931-R008 occurs when the UBL contains empty XML elements (empty tags).

Solution: omit fields without a value entirely from the UBL export; do not send empty tags. The fix is in the ERP/UBL export, not in eConnect.

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)? Choose VAT category 'O' — outside scope of VAT at invoice line level. With this setting 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.

Search variants: "BR-E-02", "VAT-exempt work", "VAT-exempt invoice without VAT number", "category E vs O platform", "manual platform invoice BR-E-02".

Foundations, certain government bodies and healthcare providers that exclusively provide VAT-exempt services have no VAT number. When creating an invoice via the platform, this triggers the error message BR-E-02: "An invoice that contains an Invoice line where the VAT category code of the invoiced item is 'Exempt from VAT' must contain the SellerVATIdentifier, SellerTaxRegistrationIdentifier and/or the SellerTaxRepresentativeVATIdentifier." In short: category E (Exempt from VAT) requires a VAT number — and this organisation does not have one.

Solution (platform UI, step by step):

1. Open the sales invoice at platform.econnect.eu.
2. For each invoice line, choose VAT category 'Outside scope of VAT (O)' instead of 'Exempt from VAT (E)'.
3. Leave the supplier VAT number empty — do not use a dummy VAT number.
4. Send the invoice again.

Category 'O' (UNCL5305 code O, "Services outside scope of tax") removes the UI requirement for the VAT number field and 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 (BR-E-02). 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.

Search variants: "BR-AE-10", "SOAP:CLIENTBR-AE-10", "Reverse charge shall have a VAT exemption reason", "BT-120", "BT-121", "missing VAT reverse charge exemption reason", "invoices rejected reverse charge".

BR-AE-10 occurs when a VAT category AE (Reverse Charge) in the VAT breakdown (BG-23) has no exemption reason: no BT-121 (code) and no BT-120 (text, for example "VAT reverse charge" or "Reverse charge"). This is an error in the supplied UBL from the ERP or invoicing package -- eConnect validates the invoice but does not automatically adjust AE fields.

Solution:

1. Check that every invoice line or surcharge with VAT category AE has a VAT rate of 0%.
2. In the UBL export of the source system, fill in the TaxExemptionReason field (BT-120) and/or the code (BT-121) for every AE breakdown.
3. Validate the invoice in advance via the Document Validator.
4. Resend the corrected invoice -- resending the original, faulty XML does not resolve this.

See also VAT reverse charge: codes K, AE and G for the full explanation of the VAT reverse charge codes.

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.

Search variants BR-CO-12 / BR-E-01: "BR-CO-12", "BR-E-01", "ChargeTotalAmount", "BT-108", "surcharge total does not balance", "shipping costs not on invoice line", "Shipping costs AllowanceCharge", "Exempt from VAT breakdown missing".

BR-CO-12 occurs when the surcharge total at invoice level does not match the sum of the separate document-level charges — for example when shipping costs are included as a separate invoice-level AllowanceCharge (ChargeIndicator=true, reason "Shipping costs" / code FC). This is valid UBL; see Surcharges and discounts for the structure. BR-E-01 occurs when an invoice line, document allowance or document charge with VAT category 'Exempt from VAT' (E) has no matching Exempt breakdown in the VAT summary.

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.

Search variants: "Invalid payload BR-S-08", "Delivery Failed BR-S-08", "VAT summary does not balance", "invoice line no quantity", "missing invoice line quantity", "BT-116", "VAT category taxable amount".

Besides rounding, BR-S-08 also fails when an invoice line has no (or an empty) quantity (Invoiced quantity / BT-129). In that case the line amount excl. VAT is incorrect (quantity x unit price plus line surcharges minus line discounts), so the sum of the lines deviates from the VAT category taxable amount (BT-116) in the VAT breakdown for Standard rated. The literal error message often looks like: Invalid payload. [BR-S-08]-For each different value of VAT category rate (BT-119) where the VAT category code (BT-118) is Standard rated, the VAT category taxable amount (BT-116)....

Distinction from xs:decimal errors: in the "'...is not a valid xs:decimal'" section above, the amount field itself is not a valid decimal number (empty or scientific notation). With BR-S-08 the amount field is a valid number, but the calculation between line amounts and the VAT breakdown does not balance.

First-line checklist (before escalating to the software supplier):

1. Check all invoice lines for a filled-in quantity and line amount excl. VAT.
2. Line amount = quantity x unit price (plus line surcharges, minus line discounts); no empty amount fields.
3. Have the VAT totals recalculated in the source system.
4. Send a corrected invoice via Peppol. Resending the same document without a correction does not resolve BR-S-08 -- Resend in the Outbox does not adjust line or VAT amounts (same resend scope as with R120 above).
5. Does the error keep recurring with complete quantities? Then it is a rounding issue or another calculation error in the ERP or UBL export -- escalate to the software supplier.

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.

These three error codes appear when the invoice has been technically sent, but the recipient or validator rejects the content on base fields in the UBL/XML. The cause lies in the XML file itself, not in the Peppol connection, the Peppol ID, or the delivery method to the customer.

Solution: adjust the relevant fields in the software where the invoice is drawn up -- CustomizationID and ProfileID are fixed values per document type, not a setting in the eConnect platform. If both BuyerReference and OrderReference are missing, add one of the two before resending the invoice.

Note on R007 and other BIS profiles: the default value in the table applies to a regular invoice/credit note. Self-billing and other Peppol BIS profiles (e.g. self-billing invoicing) have their own, different ProfileID. Do not force the default value on invoices that deliberately use a different BIS profile -- first check which profile applies before applying this FAQ.

Not to be confused with: a missing Peppol registration at the recipient, an incorrect EndpointID, an Access Point outage, or the "no validation rules available" message (see that section further below) -- those cases have different symptoms than this combination of specification, profile, and reference.

This error occurs when cbc:InvoiceTypeCode (BT-3) has the value 326 (partial invoice) or 384 (corrected invoice), while supplier and recipient are not both German organisations. Peppol BIS Billing 3.0 rule PEPPOL-EN16931-P0112 only allows 326 and 384 when both parties are German.

Portal UI: the invoice type selector is on the right of the draft invoice. Customer-facing labels include partial invoice (alongside the standard terms "Corrected invoice" and "Commercial invoice") -- easy to overlook.

Solution (portal, invoice NL or non-DE):

1. Go to Sales invoice → create invoice.
2. On the right of the draft: check the invoice type -- watch for the partial invoice label.
3. Choose Commercial invoice (type code 380) instead of Corrected invoice, unless it is a genuine correction and both sender and recipient are German.
4. For a correction to a non-German recipient: use a credit note or a negative 380 plus a new invoice -- see Credit note variants. Do not use type code 326/384 outside DE→DE.

Source: Peppol BIS Billing 3.0 -- PEPPOL-EN16931-P0112.

This error occurs on invoice line(s) with VAT category Intra-community supply (K, BT-151) when a mandatory VAT identifier is missing. For category K, either seller VAT (BT-31) or seller tax representative VAT (BT-63), and buyer VAT (BT-48) are required. The missing data sits in the party details (organisation or debtor), not on the invoice line itself. The error does not point to one specific line number -- the rule triggers as soon as any invoice line uses category K.

Solution:

1. Determine which invoice line(s) use VAT category K (intra-community supply).
2. Enter the supplier's VAT number (seller VAT) in the organisation settings, or enter the tax representative's VAT number (seller tax representative VAT).
3. Enter the customer's VAT number (buyer VAT) in the debtor details.
4. Resend the invoice. The document in the outbox is read-only -- if there is an error, a new sales invoice must be created.

Belgian Peppol IDs can take two forms:

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 (e.g. for BE0123456789 the company number is 0123456789; for BE1xxxxxxxxx it is 1xxxxxxxxx -- both prefixes are valid).

AFAS: company number with dots fails in Peppol BIS V3. When AFAS initially sends an SI2.0 invoice, no validation occurs on the Belgian company number -- formats with dots (e.g. 0809.948.614) are accepted. When switching to Peppol BIS V3, the format error surfaces because BIS V3 does validate the company number. Solution: the customer updates the master data in AFAS and removes the dots from the company number. The correct format is exactly 10 digits starting with 0 or 1, without any separators.

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.

• UWV Large Cash Flow (re-integration, training, provisions): OIN 00000004191771249000
• UWV Small Cash Flow (operations): OIN 00000004172892677000

Solution per UWV code: fill in the missing field on the invoice. UWV001 series concerns mandatory supplier fields; UWV002 series concerns identification elements.

No. eConnect is the Peppol Access Point: it handles the transport of your invoice over the Peppol network (see What is Peppol?). eConnect is not accounting or invoicing software.

Rule of thumb for the scope boundary: an error that occurs before the invoice reaches eConnect -- for example field validation on City/Postal code or other customer record data in the software used to create the invoice -- falls outside eConnect's remit.

• First check yourself whether the relevant fields (City, Postal code, etc.) are correctly filled in on the recipient's customer record in your own invoicing/accounting software.
• If the error persists, contact the vendor of that invoicing/accounting software.
• See also "Invoice rejected: missing or unknown order number" below ("ERP-specific field" note): eConnect can point to an error code, but does not operate the customer's own ERP/accounting package.

This message appears in the Outbox when the invoice could not be delivered to the recipient via the Peppol network. Possible causes:

• Recipient not registered on Peppol: the recipient does not have an active Peppol registration. The platform automatically offers the email fallback in this case.
• EndpointID incorrect: the recipient's Peppol address is wrong. Check the Chamber of Commerce number or OIN number you entered for the debtor.
• Receiving party has a technical issue: the invoice was sent correctly but could not be processed by the recipient's system. This is outside your control; contact the recipient.

If delivery fails, you can resend the invoice and correct the EndpointID.

not available when (test) sending to a recipient means: the recipient is not active on Peppol to receive documents on the identifier used. It is not a problem on the sender side.

• Peppol routing runs via the recipient's EndpointID (Chamber of Commerce number / OIN), not via the sender's VAT number. A valid VAT number does not by itself make an organisation findable or reachable -- Peppol registration is required (see What is my Peppol ID? and Register on Peppol).
• When not available occurs, the platform automatically offers the email fallback, so the document can still be delivered to the recipient via email.
• Note for the sender side: sending via Peppol works automatically once your own organisation is activated. Activation for production is a KYC requirement; testing is possible via the pilot (see Register on Peppol).

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 supplier field only accepts an organisation that you select from the dropdown list. If you type text into this field yourself — for example your own company name — instead of selecting the organisation, the Supplier section of the invoice is not built up correctly. The field appears filled in, but the invoice is rejected when sending. This error often appears under a different message, such as "VAT number missing" or "Supplier identifier is required".

Solution: remove the typed text from the supplier field, click the field and select your own organisation from the dropdown list. Then resend the invoice.

This is the same remediation as for "The Supplier field is empty" and BR-NL-1: select your own organisation via the dropdown. The difference is that here the field initially appears filled in, because it does contain text -- just not a valid selection.

Validation rule BR-CO-09 checks whether the VAT number has a valid format. The VAT number must always be entered including the country code and without dots, spaces or separators.

Country codes follow the ISO 3166-1 alpha-2 standard. VAT numbers are required when the supplier or recipient is VAT-liable and the rate is not exempt.

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.

Search variants: "red stop sign sending", "red circle sending", "invoice cannot be sent", "sending fails", "stop icon invoice", "invoice note required", "IBAN bank account required", "more info invoice note", "payment details IBAN empty", "required fields invoice sending".

When sending a manual sales invoice, a red stop icon can appear: the invoice does not go out. The cause is client-side form validation -- not a Peppol or network error and not a platform defect. The debtor/OIN, Peppol reachability and order number can already be correct while sending still fails because another required field is left empty.

Check these two fields:

1. Invoice note (section More info) -- fill in a short note or reference, for example the order number or the reference agreed with the customer.
2. IBAN bank account (section Payment details) -- fill in the IBAN on which the payment is received, via Change if needed. The IBAN at organisation level is optional, but an empty IBAN on the invoice itself can still block sending.

Distinction from other blockers:

• Send button does not respond or shows placeholders: see "Peppol send button does not respond" below (browser auto-translation).
• Invoice stays in drafts: see the section on that (organisation setting or missing "Send via").

Does sending still fail after filling in both fields? Ask for a screenshot of the exact error message, not just of the stop icon.

Search variants: "bank account number not correctly formatted", "bank account not correctly formatted", "IBAN not correctly formatted", "IBAN format error", "IBAN spaces", "payment details IBAN formatting", "manual invoice sending IBAN error".

When sending a manual sales invoice, you may see a message that the bank account number or IBAN is not correctly formatted, even if the number is correct in substance. The cause is a pre-send format validation on the IBAN or bank account in the Payment details section -- not a Peppol or network error. Spaces, hyphens or other separators (or a missing country code) cause the check to fail.

Solution:

1. Open the invoice and go to Payment details (IBAN or bank account).
2. Enter the full IBAN as one continuous string: country code plus digits/letters, without spaces, hyphens or other separators (format: NL00BANK0123456789).
3. Do not use an old account number without a country code -- Dutch accounts start with NL.
4. Save and resend the invoice.

Distinction from other blockers:

• Empty IBAN field with a red stop icon on required fields -- see "Red stop icon when sending" above.
• "ID not correctly formatted" concerns identifier/schemeID formatting, not the bank account -- see "Unknown error / identifier validation errors" above.

Does the message keep appearing? Ask for the exact field content (including spaces or characters) and the literal error message or a screenshot.

Search variants: "send button does not respond", "loading screen hangs when sending", "strange text on invoice", "odd supplier name", "illogical unit on invoice", "organisation shows strange text", "logging in multiple times to save", "log in again to send", "invoice fields translated", "browser translation when creating invoice", "cannot log in", "login page strange text".

If the send button does not respond or the loading screen hangs when sending a Peppol invoice, and you see untranslated template syntax such as {{invoice.data.supplierDetails.name}} instead of the filled-in values, the likely cause is browser auto-translation.

The same pattern can occur when creating a (new) invoice: illogical or "translated" labels/field values for, among others, supplier, organisation and unit, where saving or sending only succeeds after repeatedly logging in again. This has the same cause as the send-button placeholders -- not a product defect and no reason to reinstall client software (the platform is browser-only).

The same happens on the login page of platform.econnect.eu and elsewhere in the UI: placeholder text or raw i18n keys (for example {{lang.text}} or I18N_COLLABRR_WS.*) instead of normal labels. Users often report this as "I can't log in". See also Login and 2FA.

Browser auto-translation (automatic page translation in Chrome or Edge) interferes with the platform's DOM. This causes buttons to stop responding correctly and leaves template or i18n placeholders or illogical field labels visible.

Solution (first-line order):

1. Disable automatic translation in your browser for the eConnect platform (including platform.econnect.eu).
2. Hard refresh (Ctrl+F5) and log in again; reopen or recreate the invoice if needed.
3. Still not working? Clear the browser cache and/or try a different browser.
4. Problem persists? Ask for a screenshot of the invoice page including browser and version.

Search variants: "error when sending", "intermittent portal error", "works after restarting", "sending error without details", "error message without content".

Sometimes a user reports an error when sending via the platform, without the literal error text or a screenshot. Without that content there is not enough information for a firm diagnosis; this is not a known wide outage.

Possible first step (no confirmed cause):

1. Clear the browser cache and/or try a different browser.
2. If that does not help, ask for more context: the literal error message or a screenshot, the time, and the invoice number.

Not to be confused with:

• Send button does not respond, loading screen hangs, or illogical labels/placeholders -- see "Peppol send button does not respond" above (browser auto-translation, with its own first-line order).
• Status SentRetry or SentError after acceptance -- see the section on automatic Peppol redelivery elsewhere on this page; that is a server-side retry mechanism, not a browser-cache issue.

This message appears when you upload an XML invoice in the platform. The platform reads the data from the XML, but the supplier identifier is missing from the file. As a result, the platform cannot send the invoice.

Solution: click the pencil icon next to the supplier field and reselect your organisation. The platform then rebuilds the supplier section and adds the required identifiers to the XML.

This is the same remediation as for "The Supplier field is empty" and BR-NL-1: reselect your own organisation via the pencil icon. The difference is that here the specific message "Supplier identifier is required" appears due to a missing supplier identifier in the uploaded XML.

When sending an invoice you may see the error message "EndpointID missing". This is a known platform bug -- it is not a Peppol registration problem on the customer side. An automated diagnosis sometimes incorrectly classifies this as a registration problem; that classification is wrong.

Workaround: open the invoice block → click the pencil icon in the top right → reselect the supplier and/or debtor → resend the invoice. The platform then rebuilds the identifiers in the XML and can send the invoice correctly.

This is the same pencil-icon remediation as for "The Supplier field is empty" / BR-NL-1 and "Supplier identifier is required". The difference is the specific error message "EndpointID missing".

Search variants: "No sending-activated identifiers found for the supplier company", sending-activated identifiers, "supplier verification not done yet", sending invoice new administration, two organisations with and without B.V., identifiers not verified.

This message, and the customer phrase "supplier verification not done yet" on a first invoice or new administration, usually does not point to a separate supplier KYC step. The cause is almost always one of these four points.

Checklist (in order):

1. Correct supplier organisation selected? With two similar organisations (for example the same name with and without "B.V."), the wrong one may have been chosen. Use the pencil icon to select the organisation with verified identifiers -- an organisation without verified identifiers cannot send.
2. Organisation activated? Not yet activated: activate first via Add and activate an organisation.
3. "Sending" toggle on? Go to Organisations → your organisation → Details and check whether at least one identifier (preferably Chamber of Commerce) has the Sending toggle on. For an activated organisation this is usually already on.
4. VAT number correct? Check both supplier and debtor VAT for country code and separators -- see BR-CO-09 above. A VAT format error can occur at the same time as this message.

If the message persists after these four steps, resend the invoice after correcting the organisation or invoice data.

If an invoice cannot be sent and remains in the "Drafts" folder, check two things:

1. Sending enabled: check in the organisation settings whether "Sending of documents" is activated. If it is not, contact support.
2. Send via set: next to the debtor's OrganisationID, a "Send via" option must also be selected. Without this setting the invoice cannot be sent.

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:

1. IDR processing error: the IDR cannot process the document and returns status 40.
2. Platform-side rejection: the IDR did process the document, but the platform then sets it to status 40 (e.g. due to a validation error after conversion).

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.

Outdated or changed EndpointID (for example after a VAT number change at the recipient): if an invoice was sent to an incorrect or since-changed Peppol ID, Resend with a correction of the EndpointID is the preferred route, not crediting plus reinvoicing. Go to the Outbox, find the invoice that went to the wrong Peppol ID, click Resend, correct the EndpointID to the right ID before sending, and send. The invoice goes out again under the same invoice number to the correct Peppol ID. Verify the correct ID via the Peppol Directory.

A credit note with full reinvoicing is not needed for this scenario. That heavier route only applies when the original invoice was already (partially) delivered or needs to be corrected for accounting reasons.

A customer can only perform a resend themselves with an activated platform account with access to the Outbox. An IT partner without their own account must register first.

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.

4. PO number (BT-13, OrderReference/ID) not recognised by the recipient. A PO number in XML should normally be recognised by the recipient's ERP system. In practice, matching sometimes fails for one of the following reasons:

• The recipient's ERP system is not configured to automatically match the PO value.
• The sender is supplying the PO value in a non-standard way (e.g. in a different reference field than the ERP expects).
• The PO value is placed in a different reference field than the one the recipient's ERP monitors.

eConnect can address this at the product level per recipient, so that the matching process runs correctly. This can also be configured for a specific sender.

Action:

• Resend the invoice using the Resend option (see section above) with a valid reference.
• If the order number is unknown, contact the recipient about the desired procedure.
• If matching consistently fails with a specific recipient, contact support -- eConnect can set up a tailored solution per recipient (and optionally per sender).

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.

The Peppol network has an automatic redelivery/retry mechanism for temporary delivery failures between Access Points. When delivery to the receiving Access Point (C3) temporarily fails -- for example due to an outage at the recipient's side -- the sending Access Point (C2) attempts to redeliver the document later.

• Temporary failure (5xx) = retry; permanent failure (4xx) = no retry. At the eConnect sending level, only 5xx errors are retried (maximum 8 attempts, approximately 35 hours). A 4xx validation error is permanent and results in only one attempt -- see also the "InvoiceSentError" section above.
• Status in the platform: during a retry, the customer sees the status SentRetry (AS4 transport level). On definitive failure this becomes SentError.
• Effect of a network or Access Point outage: the invoice may only be delivered several days after sending, namely once the retry succeeds. The sender does not need to take any action -- redelivery happens automatically within the retry window.
• Exact window length: the precise retry window of the Peppol network (outside the eConnect sending retry) is not publicly standardised and may vary by Access Point.

This redelivery mechanism partly explains why the receipt date may be several days after the invoice date (IssueDate). See also Invoice date (IssueDate) vs. receipt date in eConnect for the explanation on the receiving side.

Source: expert confirmation Johan Schaeffer (Peppol & E-invoicing), 2026-07-04, re ticket #15268901 (W776).

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.

Second, different root cause -- empty amount field: the error The string '' is not a valid Decimal value on a PriceAmountType field occurs when an amount field (e.g. cbc:PriceAmount) contains an empty string ("") on one or more invoice lines instead of a decimal number. xs:decimal does not allow an empty string as a lexical value. This is a different, separate cause than scientific notation, but the same error-pattern class ("not a valid xs:decimal"/"not a valid Decimal value"): the source system simply leaves the field empty instead of sending an incorrectly formatted number.

Solution on the customer side (both variants): 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), and so that no amount field is left empty.

On the eConnect side: cannot be corrected automatically -- the value is already incorrect (or empty) in the supplied XML. Refer to the supplier of the software package; the invoice must be resubmitted with a valid amount on all lines.

This scenario applies when the supplier claims to have sent the invoice but the recipient has not received anything, and the invoice has not yet reached the final status 'Delivered' or the status is unclear.

Diagnosis in three steps:

1. Check the sending status in the platform. Go to Outbox (platform) or PSB Control > Events (PSB). The customer can check this themselves (self-diagnosis). If the invoice shows 'Sent' or 'Delivered' in the Outbox or as a successful event in PSB Control, the invoice has been submitted to the Peppol network. If the recipient's Participant ID is registered at a different or competing Access Point, the invoice was delivered to that Access Point -- that is not an eConnect sending problem.
2. Recipient not activated? Then not routable. You cannot send to an organisation that has not been activated: it is not published as a Participant in the SMP/SML and the Participant ID is not routable via eConnect. Common mistake: senders think they also need to add the recipient (their customer) as an organisation in the platform -- this is not necessary. Only the sending organisation itself needs to be activated; the recipient does not need to be in the account.
3. Recipient is with another provider? Migration required. If the recipient (or the supplier themselves) wants to switch to eConnect: first deregister from the old Service Provider, then register with eConnect. Activate the organisation first so that registration can be completed immediately, or request a migration code (this is not yet automatic in the platform). See Peppol registration and migration.

For the scenario where the status already shows Delivered but the recipient says nothing was received, see the section "Status 'delivered' but recipient has not received the invoice" below.

The status Delivered means that the receiving Access Point (the Peppol service provider of the debtor) has technically accepted the document and confirmed that acceptance. eConnect receives a returnedMessageId (format GUID@econnect.eu): proof that the invoice has arrived at the recipient's Access Point. Where the returnedMessageId is visible differs between the platform and PSB — check the correct environment for the customer.

If the debtor says they have not received the invoice while the status shows 'Delivered', the document has been delivered to the debtor's Access Point but is not yet visible in their own software or administration. This is a downstream issue on the recipient's side.

Steps to resolve:

1. Confirm to the customer that the invoice was successfully sent to the debtor's Peppol Access Point and that eConnect has received a delivery confirmation.
2. Advise the customer to ask the debtor to contact their own Peppol service provider. The returnedMessageId can be provided: with that ID the receiving Access Point can trace the document.
3. Further handling lies with the debtor's Access Point; eConnect as the sending party has no visibility beyond the point of delivery.

Search variants: "add organisation" for an invoice, supplier portal, organisation name + Chamber of Commerce number top right, cannot edit existing organisation row, cannot rename existing organisation, screenshot customer organisation top right, identifier message when adding organisation (supplier), add own organisation separately, debtor as own organisation, add invoice recipient environment, activate government debtor organisation, recipient must be in environment, registering under a municipality's own OIN, customer's OIN as own organisation, invoicing a municipality with own OIN, recipient OIN not own identifier, scheme 0190 debtor.

New users -- particularly those switching from other e-invoicing services -- sometimes try to add the receiving organisation as their own organisation on the platform when sending an invoice. This is not necessary and results in an error message.

To send an invoice to a recipient, that organisation does not need to be in your own account: when creating the invoice, you select the recipient via the debtor search field. You search by Chamber of Commerce number, company name or OIN number.

Error message "The identifier has already been verified in another organisation"

This message appears during invoice submission (via Peppol) or when trying to "add receiving organisation". The message covers two scenarios with different causes and solutions:

Scenario 1: the message is about the identifier of the CUSTOMER (recipient/debtor). This is an expression of incorrect platform usage: the user is trying to add a customer/recipient organisation to their own environment. This is not an authorisation issue — support does not need to release the identifier internally. The correct procedure: only add your own organisation(s) and activate them in your own environment. Then send the invoice to the recipient via the debtor search field — the recipient does not need to be in your account.

Scenario 2: the message is about the user's OWN identifier. The identifier is already registered under a different organisation in another account. This is not incorrect platform usage: the user legitimately wants to create their own organisation. Possible causes: a colleague has already created the organisation, or the organisation still exists in an old account.

• Internally: find out who created the organisation previously and add the new user to that account or organisation.
• If the creator is unknown: support can look up the email address of the creator so the user can contact them directly. Support does not detach or transfer the identifier itself — that is not part of the standard support procedure.

Search variants: "enabled for Peppol sending", "additional Peppol activation", "is sending already enabled", "extra send activation", "University of Luxembourg", "9938", "foreign recipient scheme".

For an activated organisation, sending is on by default -- it is part of the standard connection. There is no separate "Peppol send enable" step beyond an active organisation status. See Register on Peppol for the full activation procedure.

Enter the recipient (for example a foreign Peppol party such as a Luxembourg university) only on the invoice, via the debtor search field (Organisation ID + Send via). Do not add the recipient as your own organisation in the account -- see also the section "Confusion: trying to add the recipient as your own organisation" above.

Still getting an error that is not described here? Contact us via support.econnect.eu.