AI receipt recognition: data extraction with 94% accuracy

Why receipt data extraction breaks in high-volume flow

A primary document processing pipeline rarely breaks on a single document — it falls apart on volume. Scans from MFPs arrive mixed with phone photos taken at an angle and in poor light, bank exports — with faxes and re-sends.

Receipt data extraction tuned for clean receipts loses line items and confuses tax with the total on such a mix.

The second failure point is the receipt layout itself.

Receipt recognition runs up not against text but against geometry: an item name wraps to two lines, quantity and price are in separate columns, a discount comes as a negative amount, a return — as a separate block at the bottom.

Typical recognition errors look exactly like this: merged lines, lost quantity, an amount assigned to the wrong item.

Next comes the export. A correctly read receipt needs to be broken down into the fields of the accounting loop: item, quantity, tax rate, department — so that the data lands in 1C without manual adjustment.

Here errors do not spike but accumulate, and the share of manual field entry does not decrease: the operator still checks every field.

The one who pays for this is not the data entry department but reconciliation. A lost line does not block acceptance — it surfaces later, when the act has been signed and the discrepancy has to be explained.

Per-document accuracy shows nothing here: a receipt with forty line items goes entirely to manual correction, even though thirty-nine lines were read correctly.

Below we break down how this is closed — by field-level control, not document-level control.

What changes after implementation: accuracy, speed, control

The first shift is visible at the input: document entry automation removes routine sorting from the operator — the flow is processed in batches, and the time from scan upload to a finished record in the accounting system drops from minutes to seconds per document.

The bottleneck moves to where it should be: checking disputed cases, not manually transferring digits.

The second shift is the share of documents that go through the entire route without a single correction.

For standard receipts with a clean scan, this is about nine out of ten: line item fields, total, date, and number are matched against a reference schema, and the operator does not even open them.

The remainder — crumpled, overexposed, and rotated forms, unreadable font in line items — goes to a manual review queue with questionable fields highlighted.

The third shift is the nature of errors. What disappears is not “any errors” but specific classes: lost lines in long receipts, swapped line items with similar names, arithmetic mismatch between the sum of line items and the total.

The system catches and flags such discrepancies during parsing instead of quietly writing them to the database.

The fourth shift is manageability. The share of manual corrections becomes a metric visible by day and by supplier type: if recognition accuracy drops for a particular chain, it is noticeable before discrepancies accumulate in reporting.

The confidence threshold is configurable, so the flow can be run in strict mode or with extended auto-acceptance — for the specific risk.

Receipt recognition: templates, models, and hybrid schemes

Receipt data extraction is built in three ways, and the choice between them is determined not by the “advancement” of the technology but by the stability of the document supplier.

If a chain works with one or two types of cash register tape, a rigid template gives maximum speed and a predictable result; if suppliers and forms change every week, the template falls apart at the first layout change.

On a mixed flow, a hybrid scheme more often wins: the document first goes through inexpensive classification by geometry and anchor zones, and only receipts where the template did not provide confidence on key fields go to the model. This way, a mass homogeneous flow is processed without retraining for each new cash register.

The choice of processing mode is fixed in the configuration and does not require rewriting the parsing logic: a new template is connected separately from the model.

This makes it possible to start with the simple option, and as the number of suppliers grows, move to the model only the share of the flow where template confidence drops.

How we run implementation: from scan analysis to handover

We start recognition implementation not with configuration but with analyzing the input flow: scans of crumpled paper, photos taken at an angle, screenshots, exports from email and cash register programs.

Until the distribution of document types and fields is visible, any accuracy estimate is an estimate on convenient examples. That is why we structure the project stages so that the claimed result is confirmed on your test sample, not on demo receipts.

1. Sample audit: we collect 300–500 real documents, label fields manually, and fix a reference — the basis for subsequent accuracy checks.
2. Flow scheme: we determine where files come from, in what form data leaves for the accounting system, and what to do with duplicates and truncated fields.
3. Extraction setup: for standard layouts, we define field zones; for the rest — a supplier directory and reconciliation of the total with the sum of line items.
4. Measurement on the test sample: we calculate accuracy for each field separately — date, amount, number, details — otherwise the overall percentage masks a failure on an important field.
5. Confidence threshold: a field below the threshold goes to the operator together with an image fragment, rather than silently entering the database.
6. Pilot operation: for several weeks the system runs in parallel with manual entry, we analyze discrepancies and fine-tune the rules.
7. Handover and support: we provide configurations, the flow scheme, error analysis regulations, and the procedure for additional training on new receipt types.

What you have on hand: artifacts and regulations

A receipt recognition project ends not with a demo but with the handover of a working loop: settings, schemes, rules, and documents according to which the system continues to live without its author. Below is what exactly is recorded in the handover package and why each item is needed by your team.

• Extraction configurations — sets of settings for each document type (cash register receipt, sales receipt, corporate receipt), confidence thresholds at which a field is considered recognized, and rules for parsing non-standard columns.
• Document processing scheme — a step-by-step route: file intake, image preparation, field extraction, validation, export to the accounting system. With failure points and what happens to the receipt at each of them.
• Field validation rules — reconciliation of the sum of line items with the total, TIN check digits, correspondence between tax rate and amount, rejection of dates outside the allowed period. It separately describes what the system rejects on its own and what goes to manual review.
• Directories and dictionaries — items, counterparties, tax rates, as well as the procedure for updating them: who enters a new item and how it enters parsing.
• Project documentation — description of parsing logic, known limitations, typical causes of accuracy drops, and the sequence of actions when they occur.
• Support regulations — who is responsible for the loop, within what timeframe they respond to a discrepancy in the export, and how a rule change is tested before release.
• Operator instructions — how to work with the manual review queue, which corrections are allowed, and how a correction returns to the settings and becomes part of the training set.

