Delivery Note Data Capture 2026 — When Paper and Goods Split

A delivery note arrives on the factory floor together with the goods. The moment the receiving clerk signs it, though, the paper alone travels to the back office while the goods alone go onto the rack. The two flows meet again at month end, when the invoice lands, and by then nobody can recount what was in the box. Delivery note data capture is the work of tying those two flows back into one during the single minute the shipment is handed over. This article sets out how to design that process around the conditions that are specific to a receiving dock in Thailand.

Why delivery note data capture is a different problem from invoice data capture

When document automation comes up, invoices are almost always the first subject. The amount is fixed, there is an approval route, and there is a deadline in the form of the payment date. It is an easy place to start. Carry the same thinking across to delivery notes, however, and the design comes out skewed, because where the document arrives and why you read it are both different.

Delivery notes arrive with the goods, on the floor, not in the back office

An invoice arrives by post at the general affairs desk, or by email in an accounts payable inbox. The person receiving it is sitting down. If something is unclear they can telephone the sender, forward it to a colleague, or pick it up again tomorrow.

A delivery note is different. The driver who has just climbed out of the truck hands it over along with the goods. The person receiving it is standing up. They may be wearing gloves, and it may be 35 degrees outside. They are in the middle of unloading, and there may be a second truck waiting behind the first. There is no option here to pick it up again tomorrow. The driver leaves as soon as the signature is given, and the truck has to be clear of the gate.

That physical difference translates directly into a design constraint. In invoice automation you can assume there will be time for a person to review and correct the extracted result. On a receiving dock you cannot put that time at the counter. What the counter can absorb is a check of a few seconds up to about a minute, and any design that asks for more than that stops being used.

What you can verify at receipt is not what you can verify at payment

The second difference is what there is to verify. At receipt the goods are physically in front of you. Open the box and you can read the part number, you can count the pieces, and you can see it if the outer packaging is crushed. By the time the invoice arrives at month end, those goods are at the back of a rack, or have already been issued to a process and become part of a product.

In other words, there are things that can only be verified at the moment of receipt. What actually arrived, and how many. That is something you learn by looking at the physical goods, not at the figures printed on a sheet of paper. Equally, there are things that can only be verified at the moment of payment. Differences against the contracted unit price, whether a discount was applied, how withholding tax has been handled, whether the terms of payment line up. Those calls require data that sits with accounting.

Delivery note capture and invoice capture are therefore not competing initiatives. They are two checkpoints at different points in time. We have set out the design on the payment side in Invoice Processing Automation 2026 — reshaping accounting at a Thai plant with AI-OCR, which is worth reading alongside this piece. This article deals with what happens before that, in the moment the goods pass through the gate.

In three-way matching, only the delivery note carries eyes-on evidence

Accounting practice has a term for this set of checks, three-way matching, the procedure of reconciling three documents — the purchase order, the delivery note or goods receipt, and the invoice. Comparing only the invoice against the purchase order is called two-way matching. The difference is not about how many pieces of paper are involved, it is about what can be verified once the delivery note is in the set.

The purchase order shows what you asked for, and the invoice shows what the supplier has billed you for. Comparing those two alone tells you nothing about whether anything actually arrived. It only tells you that what was ordered is what is being charged. It is the delivery note that pins down the one remaining fact, namely that this much was actually delivered.

Of the three documents, the delivery note is the only one that directly reflects a human being looking at the physical goods. The purchase order is created before the order is placed, and the invoice after the shipment has gone out. Only the delivery note is present in the window of time when the goods were physically there. That is exactly why, unless it is turned into data at that moment, information is lost that cannot be reconstructed later.

Matching the physical goods themselves with barcodes or RFID is a separate design question. We cover the goods side in Shipping and Receiving Inspection System 2026 — designing the match that stops misdeliveries, so please refer to that article for it. This one digs into the paperwork side only.

In Thailand the delivery note is usually a combined delivery note and tax invoice

From here on we are on ground that is specific to Thailand. This is the first place where experience brought over unchanged from Japan trips people up.

The tax point falls at delivery for goods

Under Thai VAT practice, for the sale of goods, meaning tangible items, the tax point falls in principle at the point of delivery. If ownership transfers, payment is received, or a tax invoice is issued before that, the earliest of those becomes the trigger instead. Put the other way round, in an ordinary credit transaction where goods are simply delivered in the normal way, the trigger is delivery.

