AI recognition of invoices and delivery notes: how to verify the result

A manager opens a PDF invoice from a supplier and retypes the number, date, company details and twenty line items into the CRM. Tomorrow another dozen such files will arrive, along with a photo of a delivery note and a price list in Excel. AI recognition of invoices and delivery notes takes over most of this work on one condition: the model’s output is checked before it is written to your system. Below: what the model reads reliably, where it makes mistakes, how to build a process with checks and what providers do with data sent via the API (an application programming interface: your system calls the model directly, without a chat window).

Invoices and delivery notes AI reads well

AI document recognition runs on models that understand images (multimodal models). They read the same files that arrive on any ordinary workday:

• PDFs with a text layer. Payment invoices from accounting software and online banking. The text is already there, so extracting data from a PDF comes down to finding the right fields.
• Scans and PDFs without a text layer. The model reads the page as an image, so scan quality decides almost everything. (Claude, for example, turns every page of any PDF into an image and, if the file contains text, passes it along as well.)
• Phone photos. A delivery note on the hood of a car, a signed and stamped certificate of completion. These read worse: shadows, tilt and glare spoil the result more than a person would expect.
• Excel and CSV files with different structures. One supplier’s price list starts with a five-row header, another hides the SKU in the product name, a third has its own category on each sheet.
• Emails with attachments, where some of the details are in the body of the email and some in the file.

If your counterparties send documents through an electronic document exchange service, first find out whether the service provides data in a structured form (via an API or an export). If it does, those documents do not need recognition, and the model is left for everything else: PDFs from email, scans, photos and price lists.

Classic template-based OCR (software that turns an image into text using fields marked up in advance) requires markup for each supplier: it sees “15.10.2026” and, without a rule, does not know whether that is the invoice date or the payment due date. A model usually understands the difference from the meaning and the neighboring labels, so a new supplier with an unfamiliar layout does not require separate setup. Its first documents are still worth checking by hand.

Templates are not obsolete, though: if a large supplier has sent invoices in the same layout for years, a template for that supplier costs less to run and is more predictable than a model. Production systems often combine both approaches: standard documents go through templates, non-standard ones through the model.

The weak spots are known. The model reads long multi-page line-item tables, handwritten notes and crumpled or faded copies worst of all. Merged files are a separate problem: if one PDF contains a contract, an invoice and a certificate of completion, the model may take the amount from the neighboring document. Such files are split into parts first, and only then is the data extracted.

Why the result must be checked

A model makes mistakes differently than a person does. A tired employee skips a line, and the gap is visible. A model fills in every field neatly and uniformly, including the ones where it was wrong: it may fill an empty table cell with a plausible value from the neighboring row or “correct” an SKU with similar digits to one that appeared more often. Such an answer is called a hallucination: confident in form and wrong in substance.

A simple calculation. The model extracts 97% of fields correctly, and an invoice has 15 fields. The probability that all 15 are correct is 0.97 to the power of 15, about 63%. Roughly one document in three contains at least one error.

Providers offer a structured output mode: the model returns data strictly according to a given schema (number, date, the supplier’s EDRPOU code, list of line items), and your code does not break on an unexpected format. The schema only ensures the format. Google’s Gemini API documentation says so directly: the response will be syntactically valid JSON (a standard data format for exchange between programs), and the values must be validated in your application. OpenAI and Anthropic promise the same: schema compliance, required fields and data types. The documentation of all three providers says nothing about the correctness of the values themselves.

A recognition process with checks

The model reads the document, the code checks and calculates, and a person confirms anything questionable. Step by step:

1. Intake. Documents arrive at a dedicated mailbox, through a form in a personal account or in a Telegram bot to which an employee sends a photo of a delivery note from the warehouse.
2. Preparation. The code splits merged PDFs into separate documents. The model determines the type of each one (invoice, delivery note, certificate of completion, contract), and a field schema is selected for that type. From files with a text layer, the code takes the existing text; pages without text (scans, photos) are sent to the model as images.
3. Extraction. The model returns fields according to the schema: the parties’ details, number and date, line items with quantity, price and amount, totals.
4. Code checks based on the rules in the next section.
5. Confirmation. Documents with no issues move on automatically (when you are ready for that); documents with issues go to an employee’s review screen.
6. Recording. The data goes to the CRM, online store, Google Sheet, accounting system or your own database. The original file, the extracted values and the employee’s corrections are saved in a log, which shows where the model makes mistakes most often.

