The IDR (Intelligent Document Recogniser) automatically recognises the key data on a PDF invoice and converts it into structured fields in the e-invoice. Which fields are recognised depends on your subscription and configuration.

For every PDF conversion, the following fields are recognised automatically:

With some supplier formats, the IDR may pick up a different field instead of the invoice number, or the recognised invoice number may differ from the format on the PDF. Examples: a transaction ID instead of the actual invoice number (known with Meta/Facebook invoices, where the invoice number appears at the bottom of a later page), the supplier's company registration number, a purchase order number (PO), or a bank/payment reference (for example a bank reference) instead of the real invoice number, resulting in an incorrect invoice number downstream in Coda or the ERP system. This last variant can also cause a credit note to be blocked incorrectly as a duplicate invoice (see Duplicate invoice). This is a field-selection error in recognition, separate from the correct recognition of a payment reference as a separate PaymentID field (see Direct debit & G-account): there the payment reference does not overwrite the invoice number; here it is mistakenly recognised in its place.

This can be improved for the supplier format in question. The recognition of the invoice number is not configurable by the customer, but is internally optimised by a support team member via outlier detection, regex and hints per supplier or format. No roadmap change is required; it is a targeted optimisation of existing functionality. Report such a case to support — based on the report, the team adds a supplier-specific hint so that future invoices of that format receive the correct invoice number.

How does recognition work behind the scenes (SampleStore)? The IDR uses the SampleStore for this: a database of recognition patterns per supplier. The process runs in three steps: (1) searching for numbers matching a RegEx pattern in the SampleStore, (2) comparing with previous examples from the same supplier (length, structure, hyphens, dots, underscores, consistency), (3) self-learning adjustment based on new invoices. Support adds examples and optionally a RegEx to the SampleStore after a report.

Short or different number instead of a longer prefix pattern. When a supplier's invoices normally have a fixed prefix and a fixed length, the IDR sometimes recognises a shorter or different number without that prefix. If the pattern (prefix, length, structure) is already clear from the report, the first step is to adjust the SampleStore or RegEx for that supplier directly; a PDF or XML example then serves as evidence, not a mandatory first step. If recognition worked correctly before and has become incorrect again over time, the same approach applies: check and adjust the SampleStore for that supplier, which is not an indication of a product defect.

For investigation, the platform XML from the Inbox is the useful file: it contains the IDR recognition trace. An XML that you export yourself from your ERP system (for example AFAS) after the invoice number has already been manually corrected typically lacks that IDR block and only shows the already-corrected number — that file is then not suitable for analysing the recognition error.

Hidden or transparent text in the PDF (template reuse). Some suppliers reuse an old invoice PDF as a template for new invoices. Old dates or invoice numbers may remain as invisible or transparent residual text in the PDF text layer. The IDR uses hybrid OCR: in addition to the visible image, the PDF text layer is also read. On a screenshot or on screen you only see the visible lines, but recognition sees the full text layer including hidden residual text. This can be the cause when an old and a new invoice number or date become mixed up in recognition. If you suspect this pattern, always request the original PDF: a screenshot is not sufficient because it lacks the text layer. Then copy the text from the file into a plain text editor to check the discrepancy against the visible display.

Search variants: "currency not correctly recognised", "currency incorrectly recognised", "wrong currency IDR", "SEK instead of NOK", "currency wrong PDF", "currency misread invoice", "currency recognition invoice", "PDF currency error", "currency incorrectly read".

Currency is a standard recognised field (see table above) and falls under the same generic PDF→XML recognition errors as invoice number or amount: the IDR may incorrectly recognise the ISO currency code compared to the PDF (for example SEK instead of NOK). This is not a separate feature and not a standalone issue, but the same recognition question as with other fields.

What can you do? Report the discrepancy to support and provide the original PDF plus the associated XML (from the Inbox), or the Document ID of the conversion task. Based on this, the team optimises recognition for the supplier format in question. As with other recognition errors, no hard turnaround time commitment applies here.

With the Professional subscription, additional fields are recognised:

The IDR recognises dates on PDF invoices and converts them to the standard UBL date format (YYYY-MM-DD). Because date notations differ by country, the IDR uses the supplier country to interpret ambiguous dates:

• United States: MDY (month-day-year). The date 03/11 is interpreted as 11 March.
• All other countries: DMY (day-month-year). The date 03/11 is interpreted as 3 November.

If automatic country detection is not enough, a specific hint for the date format can be added per supplier through the hint mechanism.

Tip: wrongly interpreted dates (for example 03/11 as 11 March instead of 3 November) are almost always a recognition issue, not a platform issue. The platform always displays the date as it appears in the UBL.

