Reading an invoice is not understanding it: on-prem document processing at an airline

Reading the text on an invoice is no longer hard. OCR engines have done it well for years. The hard part is understanding what was read. Which amount is the total and which is a line? Which date is the invoice date and which is the due date? Is the table on page two a continuation of page one, or a separate breakdown?

The document-processing programme we built for the Finance and Accounting function of a national flag carrier is built on that second question. It runs in the airline’s own data centre, processes supplier invoices end to end, and is live. Without going into the airline’s internal details, this piece walks through the decisions that shaped the design.

How a supplier invoice moves through the line

The skeleton of the flow. I’m not sharing the airline’s internal details or volumes; the steps show how a programme like this is put together. Click a step, or press play.

1. 01Intake
2. 02Digitisation
3. 03Classification
4. 04Extraction
5. 05Rule checks
6. 06Human validation
7. 07Posting and audit

System

Intake

Whatever channel an invoice arrives through (email, scan, portal), it lands in a single intake queue. Each document gets a traceable ID, and a second copy of the same invoice is caught here.

Model

Digitisation

OCR/ICR turns the page into text with positions. The installation runs in the airline’s own data centre, so the document never leaves the building at any stage.

Model

Classification

The document type and language are identified. An invoice, a delivery note and attachments can arrive in one file; extraction only means something once the type is right.

Model

Extraction

Header fields (supplier, date, due date, currency) and line-item tables are extracted. Several tables, tables split across pages and country-specific decimal formats are handled here.

Rule

Rule checks

Do the lines add up to the invoice total? Does the currency fit the supplier? Is the supplier in master data? Each field’s confidence score is compared with the threshold set for that field.

Human

Human validation

A document below threshold, or one that fails a rule, goes to the validation screen. The reviewer doesn’t reread the whole invoice; they see the field that stopped and why.

System

Posting and audit

Approved data is posted to the ERP. Who corrected what is written to the audit trail, and corrected fields become input for the next model improvement.

Previous Play Next 1 / 7

The first constraint: documents don’t leave the building

The first decision that shaped the architecture wasn’t technical. It was institutional: documents would not be sent outside the organisation. That’s a common requirement for finance documents and, I think, a fair one. A supplier invoice carries bank details, contract prices and payment terms.

The consequence is that much of what you switch on with a few settings in the cloud becomes infrastructure work on-premises. Digitisation and extraction components have to run inside. Model versions, updates and capacity planning become part of the project. UiPath’s own documentation states that Document Understanding remains available for Automation Suite and Standalone deployments, which narrows the choice of product for any organisation with an on-premises requirement.

The lesson here, as I see it, is simple: plan the on-premises installation as its own work item, not a deployment detail. If it isn’t in the schedule from day one, it will squeeze something later.

Three gaps between reading and understanding

The scope of this programme fits in three phrases: multi-currency, multi-language, multi-table. Each is its own problem.

Multiple currencies. The currency isn’t always printed next to the amount. Decimal separators change from country to country, and the same supplier can change format over time. After extraction every amount has to be normalised and its currency checked against what the supplier usually invoices in. I’d leave that check to a rule, not the model. The model can be wrong; the fact that a supplier always bills in euros is already sitting in master data.

Multiple languages. The same field arrives under different labels in different languages, and non-Latin scripts are a challenge of their own. On another project we built a separate extraction pipeline for documents in Chinese characters, and it raised accuracy by 55%. That result points at something: instead of forcing every language through one model, splitting the troublesome language into its own pipeline is worth trying.

Multiple tables. Line items can be spread across several tables, tables break at the end of a page, and subtotals can look like lines. The best insurance is, again, a rule: if the lines don’t add up to the invoice total, the document doesn’t pass automatically.

Human validation is the design, not the fallback

Two parts of this programme set it apart: the design of the validation screen, and structured human-in-the-loop escalation. The second sounds abstract, so let me unpack it.

In unstructured escalation, a document goes to a person with a note that says “please check”. They reread it, find the problem themselves and repeat the same work every time. In structured escalation the document arrives with the reason it stopped: which field, which rule, which confidence score. Documents that stop for different reasons can go to different people. An unreadable field is work for the validation team; a supplier missing from master data is work for procurement.

There are two benefits. The reviewer’s time goes to the suspicious field, not the whole document. And because corrections are recorded with their reasons, you can measure which document types and which fields cause trouble. Those records decide where model improvement starts.

I set confidence thresholds per field, not per document. A small misread in the supplier name gets caught by master-data matching; a misread amount can turn into a payment before anyone notices. Applying the same threshold to both makes little sense.

Before you copy this

If a team were starting a similar programme, this is the list I’d hand them:

1. Collect a real month of documents. Don’t estimate anything before you’ve seen the spread of suppliers, languages, currencies and page counts.
2. Write down who will work the validation screen and how much time they have each week. A human step without capacity becomes a queue that slows everything down.
3. Decide with the business which field passes at which threshold, and name the owner of that decision.
4. Define the final consistency checks before posting to the ERP as rules. However good the model is, don’t leave those to it.
5. If you’re on-premises, put hardware, OCR engine licensing and the model-update procedure in the plan as separate lines.
6. Have a rollback plan for model version changes. A new version can improve one field and get worse on another.

None of these items is about AI. Most of the decisions that decide a document-processing project aren’t.