AI invoice processing: how reading supplier invoices works

In many companies, someone on the team opens the week's supplier invoices and copies the same fields into the ERP or the accounting software. It is repetitive work in which a slip takes time to find later, and it is one of the places where AI already helps in a predictable way, provided a person still approves what goes into the books. The reading can be done with tools your company probably already has, although it still goes wrong on certain kinds of invoice, described further down.

What happens to an invoice, from the inbox to the ledger

There are five steps, and only the last one touches the accounts.

1. The invoice arrives, usually by email as a PDF and sometimes as a scan or a photo of a paper invoice. The tool collects invoices from an address or a folder set aside for the purpose.
2. The tool reads the fields: the supplier and its tax number, the invoice date and number, the net amount, the VAT, the total and, where the company needs them, the lines with description, quantity and price.
3. It checks the reading against what the company already knows. The tax number has to match a supplier on your list, the invoice number must not have been posted before and, if there is a purchase order, the quantities and prices should agree with it.
4. It prepares the entry. Depending on the ERP, this sits as a draft in the software itself or in a list awaiting approval, with the supplier identified and the account proposed.
5. A person reviews and approves, and only then is anything posted. Invoices that fail one of the checks in step three go straight to a person, with a note of what did not match.

How AI invoice processing differs from invoice OCR

OCR, optical character recognition, turns the image of a page into text. For years, invoice OCR stopped there, and someone had to teach the software where to find the total on each supplier's layout.

Current invoice models run OCR and then work out which part of the text belongs to which field, separating the supplier's tax number, the total and the table of products. Microsoft describes its AI Builder invoice model in these terms: it runs OCR on every file and returns the fields already identified. On our reading, this means invoices from a new supplier can be read without setting up a model for each one.

What the reviewer sees on screen

Suppose, as an illustration, that an invoice from a packaging supplier opens on the left of the screen. On the right are the fields the tool has read: the supplier's name and tax number, already linked to its record in the ERP, the invoice number and date, the net amount, VAT and total, and the product lines, each next to the matching line of the purchase order.

Two of the lines agree with the order, and the tool flags the third, where more has been invoiced than was ordered. The total is marked as well, because the model reported low confidence in reading that field, which can happen when the scan is blurred in that area. After correcting or confirming those two points, the reviewer approves the invoice. If the quantity difference is real, the invoice goes back to whoever handles purchasing.

What Portuguese invoices carry: the ATCUD and the QR code

Invoices issued in Portugal carry two elements a tool can use, both regulated by Portaria n.º 195/2020 of 13 August.

The ATCUD is the document's unique code. Under the Portaria, it must appear on every invoice and other tax-relevant document, in the format «ATCUD:CodigodeValidação-NumeroSequencial», and on every page of documents longer than one page. It combines the series validation code assigned by the Tax and Customs Authority (AT) with the document's sequential number within that series. Together with the supplier's tax number, it helps the tool recognise an invoice that has arrived twice.

The QR code must appear on invoices issued by invoicing software certified by the AT, and on documents of several pages it can sit on the first or the last. How it is generated follows technical specifications set by the AT and published on the Portal das Finanças. When we build a tool, we use that specification to work out which parts of the code can confirm what was read from the text.

Where the reading goes wrong, and why a person still approves

The vendors themselves state some limits. Microsoft recommends one clear photo or scan per invoice and acknowledges that, for a particular type of invoice, some standard fields may not be extracted well. The difficult cases are familiar to anyone who has keyed invoices by hand:

• crooked or low-resolution scans, and photos taken with a phone on top of a desk;
• handwriting on top of the invoice, such as an order number added in pen;
• unusual layouts, such as tables of lines split across pages;
• credit notes, which look like an invoice and reduce the amount owed, and which the tool has to handle separately.

The models report how confident they are about each field, but high confidence does not guarantee a correct reading, and a wrong tax number or total may only surface weeks later, at reconciliation or in the VAT return, which is why a person stays in the process. The rule we follow is that nothing is posted without approval, and whatever the tool cannot check goes to a person with the reason written down.

Which tools exist on Microsoft 365 and Google, and where the data stays

If your company uses Microsoft 365, Microsoft offers two options. The AI Builder invoice processing model runs inside Power Automate and reads PDF, JPEG and PNG files. Its list of supported languages includes Portuguese (Portugal), and it returns, field by field, the vendor's tax ID, the invoice number and date, the purchase order reference, the totals, the tax details and the line items, each with a confidence score. For custom integrations, the Azure AI Document Intelligence invoice model reads photos, scans and PDFs, and also lists Portuguese for Portugal among its supported languages.

If your company uses Google Workspace, the equivalent is the Invoice Parser in Document AI, a Google Cloud service. It reads header fields and line items, including the supplier's name and tax ID and the VAT fields, and Portuguese is on its list of supported languages. It is set up in a Google Cloud project that belongs to your company, and Google offers an EU location for the processor.

We set the tool up in your company's own accounts, in Microsoft 365 and your Azure subscription or in your company's Google Cloud project, and the invoices and what is read from them stay there. Before any build we sign a GDPR data-processing agreement with you. The technology page explains how we choose between these options, including an open model on the company's own server.

Where to start in a company like yours

Invoice reading can be one of the two tools in the Start programme. Over its 30 days your team takes the workshop, and both tools go live on the systems the company already uses, with support throughout that period.

It is worth gathering a sample of real invoices from your usual suppliers now, including the worst scans and a few credit notes. We test the tool on those invoices before it goes into use, and again after every change.