With the Professional subscription, the recognised IBAN is compared against the verification store: a database of previously manually validated IBAN numbers per supplier. If the IBAN on the invoice differs from what was verified earlier, this is flagged. This helps detect ghost invoices or changed bank details.

Note: according to European standard EN16931, the IBAN on an invoice is primarily for supplier identification, not as a payment instruction. A changed IBAN must always be validated in your financial system's master data before payment is made.

In addition to standard references (order number, contract number, project number), other references can be configured specifically per supplier. Think budget codes, budget holder codes or internal references. This is custom work set up on a strip card basis.

Configurable reference recognition uses a three-layer mechanism:

1. Regex: format validation to ensure the extracted reference exactly matches the expected format
2. Outlier detection: statistical deviation detection that catches unlikely values
3. Hints: automatically generated training data based on corrections by the QC team

Tip: the purchase order number is the most commonly used reference and is stated on the invoice by most suppliers. If a supplier cannot fill a certain reference field in their software, there is little point asking for it. In that case, use the purchase order number as the primary reference.

Note: purchase order number, contract number and project number are Professional standard fields, but recognition only becomes active after a one-time support setup per customer/supplier (based on at least 5 sample invoices, optionally supplemented with a regex). Contact support and preferably provide a sample invoice.

Do you get the informational API response Order Reference detection skipped as Sample store is empty or Contract Reference detection skipped as Sample store is empty? This is not a processing error. The IDR only fills these references once the Customer Sample Store for your endpoint contains sample references to match against. If the store is empty, only that reference detection is skipped; all other fields and features are recognised normally.

To resolve: provide a few sample order numbers or contract references (at least 3 characters per sample) exactly as they appear on the invoices, so support can configure them in the Customer Sample Store. After that, a label match applies first (for example "Your order number"), with regex as a fallback. A Remote Starter is also available via sales for setting up PO number recognition.

No, not directly in the platform. You do not manage the Customer Sample Store, the formatting rules or the RegEx for order number recognition yourself; eConnect support sets this up.

Indirectly, however, by:

• having suppliers invoice with a clear, uniform order reference format (see best practice below);
• sharing format knowledge (prefix, fixed length, structure) with support;
• providing the original PDF or Document ID plus the correct order number after a failed recognition, so support can update the Sample Store.

Best practice for order reference format on the PDF:

• state the order reference preferably once on the invoice, not repeated in multiple places;
• use a common label, for example Order number, PO number, Purchase order number or Your order number;
• separate label and number with a space or punctuation mark, for example Order number: 420000007 instead of PO420000007;
• maintain a fixed structure and preferably a fixed location on the invoice.

See also Submission errors for a blocked or rejected invoice due to an incorrectly recognised order number.

According to European standard EN16931, a reference (buyer reference) is mandatory on an e-invoice; this is often a purchase order number or another reference from the recipient. A sender can place an incorrect value in this field.

eConnect does not reject an invoice on the reference by default. An invoice only fails to meet the basic rules of the European standard if there is no reference at all. Whether an invoice is rejected due to an unknown or incorrect reference depends on the recipient's configuration: in a specific recipient configuration, an invoice can be rejected if the reference is unknown. This is therefore a property of the receiving configuration, not of standard eConnect processing.

Tip: if you want to reject invoices on missing or unknown references, configure this via RBE (Rule Based Enrichment) on the receiving endpoint.

The invoice number (UBL field cbc:ID, BT-1) is mandatory in EN 16931, UBL BIS Billing 3.0 and NLCIUS for regular invoices. However, the IDR processes a mixed document stream: regular invoices, credit notes, expense claims and receipts. Receipts fall under the simplified invoice regime (transactions up to approximately €100 including VAT), for which the tax authority does not set an invoice number as a legal requirement. Rejecting on a missing invoice number would exclude all receipts and expense claims from processing.

For this reason, the IDR pipeline automatically generates a surrogate number when no invoice number can be extracted from the document during recognition. The cbc:ID field (BT-1) is then filled with the structure:

YYYYMMDDHHmmss-NOTFOUND

The timestamp is the moment of processing by the IDR pipeline, not the date on the document itself. Example: 20240315143022-NOTFOUND.

Filtering is possible at two levels:

1. RBE (Rule Based Enrichment): configure a rule that checks whether BT-1 (cbc:ID) ends with -NOTFOUND. Based on this, the document can be held for manual review, redirected to a separate inbox, or automatically rejected.
2. Own systems (ERP/accounting package): a direct string match or regular expression on -NOTFOUND in the cbc:ID field is sufficient.

With line recognition, individual invoice lines are also recognised: description, unit price, quantity, line amount and reference fields per line. This is a separate feature you can activate yourself via My Environment.

Want to know how recognition works technically? Read How does Scan & Recognise (IDR/OCR) work?.