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: "incorrect invoice number", "purchase order number as invoice number", "PO number as invoice number", "order number as invoice number", "Meta invoice number", "company registration as invoice number".

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, or a purchase order number (PO) instead of the real invoice number. That last variant can also cause a credit note to be blocked incorrectly as a duplicate invoice.

Invoice-number recognition is not customer-configurable; support optimises it internally via outlier detection, regex and supplier-specific hints. Report mismatches via support (Feedback PDF-conversion) with the Document ID and/or PDF+XML.

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.

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