Seen from the seller’s side, that means issuing the tax invoice on the day of delivery is the most straightforward way to run things. And once that is true, there is no longer any reason to keep two separate documents. If the same content goes to the same customer at the same time, one sheet is quicker. In practice, Thai localizations of accounting systems ship with a “Delivery Note / Tax Invoice” form, and issuing a single combined document is widespread. That is why the paper arriving at your dock carries both ใบส่งของ / ใบกำกับภาษี side by side.

To a Japanese sensibility, a delivery note is a communication about the transaction and the document that matters for tax purposes is the invoice that follows later. In Thailand that assumption does not always hold, because the paper that reached your receiving dock is already the tax document.

The paper that arrives on the floor is itself the input VAT credit document

That difference changes how the receiving counter has to be run. A combined delivery note and tax invoice is evidence that stock has come in, and at the same time it is the evidence you need in order to claim the input VAT credit.

If that sheet is taken in an oil-stained hand, left clipped to a clipboard until the evening, rained on, and then torn because a carton was set down on top of it, what is lost is not a memo about what arrived today. It is the basis for a tax credit. You may think you can simply ask for a reissue, but the supplier’s accounting team has already processed the document as their own sale, and a reissue takes a fair amount of effort and time. Sometimes it does not arrive in time for the monthly close.

On a Thai receiving dock, therefore, shortening the time between the paper being handed over and the paper reaching somewhere safe has value in its own right. The purpose of data capture is not only to cut clerical hours. If the image is fixed at the place where the paper was received, the basis for the credit survives even if the original later gets dirty. Physical retention of the original is still required, but the risk of losing the information drops.

The Japanese habit of keeping a copy on the floor does not transfer as it is

At a Japanese plant it is common to file the delivery note copy in a binder at the receiving area and send the whole batch to accounting at month end. It has the advantage of letting the floor check what arrived last week without leaving the area.

Do the same thing in Thailand and tax documents sit on the shop floor for weeks at a time. What tends to happen is that accounting goes round to collect them at month end and finds several missing. Somebody pulled one out to query it and did not put it back, another department took some away, or a sheet was simply filed in the wrong place. None of it is done in bad faith, but the result is that the basis for the credit is not complete in time.

The realistic way to solve this is to consolidate physical retention on the accounting side while making the information the floor wants to look at available as data. Scan the paper immediately after it is received and send it to accounting, and let the floor check past deliveries on screen. Arranged that way, you stop originals going astray without taking anything away from the floor. Data capture takes hold better when it is considered together with this change in operating practice.

The Japanese electronic bookkeeping rules and Thailand’s own e-Tax Invoice scheme have their own scope and requirements, and they are beyond what this article covers. Here it is enough to hold on to one point — the paper that arrives on your floor carries tax significance.

Form OCR extraction fields are settled by the statutory mandatory particulars

When you build an OCR template, the first thing to decide is which fields to read. For invoice OCR that discussion tends to run long. For a Thai combined delivery note and tax invoice you can cut it short, because the backbone of what has to be read is settled on the legal side.

What Section 86/4 requires

Section 86/4 of the Thai Revenue Code prescribes the particulars that a tax invoice must contain. According to the text published on the Revenue Department’s English site, the following items are required.

• The word indicating that the document is a tax invoice, ใบกำกับภาษี
• The name, address and taxpayer identification number of the issuer, being the registered operator
• The name and address of the purchaser
• The serial number, and the number of the book if applicable
• The description, type, quantity and value of the goods
• The amount of VAT, shown separately from the value
• The date of issue
• Such other particulars as the Director-General prescribes

What stands out about this list is that there is almost nothing left to decide on business grounds about which fields to read. The statutory mandatory particulars are the backbone of the extraction schema. Suppliers may use different layouts, but the categories of information carried on the document are common to all of them. That is an advantage which general invoice OCR design does not have.

Statutory fields alone will not run the operation, of course. In practice you will also want to read the PO number, lot numbers, the carrier and vehicle number, and the name of the person who received the goods. Typical extraction fields cited for delivery note OCR include the item description, delivered quantity, delivery date, carrier and driver information, the receiver’s name and signature, condition notes, reference numbers such as PO and BOL numbers, and the shipper and consignee addresses. Taking the statutory fields as the backbone and adding these on top as business requirements is the order that moves the design along fastest.

Separate header fields from line item fields

When you lay out the extraction fields, keep header and line items apart. They differ in how hard they are to read, in what they are matched against, and in what happens when they are wrong.

