Error messages and solutions per ERP package. This article covers package-specific errors. For generic API, webhook and connectivity issues: see Troubleshooting integrations.

Error messages with prefix U4 come from Unit4 ERPx. The solution is almost always on the software side, not with eConnect. The customer can download the XML file from the platform and forward it to the Unit4 administrator.

The JSON payload sent to Unit4/ERPx cannot be retrieved. The JSON that eConnect posts to Unit4/ERPx is not logged and therefore cannot be retrieved — not via an API endpoint and not via support. Manual reconstruction is not supported. For diagnosis or verification of invoice data, support refers customers to the downloadable XML file from the platform.

DueDate compensation: Unit4 cannot process invoices without a DueDate/PaymentDueDate (the field is not mandatory in the XML). eConnect sets the PaymentDueDate to the IssueDate (invoice date) plus 30 days by default when this field is missing. This is a standard Rule Based Enrichment, configured per customer as PrivateObject in the PSB (typically Id unit4-setDueDate-30days).

Invoice booked but PDF attachment missing: earlier connection breaks on the Unit4 side where the PDF was dropped are now being retried (confirmed by Platform & Integrations, May 2026). Remaining cases: see the diagnosis path below.

UBW is the classic Agresso/UBW name; within eConnect we use it as a search alias alongside Unit4 ERPx, where this forwarding takes place.

Symptom: an incoming invoice (often non-Peppol) was manually emailed to @trust.econnect.eu, is visible in the platform, but is not (yet) in UBW/Agresso or the connected financial package. See also Email Receiver for the intake via this address.

Make this distinction first, before escalating:

1. Temporary batch or forwarding delay: the document is correctly in the platform, but the customer's automatic retrieval or booking process still needs to run or is currently running. This usually resolves itself; there is no outage.
2. Permanently not arrived: after the expected run, the invoice is still absent. Then continue with Diagnosis: invoice not received in ERPx without error message below (integration type, documentId/consignmentId, Events, idempotency between Autopilot and ERPx).

On a fresh report:

1. Confirm the visibility and status of the invoice in the platform.
2. Ask about the integration type or ERP package (UBW/Agresso, Unit4 ERPx via Autopilot, SFTP/PSB, ...) and whether the automatic process has already run today.
3. Has the process not yet run or is it currently running? Then wait briefly and confirm after the run. Do not escalate prematurely.
4. Has the process run and is the invoice still permanently absent? Collect the IDs and follow the diagnosis path below.

There is no fixed SLA in hours between submission via the Email Receiver and processing in UBW/ERPx.

This path applies to complaints like "Booked in eConnect but not visible in ERPx" or "invoice seems to have never arrived, no message in Document Journal".

Background: the Autopilot — Unit4 ERPx route is idempotent (match on invoice number + customer + supplier). On a match, ERPx is not called again and only a missing PDF is uploaded, while the platform still shows Booked. An empty Document Journal for the second submission therefore does not mean the invoice is lost, but usually that the idempotent check was triggered.

Check this first with a Unit4 partner with multiple invoices:

0. Delivered-only, no journal: status Delivered/Received in the Inbox with 0 hits in Document Journals means no Autopilot booking attempt (Booked/Booking failed) has happened yet. Resubmit the invoice to the connected software first; only start an Events investigation after that. See Autopilot -- Document Journals.
1. Separate the parties: the receiving customer (ERPx user) is not the same as the supplier on the invoice, nor the same as any intermediary party on an attached log.
2. Correct log or document: check whether the attachment or the eConnect log is the claimed document (invoice number, supplier to recipient). A wrong log is a different document; do not start an ERPx investigation on it.
3. Identifier per claimed invoice: at minimum the invoice number, preferably also documentId or consignmentId. Multiple missing invoice numbers are separate documents; Booked on invoice A does not cover invoice B.
4. Booked plus duplicate error (e.g. invoice number already exists, or after resubmission): often the same invoice number was sent again. The platform may show Booked on the earlier booking; that is not proof that a different invoice number is in ERPx. Confirm this via Events (step 3 below) or an existing ERPx registration.

Steps:

The ABWInvoice transformation was built based on original test documents. Deviating document variants (e.g. free text invoices) may fail with "API400: Initializing failed". Solution: change request at Development for transformation extension.

Error messages with prefix BC come from Business Central. Little influence from eConnect; the customer must check the BC configuration.