What the code checks

Most of the model’s errors are caught by the same checks an experienced accountant or warehouse clerk does in their head. The set depends on your documents, but the basic list is almost always the same:

• Arithmetic. Quantity × price = line amount. Sum of lines = total. Total excluding VAT + VAT = total including VAT. If even one of these equations does not balance down to the kopiyka (the smallest hryvnia unit), the document goes for review: a misread digit almost always breaks one of the equations. The code does the math; the model only reads the numbers.
• Company details. An EDRPOU code (the company’s registration code in the state register) has a check digit, so most typos can be spotted with a simple calculation, without querying the register. An IBAN with the UA country code is 29 characters long and contains two check digits, so most typos in an account number can also be caught by calculation. Tax numbers in other countries have their own rules, and these are added for your counterparties.
• Reference data. Is there a counterparty with this code in the database? Is the SKU in the catalog? Does the unit of measure match the product record? An unknown supplier or product is a reason to show the document to a person.
• Matching against the order. Line items and prices in the invoice must match the purchase order, and quantities in the delivery note must match what was received at the warehouse. A discrepancy holds payment or receipt posting until an employee decides.
• Duplicates. A document with the same number, date and counterparty has already been uploaded: the supplier resent the invoice, or two employees uploaded the same file. Without this check, payment or receipt posting goes through twice.
• Plausibility. The document date is not in the future and not two years old. The price differs from the previous purchase by no more than a percentage you set. The quantity is not an order of magnitude higher than usual.

What is left to a person

The review screen is simple: the document on the left, the extracted fields on the right, with questionable ones highlighted and explained (“sum of lines does not match the total by 120.00”). The employee corrects one field and confirms the document instead of retyping all of it.

We recommend starting with manual confirmation of every document. After a few weeks, the log will show which fields the model reads without errors and which ones the employee keeps correcting. Then automatic acceptance is turned on by document type and field: for example, invoices from regular suppliers in PDFs with a text layer go through on their own, while photos of delivery notes are still reviewed by a person. Even after that, some automatically accepted documents are spot-checked, since this is the only way to see the real accuracy. The “confidence” the model reports about itself is not suitable for this.

Supplier price lists: store prices and stock

A common separate case is updating prices from a supplier’s price list. A store works with a dozen suppliers, and each sends its file in its own way: one shows stock as a number, another as “in stock / out of stock / on order,” a third as “>10.” One uses the manufacturer’s SKU, another its own internal code, a third only a name like “Faucet f/kitchen chrome D40 gooseneck.”

The model handles two tasks that used to require manual setup for each file:

• it finds which column holds the SKU, price, currency and stock, even if the supplier has changed the template;
• it matches “messy” names and other companies’ SKUs to the product records in your catalog and suggests a match with an explanation of why that product was chosen.

Then the code takes over: it applies your markup by category and your rounding rules, converts currency at your exchange rate and checks the minimum margin. A price change above a set threshold, a new product with no record in the catalog or a doubtful match goes to a confirmation queue. A confirmed match is saved, and next time the same SKU is linked without the model and without questions.

In an online store on WooCommerce or another platform, prices and stock are updated on a schedule. The content manager only deals with the exceptions.

Off-the-shelf service or custom development

There are many ready-made document recognition services, and for some tasks they are a good fit. If you need recognition of payment invoices and other standard primary accounting documents, the data goes to accounting software the service already supports and its data storage terms suit you, choose a ready-made service: connecting it will cost less and take less time than development.

Custom development is justified in four situations:

• Your own documents. Order specifications, measurement reports, dealer requests, certificates, price lists: anything for which a ready-made service has no field schema.
• Your own rules. Minimum margin, counterparty limits, matching against the order in your CRM, special units of measure.
• The data does not go to accounting but to a CRM, an online store, a warehouse spreadsheet, a corporate portal or a custom-built system with no ready-made connector.
• The data must not leave the company: contracts, personal data, commercial terms. Then you need control over the route of every file, up to a model on your own server.