One published breakdown of packing slip extraction fields lists, as header fields, the document number, ship date, shipper name, consignee name, order number, carrier and tracking number, total weight and number of packages, and as line item fields the item description, SKU or part number, shipped quantity, unit weight or dimensions, lot number and serial number. The same split works unchanged on a combined delivery note and tax invoice.

There is only one set of header fields per sheet, and their position is stable. Layouts differ between suppliers, but for the same supplier they are in the same place every time. Line items, on the other hand, vary in count. Some documents have 1 line, some have 20. The model used in this article assumes an average of six lines, but the real figure swings widely with what is being bought. The more lines there are, the higher the risk of segmenting them incorrectly.

Something that works well in practice is a self-check that reconciles the line item total against the header total. Recompute the amount from the extracted quantities and unit prices and see whether it matches the total printed on the document. When it does not, the likely causes are a dropped line or a misread digit. VAT can be checked the same way, comparing the figure recomputed from the net amount against the separately stated amount on the document. Because separate statement is a statutory requirement, the numbers you need for that cross-check are already on the paper.

Table — extraction fields and what each is matched against

Each extracted field is matched against something different. Unless you decide up front what each one is reconciled with, the captured data simply accumulates without being used.

The column to look at is the one on the right. Two entries that both say “mismatch” can mean entirely different things. A serial number mismatch suggests double counting and is an accounting problem. A quantity mismatch means over-delivery or a shortfall and is a shop floor problem. That distinction is what feeds into the question of who stops what and where, which we come to below.

Paper photographed on the floor is not paper scanned in the office

When OCR is being evaluated, accuracy is checked against sample images. If those samples were captured on the flatbed scanner in the accounting office, you will misjudge how the system performs at a receiving counter.

Carbon copies are poor material for capture

Delivery note cum tax invoices in Thailand are still frequently issued as multipart sets. It matters which sheet is the original. The original of the tax invoice goes to the buyer, because that is the sheet the input tax claim rests on, and the seller retains a copy. The remaining sheets serve as the delivery copy and as the copy left at the receiving point. The problem is that without a rule, what the counter photographs tends to be the signed sheet that stayed in its own hands rather than the original, and the characters on a copy were produced by transfer through carbon or carbonless paper.

Transferred characters have lower contrast than printed ones, the lines bleed, and anywhere the writer pressed lightly the marks fade. On documents where quantities have been written in by hand, those parts become harder still. The paper stock itself is often not white but a pale pink or yellow. These conditions are quite different from the ones a capture pipeline tuned for a printed invoice on white paper was built for.

The remedy is simple. Collect real samples supplier by supplier. Run 10 to 20 sheets exactly as they arrived at the receiving counter and the gap between your desk-based assumptions and reality shows up immediately. On that basis you can decide how far to go with background colour removal and contrast correction. Skip this and you will be rebuilding templates after go-live.

Creases, dirt and overlapping stamps

Paper that arrives on the floor carries marks that office paper does not. Creases and ridges from being written on top of a carton, oil and dirt picked up during unloading, damp on a rainy day, and stamps.

Stamps are particularly awkward. A supplier’s company stamp or a staff member’s personal seal is sometimes pressed over the item description or quantity column. A human eye can infer the characters underneath the impression, but the capture engine treats the overlapped area as broken characters. If you have your own practice of stamping a receipt mark, it is worth checking whether its position overlaps an extraction field. Moving where the stamp goes by a few centimetres genuinely solves the problem in some cases.

For creases, taking a moment to flatten the paper before capture is effective. Simply clipping it to a board or a clear sheet changes how shadows fall. Improvements available at the level of an operating rule like this are more efficient to tackle before you start adjusting the system.

Decide where and when the capture happens

Operating conditions determine the outcome more than technical ones do. Decide first who captures the document, where, and when.

There are three options. Putting a fixed capture stand and terminal at the receiving counter and capturing immediately after the receipt signature gives the best image quality because lighting is stable, and it lets the result be checked on the spot. Capturing with a handheld terminal or a smartphone requires much less capital outlay, at the cost of variation from camera shake, oblique angles and backlighting. Collecting the paper and scanning it in a batch in the office gives stable image quality, but leaves the time lag between receipt and entry intact, which means the split between paper and goods that this article is about remains exactly where it was.

Which one to choose comes down to the physical layout of the site and the daily volume. If receiving is consolidated at a single door, a fixed capture stand is easier to sustain. If it is spread across several doors, a handheld terminal will hold up better as an operating practice.

