Extracting Data from Delivery Notes: Where Manual Entry Breaks Down
A scan or photo of a delivery note reaches accounting, and then the most expensive part of the process begins — manual entry of primary documents.
An operator reads the details from the image and transfers them into the accounting system: one document takes several minutes, and on period-closing days the flow grows severalfold, and the queue grows with it.
Errors in delivery note details almost never look like a gross typo. It is a swapped digit in an amount, a lost character in an account number, a date in the wrong format, a tax calculated from the wrong base.
Each such figure goes further down the chain — into an entry, into reporting, into a reconciliation report with the supplier.
The cost doesn't appear immediately: documents are delayed in posting because the discrepancy with the supplier's source document must first be found. Then — reversal, re-approval, correspondence, and a repeated request for a copy. The later an error surfaces, the more expensive it is to correct.
But the bottleneck in document processing is not the operator's speed, but the absence of a verifiable structure. Manual entry leaves no trace: it is unclear where a figure came from and what it was checked against.
Data extraction from delivery notes is built differently: a model marks fields on the page and recognizes text in them, values pass arithmetic and reference checks, and a person handles only lines with low confidence. Below — how this works on real flows and what happens to documents that fail validation.
What Automation of Primary Document Entry Provides
Previously, recognition amounted to character reading: the output was flat text, and the structure — columns, linking an amount to a line item, number and date — was restored by an operator.
Models such as LayoutLM parse a document as a whole: text, block coordinates, and its visual context. Details are already extracted as marked by fields — supplier, number, date, amount, tax rate.
At the output, automation of document entry changes two metrics.
The processing speed of a document set drops from minutes to seconds per side, and the share of documents without manual correction grows: standard delivery notes and acts from trusted suppliers pass the entire route without an operator. Non-standard forms and low-quality scans remain manual.
Recognition quality control is built not on trust in the model, but on rules. Each field receives a confidence score, and below the threshold the document goes to an operator together with the highlighted fragment.
In addition, checks are enabled: control tax amount by lines, total convergence, compliance of details with the contract and the counterparty directory.
The main class of failures was caused precisely by manual transfer of details — a swapped number, an amount discrepancy, a lost act. Because of them, the set did not pass reconciliation, and settlements stalled until clarification.
When fields are extracted and validated automatically, reducing downtime in settlements becomes a consequence: the document enters accounting on the day it arrives, and discrepancies surface during review, not at period closing.
Processing Modes: Batch, Streaming, and Hybrid
The document submission scheme is chosen not by novelty, but by the order in which documents arrive and the cost of delay.
If delivery notes and acts are generated in the accounting system in a steady flow, and a one-day discrepancy blocks no one, batch document processing removes unnecessary complexity.
If an invoice needs to be posted on the day it is received, recognition modes for acts and acceptance as they arrive are designed differently.
Comparison of Schemes
| Scheme | When it fits | Limitations |
|---|---|---|
| Batch processing | Documents are exported on a schedule, the flow is steady, the result is needed by the start of the next day | Disputed fields wait for review until the next pass; during an end-of-month spike the queue grows, and there is no same-day feedback |
| Streaming loading of delivery notes | Scans arrive as they come in — from an exchange folder, from suppliers, from email, and a response is needed within minutes | Peak hours require a resource reserve; a markup error spreads through the accounting system faster than it is noticed |
| Hybrid verification scheme | Both flow speed and quality control are needed: automatic parsing runs immediately, disputed items go to a person | A verification interface and a regulation are required — who closes the queue and by when |
In practice, the hybrid option is more often adopted: fields with high recognition confidence go into the accounting system automatically, the rest are collected into a confirmation queue, and processing does not stall because of one unreadable scan.
The confidence threshold is selected on your documents — by the share of fields that the system returns without corrections.
Implementation Stages: From Document Audit to Handover
Work proceeds from audit to handover, and each step has a verifiable result. This way the solution goes into operation without surprises on the first high-volume flow: accuracy is known in advance rather than discovered on the first day of operation.
-
Document flow audit. We look at which forms of delivery notes and acts arrive, from which channels, and which details are needed further. The output is a list of forms and fields with priority: what we extract automatically and what goes to a person for review.
-
Document routing scheme. We fix the route: receipt, recognition, field marking, verification, export to the accounting system, archive of the original. For each step we determine what happens on an error and where the document goes for manual review.
-
Setting up matching rules. We link fields to accounting system details — number, date, amount, counterparty, item nomenclature. We define normalization for different spellings and formats, as well as the confidence threshold below which a document does not pass automatically.
-
Testing on historical documents. We run the archive of previous periods and calculate the share of fields extracted without corrections and the share of documents that passed the entire cycle automatically. Real accuracy is visible before launch on a live flow.
-
Reviewing disputed cases. We look separately at where the scheme errs: weak scans, stamps over text, handwritten corrections, attachments. For each class we refine the rules or route it into the manual processing queue.
-
Putting the solution into operation and handover. We connect receipt from email and the accounting system, configure roles and the journal: for each document it is visible what the automation extracted and what the operator corrected. We hand over the configuration, rules, and instructions, and train employees.
Implementation Artifacts: Schemes, Rules, Regulations
Implementation does not end with a demo: you are left with a set of settings and documents according to which the solution lives without us. Below is what we hand over together with working processing.
It is this set that determines whether your team can maintain delivery note parsing independently or whether every new template will require us.
- Document route scheme — the entire path of a delivery note from the input channel to the archive: where recognition happens, where the document waits for an operator, by which condition it goes for additional review, and by which it is returned to the supplier.
- Form processing profiles — separate settings for each type of act, delivery note, and adjustment document: the list of extracted fields, mandatory details, and the confidence threshold at which a line is accepted without a person.
- Document access rules — roles, separation by department and counterparty, retention periods for commercial secrets and personal data, and logging of every opening and export.
- Operator instructions — what to do at low confidence, how to correct a field, how to mark an unfamiliar template, and where to look when amounts differ between the document and the order.
- Exception review regulation — failure classes (unreadable scan, non-standard form, discrepancy with the contract), the person responsible for each class, response time, and the procedure for returning a document to the automatic flow.
- Field and reference dictionary — mapping document details to your accounting system so that new suppliers do not break parsing.
- Control sample of documents — an anonymized set of examples with expected values: it is used to check the correctness of any change to a profile.
We arrange everything in your storage system, with versions and edit history, so that handover does not turn into reconstruction from correspondence.
Procurement Case: Processing Times Before and After Implementation
Let's examine a case of delivery note processing in the supplier settlements area. This is a flow of primary documents from several hundred counterparties, each with its own template, column order, and formatting — around 12,000 documents per month passed through operators.
Before Implementation
Each document was entered into the accounting system manually: details were checked against the contract, amounts and tax rate were verified, and discrepancies were searched for by eye.
One document took 6–8 minutes, and by period closing the flow doubled — the queue was cleared with overtime.
Entry errors surfaced already at reconciliation, when a discrepancy with the supplier's source document had to be resolved with the counterparty and the correction returned to accounting again.
After: Control by Exceptions
Detail extraction was moved to a machine learning model: LayoutLM parses the document structure, and a set of validation rules works on top — amount convergence, contract compliance, item nomenclature, and prices from the reference dictionary.
Documents with confident parsing go into accounting without human involvement, the rest enter an exception queue with the problematic field highlighted, and the operator handles only those.
The processing time for one document dropped from several hours to minutes, and a batch is closed on the day it arrives.
The share of manual corrections fell from 18% to 3%, discrepancies with the supplier's source document are caught at input rather than at period reconciliation.
The load on operators shifted from entry to exception control: the same volume is closed by the area with three people instead of eight.
How to Check the Quality of Extracted Data Before Launch?
We compare not "whether the document was recognized or not," but each field separately: TIN, number, date, amount excluding tax, total, item name.
Values are normalized before comparison, so "1 234,56" and "1234.56" are the same, and the metric does not lie where the system is right.
We calculate accuracy by details as the share of fully correct values for each field, not the average per document. The average hides skew: dates read perfectly, while item numbers in tables drift.
The sample for verification is collected in a stratified way: by suppliers, forms with and without tables, scans and source files, documents with stamps over text.
We select rare groups manually — one non-standard form per thousand documents will not fall into a random sample, yet it is exactly what breaks extraction.
On non-standard forms, the nature of the error matters, not only its frequency. An empty field where a detail is absent is normal behavior; a plausible substitution of an amount from a neighboring line is more dangerous because it passes spot checks.
We fix the rule in advance: when uncertain, the system leaves the field empty and flags the document.
The confidence threshold is the regulator between the share of manual work and the risk of missing an error: we build the relationship of how many documents go for review and how many errors remain in accepted ones at a given threshold.
We set it by field, not with one value for everything: strict for amount and TIN, looser for item name. Then routing rules are refined on the live flow, not on a held-out sample.
Recognition Limitations and Common Technical Questions
Some documents are more honestly left to a person, and we say this before the start. Handwritten notes over a printed form, corrections, and signatures in fields are read unstably by a model such as LayoutLM — an error here costs more than manual entry.
Arbitrary forms without a repeating structure are also outside automation: if the supplier sends a new layout each time, the detail zones are not fixed and accuracy drops from batch to batch.
A separate limitation is source quality. A skewed sheet, a shadow along the edge, scanning a copy of a copy, a cropped field with the amount: the result rests not on the model but on image preparation — alignment, background trimming, sheet boundary detection.
If a person cannot read the scan, automation is not obliged to pull it out: such sheets go into the manual review queue, not into the accounting system.
What to do with documents we do not take into automation?
They do not block the flow: a review rule marks the sheet as "manual processing" and sends it along the usual route. Automation covers the bulk of similar delivery notes, and exceptions remain exceptions rather than stretching across the entire volume.
How does connection to the accounting system work?
Through standard exchange: a software interface or file exchange if the system is closed.
The key is idempotency: re-uploading the same document does not create a second record, and matching of counterparties and item nomenclature goes through the reference dictionary so that one supplier does not appear in three spellings.
Who is responsible for an error in details?
Fields with low confidence are not posted automatically but go to an operator for confirmation — amount, number, and date are always under control.
We are responsible for the correctness of extraction and the integrity of fields; the customer is responsible for posting the document. The journal stores what the model returned and what the person confirmed, so a disputed case is reviewed step by step.
Let's Discuss the Task: Document Volume, Sources, Roles
To make recognition assessment rely on facts, not assumptions, we need inputs on your document flow.
Below is the list of what we clarify first: from it, it becomes clear which fields are actually extracted automatically, where rule-based verification is sufficient, and where the document should go to a person with a hint.
- Types of incoming documents: delivery notes, acts, invoices, specifications, transport documents — and in what form they arrive: scans, photos from a phone, electronic forms from suppliers.
- Receipt channels: email, network folder, scanner, supplier portal, messenger. We separately note where a document enters circulation through manual entry.
- Target fields and reconciliation rules: exactly what needs to be extracted from the document — line items, quantities, amounts, taxes, party details — and how correctness is checked now.
- Accounting system and transfer method: where the data should go, whether the system has a software interface or exchange goes through files and manual loading.
- Approver roles: who checks the recognized data, who confirms, at which discrepancies the document goes to manual review, and who closes it.
- Current work procedure: how much time one document takes, what share requires corrections, and on which fields errors most often occur.
- Constraints: requirements for storage, access, and processing of personal data, as well as where processing is allowed to be hosted.
Based on these answers, we assemble a prototype on your documents, measure accuracy by fields, and propose an integration scheme. Describe the task in a convenient form — we will return with an estimate, a work plan, and acceptance criteria.
