AI document recognition in business

How AI differs from classic text recognition

Classic text recognition, or OCR, turns an image or a scan into a set of characters. It answers the question "what is written on the page", but it doesn't know where the amount is in that text and where the document number is. To get structured data from the text, people usually set up templates: a separate field layout for each supplier.

Templates work as long as the form doesn't change. A new supplier, a different invoice layout or a shifted table, and you have to set everything up again. An AI model reads a document more like an employee does. It finds the fields by meaning, wherever they sit on the page. It understands that "Total due" and "Amount" mean the same thing in different forms. And it can look up terms in the text of a contract.

One important caveat: AI can make mistakes, and they can look convincing. So extraction is only part of the solution. It needs checks around it, matching against your reference lists, and a clear procedure for cases where the result can't be trusted without a person.

Which documents suit document processing automation

A good fit is a flow with many documents, a repeating set of fields and layouts that differ from sender to sender. Typical examples are in the list below.

Rare, one-off documents are a poorer fit: setting up automation for them costs more than processing them by hand. Also assess the quality of the source files: unreadable scans, photos taken at an angle, handwritten notes. This isn't a ban, but such files more often go to a person for review, and you should account for that in your estimate.

So it makes sense to start with one document type and one flow, for example incoming supplier invoices. It is easier to measure the result there and decide whether to extend the approach to other documents.

• Invoices and acts: party details, number and date, line items, amounts, tax.
• Contracts: parties, subject, terms, amounts, payment conditions, deviations from the standard form.
• Requests from email and messengers: who is writing, what they ask for, and for which order or site.
• Appendices and supporting documents that need to be linked to the main one.

How extraction, checking and matching work

A document is processed step by step. First, a few terms. Extraction means finding the field values in the document. Checking means making sure the values don't contradict each other or your rules. Matching means linking the found values to records in your systems.

Matching is the step people underestimate most. Reading a company name from an invoice is easy. It is harder to see that it is the same company already in your records, written differently: another form of the name, or a typo. This step decides whether a duplicate counterparty appears in the system or the document lands on the right record.

Checks are useful because they catch errors by objective signs, not by the model's "confidence": the totals don't add up, a required field is missing, the counterparty isn't in the database. Each such sign is a reason to show the document to a person.

• Intake: the document enters processing from the channel where it arrives now, such as email, a messenger, 1C or a folder.
• Classification: the document type is identified, whether invoice, act, contract or request, and the set of fields is chosen.
• Extraction: parties, numbers, dates, amounts and line items are found.
• Checking: whether totals match line items, whether the details are in the correct format, whether required fields are filled in.
• Matching: finding the counterparty in the reference list, linking the invoice to a contract or order, and line items to the item catalog.
• Structuring: assembling the result in a single format for passing to the system.

Where the result goes: document recognition in 1C and CRM

Extracted data is valuable only when it ends up where people work with it. If the result sits in a separate window or spreadsheet, an employee still copies it by hand, and the benefit is lost. That is why the solution is built into the systems you already use, such as 1C (a Russian ERP platform), CRM, ERP or internal services, through an API, without replacing what already works.

The result can take different forms: a filled-in counterparty record, a request or deal in CRM, or a document in the accounting system. It makes sense to set this up so that an automatically created document is marked as prepared and waits for confirmation where a mistake is costly, and passes through without stopping in other cases. Which actions the system performs without a person is decided in advance and written down.

Before work starts, clarify how data exchange works at your company: which reference lists exist in 1C, who maintains them, which fields are required, and whether there are integrations with other systems. This determines the scope of the connection and is one of the main factors in estimating timelines.

Disputed cases: when a person should see the document

No system will process an entire flow without exceptions, and that is normal. What matters is that exceptions don't get lost or slip through unnoticed. To achieve this, you set rules in advance for when a document goes to an employee for review.

It helps an employee when the document is open next to the extracted fields and doubtful values are highlighted. The review takes minutes and doesn't repeat all the manual work. Corrections are recorded, and they show which kinds of errors keep recurring. The rules and settings are then refined on that basis.

Decide separately who is responsible for disputed documents and how soon they must be handled. If nobody owns the exception queue, it quickly becomes a new place where invoices and requests get lost.

• The model isn't sure of a field value or didn't find a required one.
• A check failed: the totals don't match or the details are in the wrong format.
• A counterparty or line item isn't found in the reference list, or several records fit at once.
• The document is of a new kind that wasn't in the flow before.
• The contract terms differ from the standard ones and need review by a lawyer or a manager.

How to measure quality on your own documents before launch

Demo examples from a contractor don't tell you how the solution will handle your document flow. You need to test quality on real documents. It makes sense to do this in a pilot, before the full solution is built.

A common mistake is to judge by a few clean examples or by average accuracy. The average hides the fact that a key field, such as the amount, is wrong more often than the others. A second mistake is leaving hard documents out of the sample. Those are the ones that cause problems later in daily work.

If your documents contain personal data, decide in advance which fields the solution really needs, and pass anonymized samples where you can. Requirements of Federal Law No. 152-FZ (the Russian personal data law) are built in at the design stage, not added after the solution is finished.

• Collect a sample of real documents: typical ones, plus poor scans, photos, rare suppliers and non-standard contracts.
• Ask employees who know the process to mark the correct field values. This is your reference.
• Compare the result with the reference field by field, not with one overall score.
• Work out the cost of an error: a wrong amount or counterparty matters more than an inaccuracy in a comment.
• Put the acceptance criterion in writing: which fields, and at what accuracy, must pass without a person.
• Run the test in parallel with manual work and compare the outputs of the solution and your employees.

What to ask a contractor and how we start

Before you choose a contractor, ask the questions in the list below. The answers usually show quickly whether the contractor is ready to work with your documents, not demo ones.

We start with a free discovery of one process. We look at how documents are handled now, whether there is data to automate with, and whether you need AI here at all, since some tasks are solved by ordinary automation or a ready-made service. You get a written document with a process map, the boundaries of the solution and an acceptance criterion. Then we build a prototype on your real data. Disputed cases in it go to a person. AI document processing starts at $2,100, and the first prototype on your data takes from 3 weeks. Integrations with 1C (a Russian ERP platform) and CRM start at $3,600 and 4 weeks. We give the exact price and timeline after discovery.

After launch there are two options: your team runs the solution, or we take over support. Support packages are 10, 20 and 40 hours a month, from $400. The option is fixed in the contract together with acceptance.

• Can we test the solution on our documents before signing for the full scope of work?
• How is the acceptance criterion fixed, and what happens if the solution doesn't meet it?
• What does the system do with documents it isn't sure about, and who sees them?
• In which system will the result appear, and do we need to change what already works?
• Where is the solution deployed, and how are personal data requirements handled?
• Who is responsible for the solution after launch, and on what terms?