Decide on the timing as well. If you try to complete corrections to the extracted result while the driver is waiting, the floor will start skipping the capture step altogether. What happens at the counter is the capture and a look at whether errors were flagged. Corrections belong downstream. That division of labour is the realistic one.

In purchase order OCR matching, what you decide is not the tolerance but who stops what, and where

The captured data is then reconciled against the purchase order data. The discussion that tends to drag on here is what tolerance to set. In practice the more important design question is who stops what, and where, when a discrepancy appears.

Quantity, item and price discrepancies get stopped in different places

Discrepancies come in types, and the types differ in whether they can be resolved on the spot. Treat them all the same way and either the floor comes to a halt or discrepancies pass through unnoticed.

A quantity discrepancy is one to confirm at the gate, on the floor. If the number ordered and the number delivered do not agree, right now, with the goods in front of you, is the only chance to verify it. Asking the driver will sometimes establish whether it is a short load or a scheduled partial delivery. Once the truck has left, you can neither recount nor return anything.

A price discrepancy is the opposite, a discrepancy that must not be stopped on the floor. Even if the unit price on the document differs from the order price, the receiving counter cannot resolve it. Notification of a price increase may be stuck somewhere between sales and purchasing, or it may simply be a clerical error on the document. Either way, the people who decide are purchasing and accounting. If the floor takes the line that the goods cannot be accepted because the price is wrong, the truck cannot clear the gate and the next delivery cannot come in. The goods themselves have arrived correctly, so this is a discrepancy to accept first and resolve afterwards.

An item discrepancy sits between the two. If the part number delivered differs from the order, it can be accepted where the item is an approved substitute, and if it is an outright misdelivery it is quicker to have the driver take it back. Making that call requires an item master and registered substitutes. Trying to automate this without a maintained master produces a stream of exceptions.

Three patterns — over-delivery, shortfall, substitute item

Splitting quantity and item discrepancies into three patterns, from the point of view of how the floor handles them, makes the operating rules much easier to write.

Over-delivery is the state where more arrived than was ordered. Accepting it increases both stock and liability, but some items unavoidably leave a remainder because of packaging units, and sometimes the supplier is simply bringing the next batch early. What the floor should do is not decide whether to accept or return, but record the fact of the over-delivery and escalate it to purchasing.

A shortfall is the state where less arrived than was ordered. What you want to establish is whether this is a partial delivery in progress or a short load. If it is a partial delivery, the balance stays under management as an open order quantity. If it is a short load, you can sometimes ask the driver on the spot when the rest is coming. If a shortfall is not recorded at the point of goods receipt, it surfaces for the first time when the invoice is reconciled at month end, and by then nobody remembers the circumstances.

A substitute item is the state where something other than the part number ordered has arrived as an equivalent. This is the most dangerous of the three. If it is booked in under the wrong part number, the inventory data says the ordered item never arrived while the physical goods are sitting on the rack, and that can go undetected until a stock count. Because acceptance sometimes requires a judgement from the engineering department, it is safer not to design this to pass automatically on the floor.

Table — discrepancy types and where to stop them

The following table pulls all of the above together from the point of view of where each discrepancy is stopped.

Build this table at a level of detail that lets you post it on the wall of the receiving area as it stands. Whether or not there is a single sheet for a receiving clerk to consult when they are unsure makes a real difference to how stable the operation is.

How far goods receipt automation actually goes

When you set the scope of automation, starting from how much can be automated leaves you with no natural stopping point. Starting from where a person takes over settles the design faster.

Write the auto-pass conditions out in prose first

Before you open a configuration screen, write out the conditions for passing a document automatically as plain sentences. They will look something like this.

• The PO number can be read, and exactly one valid purchase order can be identified from it
• Every part number on the line items matches a line on the purchase order
• The quantity on each line item is no greater than the open order quantity
• The issuer’s taxpayer identification number matches the supplier master
• The total recomputed from the line items matches the total printed on the document
• The serial number does not already exist in the past receipt records

Only documents that satisfy all six pass automatically, and anything that fails even one goes to a person for review. Set up this way, if the touchless rate after go-live comes in lower than expected, you can count which condition is causing the failures. Without conditions written out in sentences you end up with only a vague sense that documents are not passing, and no way to improve anything.

Decide where exceptions land before you go live

