What to do when a conversion task is rejected: common reasons, solutions and resubmission.
Sometimes eConnect cannot convert a submitted document into an e-invoice. The conversion task then gets the status "rejected" and you receive an error message by email with the reason. In most cases you can resolve the problem yourself and resubmit the document.
An invoice number without spaces after PDF conversion is not a rejection reason. PDF conversion always removes all spaces from the invoice number. Supplier XML (Peppol or an XML upload) keeps the number including spaces. Duplicate detection compares exactly on supplier, invoice date and invoice number. A space difference alone produces two originals, not a duplicate. If the PDF conversion differs from the XML, submit only the XML. You correct a different file name at the sender.
Below are the reasons why a conversion task can be rejected, with what you can do for each reason.
The total amount cannot be determined, or required invoice elements are missing. A valid invoice must contain at least an invoice number, invoice date, amounts and identification details of the supplier and the buyer.
What can you do? Check that the invoice is complete and resubmit the document. If invoices from a particular supplier are structurally missing data, contact the supplier.
The system has recognised the document as something other than an invoice or purchase order. Automatic classification (Detect API) distinguishes, among other things: invoices, proforma invoices, logos, receipts, packing slips, purchase orders, payslips, reminders, tax documents, terms and conditions and attachments. Documents that are not classified as an invoice or purchase order are eligible for rejection.
Classification itself is fully automatic, but the actual rejection of a conversion task is always a manual action by the quality team. A document can therefore be correctly classified as "not an invoice" and then assessed by the team.
What can you do? This is usually a correct classification. Proforma invoices are rejected by default and that cannot be overridden. The same applies to documents labelled as proforma invoice, test invoice, trial invoice, test invoice or sample invoice: if they are meant as a proforma or test document (so not a real invoice), eConnect processes them in the same way and they are rejected. If you want a proforma to be processed anyway, change the word "proforma" on the PDF to "invoice" yourself before you submit the document. Responsibility for this lies with you as the customer.
If you want to send the document as an attachment to an invoice, send it together with the invoice in the same email. Is your invoice incorrectly classified as a proforma invoice? Report this to support so the classification can be improved.
The scan is too light, too dark, blurred or of the reverse side. The OCR engine cannot recognise the text reliably.
What can you do? Scan the document again at at least 300 dpi, ensure good contrast and place it straight on the glass.
The PDF has encryption, a digital signature or other restrictions that prevent the text from being read.
What can you do? Remove the protection from the PDF file or ask the supplier for an unprotected version.
The PDF file contains more than one invoice. eConnect always processes one invoice per file.
What can you do? Split the PDF file so that each invoice is in a separate file. An invoice of several pages may still be in one PDF.
A technical error occurred. The document is automatically resubmitted within 24 hours on business days.
What can you do? Wait for automatic reprocessing. If the document has still not been processed after 24 hours, contact support.
Tip for persistent processing errors: a PDF that keeps failing on a processing error can often be unblocked by "printing" the source file to PDF again via Microsoft Print to PDF (or a similar PDF printer) and submitting the new PDF. This normalises the PDF structure and resolves many embedded-PDF issues without support having to do anything.
A self-billing invoice was sent to the wrong receiver. As a buyer you submit it as a purchase invoice, as a supplier as a sales invoice.
What can you do? Resubmit the invoice to the correct email address (purchase or sales).
With ZUGFeRD invoices (hybrid PDF with embedded XML) the conversion task can show the status "Successfully processed", while the invoice does not appear in your inbox. In that case IDR recognition succeeded, but the conversion from CII format to UBL failed. The platform can only store valid UBL invoices.
What can you do? Contact support and state that the conversion task was marked as successful but the invoice is missing. The technical team can adjust the transformation so that similar invoices are processed correctly in future.
Tip: a ZUGFeRD invoice that scores "green" in external validators can still fail on the eConnect platform. That is because the platform applies stricter requirements (BIS Billing v3 / NLCIUS) than most CII validators.
On an incoming (PDF) purchase invoice, the message "VAT calculation is incorrect" means that the amounts and the VAT on the document or in the recognition do not add up. The document is therefore (temporarily) not forwarded to your accounting system or ERP. This message can also appear as a final status in the conversion task history.
A previously rejected document can still be booked successfully: the platform recalculates the amounts automatically (invoice total leading, then the VAT amounts and other values) and can make a document balance without further action from you.
If the rejection remains final, that is an exception but a deliberate choice by the quality team. If you dispute the rejection, it is up to you to show that the amounts do balance.
What can you do? First check the current status of the document in the conversion task history: if a successful status now appears after recalculation, resubmission is not needed. If the task is still open or in progress, wait for the recalculation. If the rejection remains and you think this is incorrect, contact support and explain why the amounts do balance.
A credit note supplied as XML by the supplier (for example via Peppol) is sometimes processed as a regular invoice instead of as a credit note. This happens because the supplier set the document type incorrectly in that XML: invoice code 380 (regular invoice) instead of 381 (credit note).
For a document supplied as XML, the supplier (or the supplier's source system) determines the document type. eConnect processes this XML as supplied and does not change the document type.
What can you do? Contact your supplier and ask them to resupply the credit note with the correct document type code (381). If the document arrived at eConnect as a PDF and not as XML from the supplier, contact support: in that case it may be a recognition error that can be improved.
The XML shows a different VAT amount or rate than the PDF invoice, with the message "The applied VAT differs from the expected rate". This occurs, for example, with a VAT rate of 17% (the Luxembourg standard rate). eConnect and the IDR support invoices with 17% VAT; this rate is not an unsupported or unknown rate.
The message is not an automatic recognition error. IDR processing first prioritises a correct total amount (the total amount payable), and then takes over the full VAT of the invoice. The IDR always takes the VAT amount and rate from the invoice itself; eConnect does not correct the invoice. Only if the VAT rate or amount in the XML actually differs from what is on the PDF invoice is there a structural recognition error.
What can you do? First check whether the total amount payable was taken over correctly. Then compare the VAT rate and amount on the PDF with the XML. If they match, there is no recognition error: the message is then only a validation warning. If the VAT amount or rate in the XML demonstrably differs from the PDF, contact support and send the original PDF and the related XML.
Note: tax booking questions (for example input VAT versus EU refund at a foreign VAT rate) are outside the scope of this error message. Contact your own tax adviser for this.
If the PDF invoice shows no VAT (also not as another amount such as insurance tax or a percentage of 21%), PDF conversion sets the VAT category to O (VAT not applicable). This also happens when the PDF does state a VAT number of the supplier.
This is product behaviour, not an automatic recognition error: IDR processing bases the VAT category on what is actually stated as VAT on the document, not on the presence of a VAT number.
What can you do? Does the PDF show VAT, but is it missing in the XML? Then there may be a recognition error. In that case contact support via Feedback PDF-conversion and send the original PDF and the related XML.
After resolving the problem you can resubmit the document by email. Send it to the same email address as the first time. The platform treats it as a new document and starts a new conversion task.
If you think an invoice was rejected incorrectly, you can report this via support.econnect.eu. Send the document concerned with the request for recheck. The eConnect team reviews the invoice again and adjusts the classification or recognition if needed.
Note: every correction the Quality Control team makes is fed back to the IDR as training data. A similar error is then prevented automatically in future.
Want to understand how the full conversion process works? Read Conversion task: the process from start to finish.
Contact support