The IDR (Intelligent Document Recogniser) automatically recognises the most important 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.

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

With the Professional subscription, additional fields are recognised:

Search variants: "Meta invoice number", "Facebook invoice transaction ID", "invoice number Meta not recognised", "Meta invoice number transaction ID", "invoice number page 2 Meta", "transaction ID as invoice number", "company registration as invoice number", "company registration number as invoice number", "invoice number is company registration", "incorrect invoice number company registration", "chamber of commerce as invoice number", "invoice number not correctly read", "incorrect invoice number OCR", "invoice number with slash", "invoice number backslash", "two-part invoice number", "purchase order number as invoice number", "PO number as invoice number", "incorrect invoice number", "wrong invoice number", "invoice number not correctly transferred", "invoice number truncated", "incorrect invoice number IDR", "SampleStore invoice number", "RegEx invoice number recognition", "improve recognition supplier", "invoice number half recognised", "incorrect invoice number transferred", "invoice number recognition improved", "attachment correct invoice number", "incorrect invoice number supplier", "payment reference as invoice number", "bank reference as invoice number", "bank number as invoice number", "incorrect invoice number to ERP", "short number instead of invoice number", "incorrect short number recognised", "invoice number prefix not recognised", "recognition was correct now wrong again", "platform XML Inbox", "AFAS export no IDR".

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 (for example due to a slash, backslash or an invoice number consisting of two parts). 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 — typically page 2 — and the transaction ID is recognised more prominently), the supplier's company registration number instead of the real invoice number, a purchase order number/order number (PO) instead of the real invoice number, 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 also plays a role when a credit note is incorrectly blocked 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.

How does recognition work behind the scenes (SampleStore)? For ordinary invoice number recognition, the IDR uses the SampleStore: a database of recognition patterns per supplier. The process runs in three steps: (1) the system looks for numbers matching a RegEx pattern in the SampleStore, (2) found numbers are compared with previous examples from the same supplier (length, structure, hyphens, dots, underscores, consistency), (3) the system learns automatically from new invoices. If you report a deviating or incomplete invoice number, support checks the SampleStore for that supplier and adds examples and optionally a RegEx so the full pattern matches. Once the fix is applied, future invoices from that supplier should be recognised correctly.

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.

No manual adjustment on the platform. In addition to recognition not being customer-configurable, the invoice number on a document in eConnect also cannot be manually overwritten or changed. In urgent cases: download the document and correct the invoice number in your target system or ERP. Also always report the discrepancy to support (see steps below) so that recognition can be structurally improved.

What can you do?

1. Open the document in the Inbox and collect the Document ID of the affected conversion(s) plus the invoice number as it appears on the later page (at least one example), or download the original PDF and associated XML
2. Report this to support (Feedback PDF-conversion)
3. Based on the report, the team adds a supplier-specific hint, after which future invoices of that format will receive the correct invoice number. If the improvement has already been rolled out via a release, a brief confirmation that this has been addressed suffices; there is no hard guarantee on reprocessing of already-processed documents without resubmission.

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.

The IDR recognises dates on PDF invoices and converts them to the standard UBL date format (YYYY-MM-DD). Because date formats differ per country, the IDR determines, based on the supplier's country, how ambiguous dates are interpreted:

• 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 sufficient, a specific hint for the date format can be added per supplier.

Tip: incorrectly interpreted dates (for example 03/11 as 11 March instead of 3 November) are almost always a recognition issue, not a platform problem. 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 previously verified, this is flagged. This helps detect phantom invoices or changed bank details.

Note: the IBAN on an invoice serves primarily as supplier identification under European standard EN16931, not as a payment instruction. A changed IBAN must always first be validated in the master data of your financial system before payment is made.

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

The recognition of configurable references uses a three-layer mechanism:

1. Regex: format validation to ensure the extracted reference exactly meets the expected format
2. Outlier detection: statistical deviation detection that intercepts improbable 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 by most suppliers on the invoice. If a supplier cannot fill in a particular reference field in their software, there is little point in 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.

With line recognition, individual invoice lines are also recognised: description, unit price, quantity, line amount and reference fields per line.

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