The part of an automation design most often left out is where the exceptions go. Whose screen do the documents that did not pass automatically pile up on? Who looks at that screen, and when? Whom do they escalate to when they cannot make the call?

In the model used in this article, 30% of the 900 documents a month, meaning 270 documents, go to exception handling. That is 12 or 13 a day. Go live without deciding who processes them and a backlog builds up, and in the end everyone goes back to manual entry. In practice, routing by type works well. Quantity and item discrepancies go to purchasing, document defects go to accounting, and outright capture failures go to the data entry team. Splitting the queue three ways like this is enough on its own to reduce the backlog.

On the exception handling screen it matters a great deal that the source image can be displayed alongside the data. Whether the operator is correcting numbers in isolation or correcting them while looking at the relevant part of the paper changes the processing speed.

Do not automate the receiving signature

There is one last thing to decide not to automate. That is the receiving signature.

The receiving signature is the act by which one of your own staff states that they have indeed received this shipment. Omit it, or have the system perform it on their behalf, and when a dispute arises later you will not be able to explain who checked what. Replacing it with an electronic signature is not a problem in itself, but even then keep it in a form where a person looked and a person approved, and the record shows it. Automating the capture and deciding where responsibility sits are two separate matters.

Two decisions for the WMS and inventory system integration

When it comes to passing the captured data to the inventory system, two issues surface. Neither is technical. Both are decisions about how the business is run.

When to post the receipt into inventory

The first is when stock is increased.

Under the approach that posts at the point of receipt, stock increases the moment the capture passes. Inventory data catches up with the physical goods quickly, and enquiries from production along the lines of “it should have arrived by now” become less frequent. On the other hand, anything that later fails inspection or gets sent back has been added to stock in the meantime.

Under the approach that posts on completion of goods receipt inspection, stock increases only after incoming inspection and quantity confirmation are finished. Accuracy improves, but there is now a window during which the goods are physically on site while the inventory data says they do not exist, and if that window is long, production is kept waiting.

Neither is inherently right, and splitting the rule by the nature of the item is the practical answer. Items requiring incoming inspection are posted on completion of inspection, general-purpose materials with no inspection are posted at receipt, and so on. Go live without settling this and you will not be able to tell whether a stock discrepancy is caused by a timing difference or by an actual error.

Hold a pending inspection status for stock

The second issue holds the key to the first. The second is to make it possible to hold pending inspection as a status on stock.

Pending inspection stock is stock that is on site, whose location and quantity are both known, but which has not yet been cleared for use. Once you can hold this status you can run an operation that posts at the point of receipt while keeping the stock unavailable for allocation by production. Items with a discrepancy, goods that arrived as substitutes, and anything with visible damage are quarantined in this state.

Where the system has no such status, the floor substitutes for it by putting the goods in a physically separate place. There is nothing wrong with that in itself, but the rule breaks down once that space fills up. If you can hold the status in the data, that is the more stable arrangement.

Location management and allocation rules on the warehouse side are covered in Inbound and Outbound Management System 2026 — designing a warehouse that does not stop a Thai plant. Delivery note data capture plays the role of feeding information into the front end of that.

AI-OCR implementation cost and payback, as a model calculation

The figures from here on are a model based on assumptions we have set in order to show the shape of the calculation. They are neither an actual quotation nor the recorded results of a real site. Please read them separately from everything above.

Setting the assumptions

Picture a single site of a Japanese manufacturer in Thailand. It buys parts from 40 suppliers and receives 900 delivery notes a month. On 22 working days that is roughly 41 a day, and we assume an average of six line items per document.

Today, the receiving clerk counts the goods, signs the paper, and sends the paper to the back office, where a member of staff reconciles it against the purchase order data and keys it into the core system. Putting that at 8 minutes per document, 900 documents a month comes to 7,200 minutes, or 120 hours. We assume a fully loaded clerical labour cost of 250 THB per hour.

After deployment we assume a touchless rate — the proportion of documents passing automatically — of 70%. A document that passes automatically takes 1 minute, since it involves only the capture and a look at the result, and a document that goes to exception handling takes 6 minutes, since it is reviewed and corrected on screen. With 630 documents at 1 minute and 270 at 6 minutes, that is 630 minutes plus 1,620 minutes, so 2,250 minutes in total, or 37.5 hours.

The time saved is 120 hours less 37.5 hours, which is 82.5 hours. Converted to money, 82.5 hours at 250 THB gives 20,625 THB a month, and 247,500 THB a year.