The prefix between brackets indicates the type of response that eConnect received from Business Central when booking the invoice:

• [BC400] — a request rejected by Business Central (BC returned a 400-type error). This is almost always a validation or table relation error in the customer's BC configuration. The text directly after [BC400]: names the specific BC error.
• [BCBadRequest] / [BCNotFound] / [BCTooManyRequests] — similar BC-side responses (rejected request, not found, rate limit).
• [API400] — rejected by the eConnect API itself, for BC (e.g. an incorrect connection setting).

In all BC prefix cases, the solution is on the BC side (customer's configuration); eConnect has little influence here.

Lookup order for identifiers in the invoice: 1. VAT, 2. Chamber of Commerce (KvK), 3. IBAN. Mapping to BC API fields: VAT to VAT_Registration_No, Chamber of Commerce to Registration_Number, IBAN to Vendor Bank Account No. Vendor not found: eConnect does not create a vendor; the invoice fails (typically [API400] Could not retrieve vendor... / vendor ids).

After the vendor is recognized, bank accounts from the invoice are checked against the Vendor Bank Accounts of that vendor, including G-accounts passed via the IDR extension. See G-Account Code in the table below.

The suffix .JSON (e.g. [BCNotFound].JSON) occurs because the integration code expects a JSON response, but Business Central returns an HTML page instead of JSON for some 404 errors. That HTML cannot be parsed to JSON — hence the .JSON part in the error message. The underlying cause is the same as for a regular [BCNotFound].

[BCNotFound] typically has two causes:

1. The specified URL of the BC environment is incorrect.
2. The web services required by the integration have not been published in the environment.

For outgoing (sending invoices) the web services are usually not an issue: the eConnect extension publishes them itself. For incoming the customer can install the extension to publish the web services, or publish them manually.

Specifically for DataBalk customers there is a third cause: they do not link the two Lines web services PSBPurchaseOrderLines and PSBPurchaseInvoiceLines to the default pages 54 and 55, but to custom pages. If these web services are nevertheless linked to the default pages, a 404 response follows when called.

The AFAS connection works per administration and per environment. Receiving forwards the XML 1:1 to the linked AFAS administration. If only one administration fails while others are fine, this is rarely an organization-wide Peppol receiving issue, but usually an admin-specific connection or forwarding problem.

When a report comes in, check in this order:

1. Scope: which exact AFAS administration (name or ID) is failing? Are other administrations working fine?
2. Evidence: at least one invoice number (with invoice date) that the customer says is missing in AFAS.
3. Inbox check (same organization):
   • Not in the inbox? Then the issue is more likely in receiving, the Peppol channel or the e-mail channel, not the AFAS connection. See incoming invoices.
   • In the inbox but not in AFAS? Then it concerns the downstream connection or forwarding to that administration.
4. Connection: every AFAS environment has its own connection keys. Check whether the failing administration is in the correct environment and whether the eConnect keys for that environment are active in AFAS.
5. Platform action (if the document is in the inbox): check the status and use "Resubmit API download"; if the invoice is marked as duplicate, first use "Mark as original" (see generic ERP steps).

The known AFAS error rows above (entityID, duplicate, Small Business VAT, BE-0208 with dots) do not cover this scenario: this is an admin-scope receiving diagnosis without a fixed error code.

Known outage? Check status.exact.com first for current Exact outages -- separate from eConnect's own status page (support.econnect.eu/status/). An outage at Exact itself (e.g. Exact Online, Exact API) sometimes explains errors that are not caused by the eConnect connection.

Connection: SOAP enterprise, only receiving (purchase). Setup: Connect ECI Inventive.

Two causes, do not confuse them:

1. eConnect platform disruption: for example PDF attachments not delivered. Check the invoice status in eConnect Inbox.
2. Own payload validation error on the Inventive side: outside the scope of eConnect support. The Inventive administrator investigates this.

Status "processed" in eConnect Inbox means eConnect delivered the invoice correctly. If the invoice is still missing in Inventive afterwards, first check the Inventive payload/import (batch jobs), not the eConnect receipt again.

The following steps apply to every ERP package:

1. Test the connection: all packages require port 443 to the eConnect endpoint.
2. Revoke software integration: Platform > Connections > Revoke key > also remove in the linked software.
3. Resubmit documents: Inbox/Outbox > three dots > "Resubmit API download". For duplicate marking first "Mark as original".