If you have a dozen documents a week and they are all alike, automation will not pay off. A project pays off where manual entry takes up a noticeable part of someone’s workday or where data entry errors have already cost money. Besides development, the costs include API fees for each page (or a server for your own model) and maintaining the validation rules after launch. It only saves money when the employee time saved is worth more than these costs.

Where the data goes: API or your own server

Whether a provider uses your invoices for training depends on how you connect. Below is what the official policies of the three providers say (checked on October 21, 2026; terms change, so reread them before launch).

• OpenAI API. Since March 1, 2023, data sent via the API is not used to train models unless you have opted in. Logs for abuse monitoring are retained for up to 30 days. A no-retention mode (Zero Data Retention) and processing in the European region are available after approval by OpenAI. Source: the Your data page in the OpenAI documentation.
• Anthropic API. Inputs and outputs of commercial products, which include the API, are not used for training by default; the exception is when you have sent feedback or opted in. Data is deleted from the servers within 30 days unless another agreement is in place (for example, on zero retention). Requests that an automated system has flagged as violating the usage policy are retained for up to 2 years. Sources: the Privacy Center articles on retention periods and on model training.
• Google Gemini API. The terms depend on the tier: free or paid. On the free tier, Google uses prompts and responses to improve its products, they may be read by human reviewers, and the terms explicitly ask you not to submit confidential or personal data. On the paid tier, prompts are not used for training and are retained for a limited time only to detect violations. For the European Economic Area (EU countries plus Iceland, Liechtenstein and Norway), Switzerland and the United Kingdom, the paid tier terms also apply to the free quota. Ukraine, Kazakhstan and other CIS countries are not on this list: their free quota runs under the free tier terms. Source: Gemini API Additional Terms of Service.

For most invoices and delivery notes, a paid API with these terms is sufficient. A separate risk is an employee who pastes a contract into a personal free chatbot because it is faster. A proper work tool reduces the temptation, but a ban and an explanation are still needed.

If documents arrive via Telegram, keep in mind how the messenger works. A conversation with a bot is a regular cloud chat: encryption works between the client and the server, and there is no end-to-end encryption. For contracts and passport scans, an upload form on your server is more reliable (it can be opened inside Telegram as a Mini App). One more limitation: through the standard Bot API, a bot downloads files up to 20 MB. Multi-page scans can be larger, and then you need your own Bot API server, which has no download limit.

A neural network on your own server

A neural network on your own server is an open model deployed on your own or a rented server with a graphics card (GPU). This option is for cases where documents must not leave your infrastructure at all: files are processed internally, and no external provider sees them.

The main advantage is full control over the data. The second is savings, but only at high volume: you pay for the server rather than for each page, and at low volume the server costs more than the API. There are more disadvantages. You need a GPU server and someone to administer and update it. Open models that fit on such a server usually fall short of large cloud models on complex documents: long tables, poor photos, mixed languages. Code checks and a review screen are needed just the same: a local model makes mistakes no less often than a cloud one.

There is a middle option: documents without sensitive data (price lists, invoices from regular suppliers) go through a paid API, while contracts and anything with personal data are processed by a model on your server. The route is set by a rule based on document type and counterparty.

How to start a pilot

1. Choose one document stream where manual entry takes the most time: incoming invoices, warehouse delivery notes or price lists.
2. Collect real documents from several months, including bad scans, photos and the most awkward layouts. Five “pretty” PDFs will tell you nothing about how it works on the normal flow.
3. Prepare a reference set: the correct field values entered by a person. The model is not tuned on this sample; it is only tested on it.
4. Measure accuracy by whole documents: a document is correct only if all of its fields are correct. Look separately at critical fields: amounts, company details, quantities.
5. Write down the validation rules that employees currently keep in their heads. They will become the basis for the code.
6. Decide where and in what form the data goes: as a draft for confirmation or directly as a working record.

If after the pilot the model keeps making mistakes in the same place, changing the threshold at which a document is sent for review is not enough. You need to find the cause: different page preparation, a refined field schema, an additional validation rule.

How RIVERIT can help

We develop AI business automation for your documents: extracting data from invoices, delivery notes, price lists and other files with checks based on your rules. We connect OpenAI, Anthropic and Google models via the API or deploy an open model on your server if the data must not leave the company. We write the solution in code and integrate it with your CRM, online store, spreadsheets or your own database. Document intake can be organized through a Telegram bot with an admin panel. Learn more on the AI business automation page.