The second effect concerns incorrect goods receipts. Assume that at present six incorrect receipts a month arise from quantities or items being confused on delivery notes. We assume a recovery cost per incident, covering the stock investigation, the reorder and the waiting time on the production side, of 4,500 THB. If matching at the point of receipt reduces this by 60%, that is 3.6 incidents a month avoided, worth 16,200 THB a month and 194,400 THB a year.

Table — the five cost layers

Costs are split into five layers. The reason for splitting them is so that you can verify afterwards which layers are contributing to the benefits and which are not.

That gives 620,000 THB initial and 270,000 THB annually. The point worth noting is that development in layer 4 accounts for roughly six-tenths of the initial cost. Reconciling against purchase order data and integrating with the inventory system come to more, in money terms, than the capture itself in layers 1 and 2. That distribution is the reason this article takes business process design rather than product selection as its subject. Comparison of the products themselves is covered in AI-OCR Comparison 2026 — how to choose a product that works at a Thai plant, so please use that article to build a shortlist.

Table — the benefits

There are two benefits, the reduction in clerical hours and the reduction in the recovery cost of incorrect goods receipts.

There is something worth emphasising here. Count only the labour saving and this investment does not pay back. The annual benefit from reduced clerical hours is 247,500 THB against an annual cost of 270,000 THB, so on that basis alone it is a loss. Where matching at the point of receipt really earns its keep is on the recovery cost of incorrect goods receipts, and only once you count that does the investment stand up.

Working out the payback period

The annual net benefit is the total benefit of 441,900 THB less the annual cost of 270,000 THB, which is 171,900 THB. Dividing the initial investment of 620,000 THB by 171,900 THB gives a simple payback period of 3.6 years.

As capital expenditure goes that is on the long side, and this is not a project that pays back inside three years. That said, there are benefits not included in the calculation, as noted below, and at a site that can expect a reduction in incorrect receipts higher than 60% the payback shortens. Conversely, at a site where incorrect receipts barely occur today, this investment does not pay back. Before you evaluate it, we suggest counting how many incorrect goods receipts you had over the past year.

What happens when the touchless rate moves

The touchless rate is the most volatile variable in this calculation. Depending on how consistent your suppliers’ formats are, how well your masters are maintained and how thoroughly the templates are built, it can land anywhere between 50% and 90%.

What to be careful about is that the touchless rate affects only the labour saving. Do not apply it to the reduction in incorrect goods receipts. The matching itself is performed even on documents that go to exception handling. Indeed, the fact that a document did not pass automatically means a discrepancy was detected, which from the point of view of preventing incorrect receipts is the mechanism working. Apply a single blanket factor across both and the conclusion changes.

The 50% row is 450 documents at 1 minute and 450 at 6 minutes, giving 3,150 minutes, or 52.5 hours. The 90% row is 810 documents at 1 minute and 90 at 6 minutes, giving 1,350 minutes, or 22.5 hours. The incorrect receipt benefit stays at 194,400 THB across all three rows.

What to take from the table is that even as the touchless rate moves from 50% to 90%, the payback period stays within a band of 4.9 years to 2.9 years. It does not vary by a factor of two, because the incorrect receipt benefit underpins it. Which also means that at a site where no incorrect receipt benefit can be expected, the payback period lengthens however high you push the touchless rate.

Benefits you should not add to this calculation

It is tempting to stack up benefits in an investment paper, but do not add the following three. Add them and you will not be able to explain them later.

• Reduction in the value of inventory itself. Delivery note data capture does not reduce stock. Unless the way you place orders changes, the quantity arriving is the same
• Cash flow benefit from a shorter payment cycle. This depends on how the payment side is designed, so keep it in a separate account from this calculation
• Stock discrepancies other than incorrect receipts. Stock count errors and mix-ups at issue are not prevented by matching at receipt, so they are outside the scope of this article

One further note. There is a vendor-published worked example that takes invoice processing at 200 documents a month and shows 12 minutes per document falling to 1.5 minutes. That is a worked example for invoices, not a figure for delivery notes. It is a different thing from the model calculation in this article, so please take care not to mix the two.

How to proceed — four steps

Once the design thinking is settled, the order of execution follows. Delivery note data capture changes a good deal of how the floor works, so getting the order wrong means it never takes hold.

Step 1 — collect the actual documents and classify them

The first thing to do is not to evaluate systems but to collect paper. Take the last month of delivery notes and lay them out sorted by supplier. With 40 suppliers you get 40 piles.