The package is written so that a new engineer or operator can understand the system without contacting us — this is the acceptance criterion, not a list of files in an archive.

Primary document flow: metrics before and after

The client is a wholesale company with distributed deliveries: about 12,000 primary documents per month arrived in accounting as photos and scans.

The operator entered fields manually, one document took 3–5 minutes, the queue accumulated by the end of the period, and month-end closing was delayed by several days.

Metrics before and after

What we changed: we configured routing by model confidence — low-confidence fields are not “guessed” but go to the operator with the questionable fragment highlighted.

This is how accuracy in the flow is achieved: the system honestly sends for review what it is unsure about, instead of silently substituting an incorrect value. Parsing results are stored in 1C, and reconciliation with suppliers is performed using the recognized fields.

What produced the effect

We separately configured quality control: every week we compare a random sample of recognized documents with the source files and record which form types are underperforming — corrections to extraction rules are made surgically, without retraining the entire pipeline. On flows with homogeneous supplier forms, the share of corrections drops to 3–4%.

Manual labor did not disappear but shifted: the operator handles only disputed documents instead of the entire flow. The queue at period closing is no longer the bottleneck — the bottleneck is now where it is visible and can be measured.

What to do if some documents are phone photos

Phone photos are a full-fledged input format, but not “as is.” There are four differences from a scan: uneven lighting with shadows and glare, geometric distortions due to tilt, sensor noise in low light, and motion blur.

A model trained on clean scans loses accuracy on such input not because of “poor vision” but because the image of the characters is physically different.

That is why image preprocessing precedes recognition. First we find the document boundaries and align it by four corners using a perspective transform — tilt no longer has an effect.

Then we assess sharpness: if the frame is so blurred that strokes have merged, it does not go into the pipeline but is immediately marked for re-shooting.

Next is local binarization by adaptive threshold: it preserves the shadow along the edge of the receipt where a global threshold “eats” half a line. Finally, we normalize contrast, and faded thermal paper reads almost like new.

After preprocessing, the photo approaches a scan in its properties, and the same logic then works as for documents from roller feeding.

Recognition robustness comes not from a single model but from structural parsing: first we find the expected field zones, then we recognize the field contents.

Where a value is checked formally — number, amount, date — validation and autocorrection of similar characters are enabled (zero and O, one and l, eight and B). An error that arithmetic catches does not need to be handed to a human.

The key technique is the confidence threshold. A field recognized with low confidence is not guessed: the fragment is highlighted and goes to the manual review queue as one item, not as the entire document.

That is why scan quality stops being a common multiplier — the auto-fill rate is calculated based on the outcome, and disputed frames are handled surgically.

In practice, the pipeline accepts JPEG, PNG, HEIC, and PDF scans, parses several receipts in one photo and images from cash registers of different manufacturers — from ATOL onward: their font size, print template, and line arrangement differ, and the parsing branch is selected by document geometry.

The only thing worth fixing in employee instructions is to photograph the receipt in full and not at a sharp angle: this is cheaper than restoring an unreadable frame manually.

Technical questions asked before the start

Before the start, engineering teams ask roughly the same questions: what will happen with new document types, how data access is arranged, how errors are analyzed, and whether coverage can be expanded in stages. Below are answers to the point, without generalities.

How do you get access to our data?

Processing can be deployed on your side, where the documents are stored, or only the dataset needed for launch can be taken. Personal data is cut at the input, before field extraction — only anonymized results go outside. Sample access rights are limited by the role of the service account.

How do you analyze recognition errors?

Every discrepancy goes to a log with the field, document, and schema version indicated. Therefore it is visible where accuracy is lost: on scan quality, on non-standard layout, or on a specific field. Using these cuts, we build a report and close the systemic cause, not a single case.

Can coverage be expanded in stages?

Yes, and this is the preferred path. We start with one document type and one intake channel, measure accuracy on a control sample verified manually, and only then connect the rest. This way, expansion relies on confirmed numbers, not assumptions.

Let’s discuss the task and come back with an estimate and plan

A conversation about implementing recognition starts not with a presentation but with materials. To come back with an estimate of the scope of work and a realistic implementation plan, rather than generalities, we need only the following set:

• a sample of receipts in original quality — 30–50 items, including crumpled, overexposed, and angled ones: they immediately show where the model loses fields;
• a list of fields to extract, marking which are critical (amount, VAT rate, date, document number) and which are desirable;
• a reference parse for 10–15 receipts from the same sample — manually verified values, with which we will compare the recognition result;
• a description of the data sink: where the result goes (accounting system, storage, table) and in what format it is expected;
• flow profile: how many documents per day on average and at peak, whether processing at the moment of scanning is needed or batch processing is acceptable;
• loop constraints: where data is allowed to be placed and who gets access to it.

Using these materials, we run a trial launch on the sample and show accuracy for each field separately, not a single averaged figure — this shows which field will need additional training.

Then we agree on the implementation plan: stages, quality control points, and the procedure for analyzing errors on your own documents. Describe the task and send the sample — we will come back with an estimate and plan.