Reading Delivery Notes: Where OCR Ends and Control… | ORKA

Reading Delivery Notes: Where OCR Ends and Control… | ORKA

AI delivery note reading can turn a document into structured data proposals. On its own, it does not confirm the quantity actually received or decide whether a delivery matches the purchase order. OCR quantity control begins after reading: by comparing the document, the order, the goods at receipt and the acceptance rules. An ERP posting should follow only after a responsible person or a clearly defined automated rule makes the decision.

A delivery note contains evidence to read, but it is not itself a receipt decision. In a goods-receipt process, it is useful to separate four actions:

OCR finds characters in a photograph, PDF or scan. AI delivery note reading can help separate fields, identify line items and propose a link to a purchase order. Acceptance control requires broader context: whether the goods actually arrived, whether the right item was delivered, whether the figure refers to pieces, kilograms or packages, and whether an open quantity remains for a later delivery.

When these jobs are combined into one unclear step, a reading error can easily become incorrect inventory, a supplier liability or a closed order. It is therefore useful to shape the process before choosing a tool. Business process screening can help document the actual documents, decisions and exceptions at receipt.

A structured record is not a replacement for the original. Each extraction proposal needs an available, readable copy of the delivery note or a reliable link to it. The person at receipt can then check a disputed line without searching again through email, paper files or scanned attachments.

For every line item, the system or working screen should clearly show:

A readable view reduces the risk of accepting a value that nobody has checked. It matters especially for handwritten changes, poor photographs, differing supplier formats and multi-page documents.

Item checking is more than comparing names. Names on a delivery note may be abbreviated, include a packaging designation or differ from an internal code. A more reliable approach is to define a checking sequence: supplier code, internal code, approved code mapping, then a manual decision when no reliable link exists.

The unit of measure needs a separate check. One carton is not necessarily one piece, and a kilogram is not always interchangeable with a litre or a package. Where the process uses unit conversions, the master-data owner should maintain the conversion rule and its version. A receiving clerk should not improvise a conversion while goods are being received.

Quantity should be compared against at least two sources:

The purchase order provides a third important context. It answers whether the received quantity was expected and how much remains open. A delivery note may show 40 pieces, physical receipt may show 38 pieces, and the purchase order may be for 100 pieces. Reading is not the decision here. The process should allow receipt of 38, recording of the shortage or discrepancy, and retention of the remaining 62 as an open quantity, in line with the organisation's business rules.

Consider a delivery note with two lines. The first shows 10 packages of material and the second shows 24 pieces of a spare part. The extraction correctly captures both values. At receipt, the team finds eight packages on the first line and 24 pieces on the second.

The responsible person should not alter the extracted document as though it stated eight packages. The document remains the source record. The control records receipt of eight, the reason for the difference and the decision on the next action. The ERP receipt reflects the physically accepted quantity, while the purchase order retains the open difference if the rules allow a later delivery. If the eight packages cannot pass quality or identity checking, those eight do not automatically become available inventory either.

This scenario shows why it is useful to distinguish fields for "extracted", "confirmed at receipt" and "posted in ERP". One value can be correct on the document but unsuitable for the business decision.

An automated flow is appropriate only for clearly bounded cases. For example, an organisation may consider an automated acceptance proposal when there is an unambiguous purchase-order link, the same unit of measure, a quantity within an approved rule and a readable source document. This is a process decision to test on your own data, not a general recommendation for every receipt.

The following exceptions should go to a responsible-person review:

NIST's AI Risk Management Framework provides a framework for managing AI risks. It does not establish the accuracy of a specific OCR or AI system in your process. For that reason, teams need to track actual exceptions, review incorrect links and revise rules when documents, suppliers or master data change.

Before putting the process into operation, record the following elements and their owners.

Inputs and data ownership

Decisions and responsibility

For each exception, define the sequence: stop acceptance, record the reason, assign an owner, resolve the decision and retain an audit trail with the document. Separate the operational discrepancy from the accounting decision. Goods receipt and invoice processing may use the same document, but they do not need the same owner or the same approval moment.

Acceptance criterion

Set a measurable criterion before production use: every ERP goods receipt must link to a readable source document, record a decision on the item, unit of measure and quantity, and mark an exception where a discrepancy exists. Track separately the share of records sent to review, incorrect links discovered later and exception-resolution time. Establish the baseline and target from your own document sample.

In ORKA's approach, official business transactions remain in ERP, while Orkasta: daily collaboration can support the work around decisions and exceptions, and Trueforce covers specialised engineering work where the process requires it. A useful first step is not selecting OCR. It is walking one real delivery note from input to posting: who reads it, who confirms it, what happens when there is a difference, and which record proves the decision.

Recommended articles