There are three things to look at. The first is the variation in format, which can differ between branches of the same supplier. The second is whether the documents are multipart sets, so count how many carbon copies you are dealing with. The third is the skew in volume. Counting sheets by supplier usually shows the volume concentrated in a handful of them, and template work starts with those.

Step 2 — count what actually went wrong

Next, count what actually happened at receiving over the past year. How many quantity discrepancies, how many item discrepancies, how many of those turned into incorrect goods receipts, and what the recovery cost was.

This exercise sets both the numerator and the denominator of your investment case. The model in the previous section assumed six incorrect receipts a month at a recovery cost of 4,500 THB each, but this varies enormously between sites. Take a vendor’s calculation at face value without counting your own record and you end up with a conversation after go-live about the benefits not showing up.

Step 3 — settle the stopping rules on a single sheet of paper

Put the discrepancy types, where each is stopped and which department decides onto a single sheet. The table in the earlier section is the template. Read that sheet through together with purchasing, accounting, quality assurance and the receiving floor, and get all four to agree to it.

Skip this step and build the system first, and after go-live the argument about who handles which discrepancy starts in front of a growing pile of exceptions. Settle the rules first, then transcribe them into the system. Keep to that order.

Step 4 — roll out gradually, starting with the highest-volume suppliers

Do not bring all 40 suppliers up at once. Build templates for the top 10 first and start running within that scope. After one or two months of operation the actual touchless rate, the content of the exceptions and the problems with the capture routine all become visible.

Add the rest gradually on the strength of that. For suppliers whose format is unusual and whose capture will not stabilise, deciding not to force automation, and instead either asking them to change the format or leaving those documents on manual entry, is a legitimate option. Automating every document is not the objective.

Common failure patterns

These are the patterns we have seen where delivery note data capture does not work out.

Evaluating capture accuracy and leaving the matching until later

This is the most common shape of failure. Accuracy is checked in a demo, it looks good, and the decision to buy is made. But the part that reconciles the captured data against purchase order data has not been designed, and in the end people are matching in a spreadsheet. As the five cost layers showed, matching and integration account for the larger share both in money and in effort. Reverse the order of evaluation.

Not testing with paper that arrived on the floor

Accuracy is assessed on clean samples captured with the accounting department’s scanner, and then the numbers do not materialise in production. Carbon copies, creases, dirt and overlapping stamps can only be checked on the real thing. Collect the paper from the receiving counter as it is, during the evaluation stage.

Going live without deciding where exceptions land

At a touchless rate of 70%, 270 of 900 documents a month go to exception handling. Go live without deciding where they go and documents accumulate in an exception list that, within a few months, nobody opens. Decide the routing by type, who reviews it, and how often, before you go live.

Asking the floor to make judgements about price

Design every discrepancy to be stopped on the floor and a price discrepancy leaves the truck waiting. A delay of a few minutes propagates to every delivery that day. Hold the line that the only things stopped on the floor are discrepancies concerning the physical goods.

Writing the investment case on labour saving alone

As the model calculation showed, the reduction in clerical hours alone comes in below the annual cost. Write the case that way and it either does not get approved, or it gets approved and then attracts the complaint after go-live that the benefits are not there. Count the recovery cost of incorrect goods receipts, which is the part that only matching at receipt addresses.

Trying to automate the receiving signature as well

Carried along by the momentum of the efficiency drive, teams hand the act of approving the receipt to the machine as well. When a dispute arises later, you cannot explain who checked what. Keep two things separate — the automation of the capture, and the question of where responsibility sits.

Frequently asked questions

How is delivery note data capture different from invoice data capture

The place the document arrives and what there is to verify are both different. An invoice arrives in the back office and is used for judgements at the point of payment. A delivery note arrives on the floor with the goods, and it fixes the information that exists nowhere else, namely what actually arrived and how much. That information cannot be reconstructed at month end. The central design question is therefore how to use the few dozen seconds available at the receiving counter.

How accurate does form OCR need to be

It depends on the field, which is the practical answer. Fields such as quantity and part number, which are matched against the physical goods, are judged strictly, because a misread leads directly to an incorrect goods receipt. Fields such as the carrier name or a condition note do not stop the operation if they are slightly wrong. Rather than setting one target across every field, it is more realistic to work out for each field what happens if it is wrong, and to vary the need for review accordingly.

