Orders, delivery notes and invoices: from data entry to review

Context

The PDF is in your inbox. The order is still missing from your ERP. You open the attachment, find the customer or supplier record, copy the codes and check quantities and prices. Then you do it again for the next document.

In distribution and manufacturing, orders, delivery notes and invoices arrive through different channels. Their layouts and references do not always match. Entering them takes concentration; making sense of them takes experience. Someone who knows a supplier can judge when an unfamiliar description means the usual item and when it needs checking.

We have built this representative scenario around the sector's working practices. The comparisons describe a proposed workflow, rather than results from a particular client. We take documents through extraction, checks against your ERP and human review before anything is entered.

The challenge

1. The same data gets entered twice, with someone typing it the second time. The code is legible in the PDF but absent from the field where you need it. You bridge the gap: copying, looking up records, switching windows. When the supplier's code differs from yours, you also have to decide which item it means. Extracting the text leaves that decision unresolved.

2. The cost gets lost in the daily workload. You already pay for data entry through staff costs. What is often missing is a record of how much time the process takes: reading, searching, making calls and correcting mistakes. You notice it when someone is off or a backlog builds up. Without separating out those activities, it is hard to judge how much work could be saved.

3. Document matching competes with deadlines. You need to reconcile quantities and prices while shipments need arranging and payments need authorising. Spot checks leave some documents unmatched. A discrepancy found after payment means searching records and contacting the supplier. Even recovering a modest amount can tie up someone who already has a full workload.

4. A new layout needs checking. Columns move, descriptions change and the order reference appears somewhere else. Extraction rules need updating and testing. A model can handle different layouts, but a change still matters: it may confuse the quantity delivered with the quantity ordered and return a plausible value.

The numbers to watch

Before making changes, we measure the work using your documents. We separate the time people spend on a document from the time it spends waiting: they call for different improvements.

• How many minutes of work does a document need, including checks and corrections?
• How long does it take from arrival to entry, on average and in the worst cases?
• How many documents arrive, broken down by type and supplier?
• What proportion of fields is correct first time, checked against the original document?
• How many exceptions need intervention, why do they occur and how much work do they take?
• How many duplicate invoices and discrepancies between orders, delivery notes and invoices do you find? How many surface after payment?
• What does handling a document cost, including everyone's time?

When we compare the proposed process with the baseline, we include service costs, maintenance and exception handling. A draft that is quick to produce but slow to correct may offer no saving. A good average can also conceal frequent errors in documents where accuracy matters most. We break the results down by field type and supplier.

Our approach

1. Choose a document type and establish the baseline. We identify a workflow where volume and manual effort justify a trial. We collect routine and awkward examples, including poor scans and partial deliveries. Where you already have structured data that can be imported, we start there. We use the model for the extraction you actually need, avoiding unnecessary attempts to reconstruct data that is already available.

2. Check extracted fields against your ERP records. We match customers or suppliers and check item codes, quantities and order terms. We agree how to handle discounts, rounding and partial deliveries. The output remains a draft. If a document needed for matching is missing, we flag it. If the master data gives an ambiguous match, we ask for a review. A populated field is no proof of accuracy.

3. Give exceptions to someone who can resolve them. We define the checks and test any confidence indicators against your documents. A high score does not establish that a field is correct. Detected problems hold the document in an exception queue, with a clear reason and someone responsible for it. Other drafts still need human review and confirmation. Reviewers must be able to compare the data with the original straight away, then correct or reject it.

4. Keep a record of extraction, changes and approval. We link the source document to extracted fields, check results and corrections. We record who confirmed it and when, with access and retention periods agreed for the project. That history also helps us identify what needs attention: a layout being misread, an ambiguous match or a rule that needs changing. We keep measuring errors after launch as documents and working conditions change.

What changes

In the proposed workflow, the person handling data entry starts with a draft alongside the source document. They can focus on matching, discrepancies and missing information. The record is entered after confirmation.

You can see which documents are waiting for review, how long they have been there and why. You can trace a quantity back to its source and distinguish the model's reading from a person's correction. If the delivery note is missing, matching remains incomplete and must be shown as such.

Reviewing is work. It takes time, training and the authority to put a document on hold. We involve the people who will do it in the trial: a screen that suits its designer may be awkward for someone using it every day. We assess the benefit across the whole process, including any work passed to the people handling exceptions.

What people fear, and what we tell them

"The model misreads something and a wrong figure ends up in the accounts." That can happen. Models make mistakes, even on documents that look straightforward. Automated checks and human review reduce the risk, but both can miss an error. During the trial, we count the errors that escape the checks as well, recording the field affected and the consequence. We agree when to stop the workflow and return to manual handling. If the errors remain unacceptable for the process, the trial does not justify going live.

"Where do our documents go?" We send them to a service outside your systems for processing. The models run on AWS Bedrock with European Union inference profiles; data is processed in the European Union. Before work starts, we document what data is sent, which service receives it, who can access it and how long it is retained, including copies and logs covered by the project. Processing in the EU does not, on its own, answer all those questions.

"If it gets something wrong, who is responsible?" Adding an approval button does not settle that. Before work starts, we define who checks, who authorises entry, who handles exceptions and what we are responsible for in the integration and agreed checks. We document these duties and how errors will be handled. The audit trail helps establish what happened; it cannot assign responsibility on its own. Whoever confirms a document needs the information, expertise and time to do so.

How we approach it today

We start with a scoping workshop, looking at your documents and the work it takes to enter them. We set the scope of a trial, define what to measure and identify who needs to take part. We assess cost per document, data quality and the workload from exceptions. Savings only make sense if the process remains manageable and properly checked.

If volumes do not justify the integration, or reviewing absorbs the benefit, we tell you. The same applies if improving an existing import would do the job. The trial must give you enough evidence to decide to stop, too.

• AI integration in the systems you already use
• Odoo and integrated ERP
• The AIRA method

Bring an example that means searching through emails or calling a supplier. Let's talk: 30 minutes, with no obligation, to see whether any part of that work is worth automating.