Can Thai delivery notes be handled the same way as Japanese ones

Sometimes they cannot. In Thailand the tax point for the sale of goods falls at delivery, so issuing the delivery note and the tax invoice on a single form is widely practised. Where that is the case, the paper arriving on your floor doubles as the input VAT credit document. Keeping copies in a file on the shop floor for weeks carries the risk of originals going astray.

How much of the purchase order OCR matching can be automated

The PO number is readable, the part numbers match the order lines, the quantities are no greater than the open order quantities, and the recomputed total agrees. Documents that satisfy all of those conditions can be passed automatically. The model in this article assumes that proportion is 70%. The actual figure is determined by how consistent your suppliers’ formats are and how well the item master is maintained, so we suggest starting with the highest-volume suppliers only and measuring the real rate.

Does goods receipt automation reduce the receiving clerk’s workload

The receiving clerk’s own work does not reduce by much, because the flow becomes counting the goods, signing, and capturing the document. What reduces is the downstream data entry, which in the model calculation falls from 120 hours a month to 37.5 hours, a saving of 82.5 hours. Explaining it to the floor as fewer questions coming back to them later, rather than as less work, is closer to the truth and makes cooperation easier to obtain.

How much does an AI-OCR implementation cost

It varies a great deal with the size of the site and the scope of integration with existing systems. The model in this article assumes 620,000 THB initial and 270,000 THB annually. The largest single element is the development of purchase order matching and WMS receipt integration, at roughly six-tenths of the initial cost. Judging by the capture licence fee alone will leave you a long way off an actual quotation.

Every supplier uses a different format, so how many templates do we need

In principle one per supplier, and in some cases one per branch. You do not need to build them all from the start, however. Count the volume by supplier, start with the concentrated top end, and expand in stages. Leaving low-volume suppliers on manual entry is a defensible decision.

Can documents photographed on a smartphone be read

They can in most cases, though variation in conditions drives the result, because oblique angles, backlighting, camera shake and the way shadows fall all come into play. If you can install a fixed capture stand at the receiving counter, that is more stable. When using a handheld terminal, setting the capture position and how the paper is held as an operating rule keeps the variation in accuracy small.

Summary

A delivery note is a piece of paper that arrives on the floor with the goods. The moment the receiving clerk signs it, though, the paper goes to accounting and the goods go to the warehouse, on separate paths. The two meet again at month end when the invoice arrives, and by then nobody can recount the goods. Delivery note data capture is the work of tying those two flows back into one during the minute the shipment is handed over.

In Thailand that paper is usually a combined delivery note and tax invoice, so from the moment it reaches your floor it doubles as the input VAT credit document. That is why the Japanese habit of keeping a copy on the shop floor does not transfer easily. On the other hand, because Section 86/4 of the Revenue Code prescribes the mandatory particulars, you do not have to decide the backbone of your OCR extraction fields on business grounds. That is a design advantage which invoice automation does not have.

In designing the matching, decide who stops what and where before you decide what tolerance to set. Quantity and item discrepancies are confirmed at the gate where the goods are, and price discrepancies are resolved in the back office. Stop a price discrepancy on the floor and the truck cannot clear the gate. And when you explain the investment, do not count the reduction in clerical hours alone. The model calculation gives an annual labour saving of 247,500 THB against an annual cost of 270,000 THB, so on that basis it does not pay back. Where matching at the point of receipt really earns its keep is on the recovery cost of incorrect goods receipts.

We build production management and business systems for Japanese manufacturers in Thailand, and on document capture at the receiving dock we support the whole path, from classifying the actual delivery notes through designing the discrepancy rules to integrating with the inventory system. It is perfectly fine to come to us before you are ready to shortlist products, simply wanting to understand what is happening at your own receiving dock. We can start by looking at your documents and proposing where to begin for the quickest effect. You are welcome to get in touch through our contact page.

References

• Section 85_86 | The Revenue Department (English Site)
• Thai Tax localization — Delivery Note / Tax Invoice
• Three-way matching explained — GENIAL TECH (Japanese)
• Invoice matching and how to streamline it against purchase orders and delivery notes — invox (Japanese)
• Guide to eliminating manual delivery note entry with AI-OCR — LINE WORKS PaperOn (Japanese)
• AI Packing Slip Processing and Data Extraction — Affinda
• Best Delivery Note OCR Software 2026 — Lido
• Cost benchmarks for AI-OCR invoice processing automation — MRI (Japanese)