Shipping and Receiving Inspection System | Stop Mis-Shipments

“We installed a shipping and receiving inspection system, but mis-shipments haven’t stopped.” We hear this from Japanese-affiliated plants across Thailand almost every month. In most cases the hardware is not the problem. What is missing is the verification design — a clear decision about what is matched against what, at exactly which moment, and under whose responsibility. This article breaks the flow from receiving to dispatch into five verification checkpoints and explains how to set the right strength for each one.

Are you still stuck at “scan the barcode and mis-shipments go away”?

When a plant starts looking at mis-shipment countermeasures, the first proposal is almost always identical: buy handheld terminals and make the operators scan barcodes. There is nothing wrong with that proposal. Compared with a purely visual, paper-based operation, adding a scan produces a visible improvement almost immediately.

The trouble shows up about six months later. Visit the same plant and you hear a different set of sentences:

“We are scanning, but we still get a few shipping errors a month.”

“When a claim comes in and we investigate, the handheld log is right there. The scan happened. The shipment was still wrong.”

“It isn’t one person repeating one mistake. It happens to whoever is on shift.”

None of that is a hardware problem. Read accuracy is not the issue, and neither is operator attitude. The verification design has a hole in it.

To put it more precisely: scanning a barcode is not, by itself, verification. It becomes verification only when the scanned result is matched against something, and only when a mismatch prevents the work from moving to the next step. Most sites have implemented the “read” half. They have not defined, process by process, what the read value is compared against and what happens when the comparison fails. So the logs pile up and the errors survive.

The more dangerous version of this problem is subtler. Many plants do not realise that an entire process step has no verification at all. They scan at receiving. They scan at picking. They print a shipping document. On a whiteboard it looks like full coverage — and yet one step in the middle is passing through completely unchecked. Identifying that step is the single most important thing this article has to offer.

Measuring mis-shipments in PPM

Before getting into design, establish where you are today in numbers. Mis-shipment performance is normally expressed in PPM (Parts Per Million).

Mis-shipment rate (PPM) = mis-shipments ÷ total shipments × 1,000,000

If you ship 10,000 orders a month and three of them are wrong, that is 3 ÷ 10,000 × 1,000,000 = 300 PPM. “Three a month” sounds small when you say it out loud. Convert it to PPM, and you can see where your own site actually stands.

As reference points: a fully automated distribution centre is reported to operate at roughly 10 PPM, while warehouses running on largely analogue management have been reported at 1,000 PPM. In e-commerce logistics practice, a common recommendation is to set 100 PPM or better as the first target.

Manufacturing shipments are usually far lower in volume than e-commerce, so the PPM figure is statistically noisy — a single error against 1,000 monthly shipments already puts you at 1,000 PPM. Even so, the act of recording PPM continuously has value in itself. It lets you look at improvement as a trend line instead of “it feels like it’s gone down.” It also changes the quality of the monthly report to Japan headquarters: quoting both the raw count and the PPM makes the discussion concrete rather than anecdotal.

The three root causes of mis-shipment

Mis-shipment causes sort cleanly into three categories.

The right-hand column reflects the tendencies we observe on Thai shop floors; it is not statistical data. Read it against your own history rather than adopting it as fact.

The point worth noticing is this: categories 1 and 3 cannot be prevented by scanning at the picking step. Category 2 — wrong item — is exactly what picking scans are good at, and it does drop substantially. But wrong quantity usually occurs after picking, at the moment goods go into cartons. And delivery error occurs entirely after the match against the shipping instruction has already been completed and closed.

Which means a plant that has installed handhelds only at picking may have addressed only one of the three categories. That is the real explanation behind “we scan, and the errors are still there.”

The five-checkpoint verification model

So let us break the flow from receiving to dispatch into five verification checkpoints. For each of the five you decide two things: what is matched against what, and what happens on a mismatch. That is what we mean by verification design.

1. Receiving verification — match the goods against your own PO data

This step confirms that what the supplier delivered matches what you ordered. The critical nuance is that you are not checking the goods against the delivery note — you are checking the goods against your own purchase order data. The delivery note was written by the supplier. Goods that agree with the delivery note do not necessarily agree with what you actually ordered.

A very common Thai situation: the delivery note from a local supplier is in Thai, while the part master inherited from Japan is still in Japanese. Matching by item name means a human being translating and comparing in real time, and that is where things slip through.

Whether the supplier can be asked to apply your labels largely determines how this checkpoint can be designed. If they can, you get barcode verification from the moment goods arrive. If they cannot, you are forced into a design where you print and apply your own label at receiving — which effectively makes your dock the origin point of all downstream traceability.

Weak receiving verification contaminates everything downstream. Once wrong goods enter stock under a correct part number, no amount of careful scanning later will help: the system considers everything normal while the wrong item flows out the door. Checkpoint 1 is the precondition that makes every later check meaningful.

2. Put-away verification — bind the goods to a location

This step records which rack or which zone received the goods. Plants that skip it and operate on “roughly over there” are far from rare in Thailand. The pattern we see most often involves items recently transferred from Japan, or prototype and low-volume items, whose “temporary” location quietly became permanent.

What happens without put-away verification? Picking becomes searching. And once people are searching, they reach for the similar-looking thing nearby. That is the breeding ground for wrong-item errors. When the cause analysis says wrong-item errors increase in “cluttered work environments,” this is the mechanism it is describing.

Our article on optimal inventory level management approaches location and inventory management from the stock-level side.

3. Picking verification — make it a three-way match

This step confirms that the operator took the right goods from the right rack against the shipping instruction. For most plants, this is the first place they invest.

The design point that gets missed: verify instruction ↔ location ↔ goods as a three-way match, not instruction ↔ goods as a two-way match. If the operator scans the item but never scans the location, then “correct part number taken from the wrong rack” passes silently. Wrong rack usually means wrong lot, or stock allocated to a different customer. For lot-controlled items, or for customer-dedicated inventory, that is real damage rather than a technicality.

Device selection and picking operation itself are covered in detail in our article on handheld terminal and barcode picking. Here we deliberately stay on the question of which checkpoint the device is placed at rather than which model to buy.

4. Packing verification — the checkpoint almost everyone skips

Now to the heart of it. Of the five checkpoints, packing verification is by far the one most likely to be missing entirely.

Packing verification confirms that what was assembled as an order unit corresponds correctly to the package units — the cartons and pallets it physically ends up in. “Picking finished correctly” and “the right things went into the right box” are two separate events, and treating them as one is the core mistake.

Why does this checkpoint disappear? Three reasons.

Reason 1: an unspoken assumption that correct picking implies correct packing. Once scan verification exists at picking, both the operator and the supervisor feel that verification is done. Everything after that looks like “just putting things in boxes.” In reality, that putting-things-in-boxes happens in a location where multiple orders flow in parallel.

Reason 2: the packing area is physically crowded. Picked goods arrive by cart or tote, and several orders sit on the packing bench simultaneously. Add void fill, tape, a label printer, waybills. At that density, “put it in the neighbouring order’s carton” happens easily and often.

Reason 3: packing is invisible to the system. Shipping instruction data contains what to ship and how many. It rarely contains how many cartons that will be split into or which items go into which carton. In other words, there is no reference data on the system side — so there is nothing to verify against, and the checkpoint quietly ceases to exist.

Because checkpoint 4 is the centre of this article, we will look at it from two angles — the failures it causes and how to implement it — before returning to checkpoint 5.

What goes wrong when packing verification is missing

These are the patterns that actually occur in Japanese-affiliated plants in Thailand.

Split packing that doesn’t add up. An order of 500 pieces is split into five cartons of 100. In practice only four cartons get built; the fifth carton’s contents are still sitting in the picking area. The picking log shows 500 allocated, so the system considers the order complete. Days later the customer calls to say only 400 arrived.

Same part number, different lot, swapped cartons. Identical part number, but lot A is destined for Japan and lot B for the Thai domestic market. The cartons look the same from the outside. Both sit on the packing bench, and the waybills get swapped at labelling. Because the part number is identical, a part-number scan at shipping cannot detect it. For a customer with traceability requirements, this becomes a serious claim.

Consolidated packing where an item was “definitely put in.” Multiple orders for the same customer are consolidated into one outer carton for a single delivery. The last item never makes it in. Picking was correct, the waybill is correct, the carton count is correct. Only the contents are one short.

Label sequence shift. Labels come off the printer in a continuous run; the operator peels a stack and applies them in order. One label out of sequence, and everything after it is out of sequence too. This error is undetectable without opening the cartons.

In every one of these cases, raising the verification strength at picking will not help. The only thing that helps is bringing a record and a check into the packing step itself — a record that says “this carton contains this content.”

How to implement packing verification

The concept is simple: give each carton a unique ID, and bind the goods placed inside it to that ID.

In practice the flow looks like this:

1. When packing starts, print and apply an outer carton label carrying the carton ID
2. Scan the goods going into the carton, either piece by piece or by category
3. When the carton is closed, fix its contents and update the remaining quantity on the order
4. When the full order quantity has been allocated to cartons, the order is packing-complete

The value of this design is that “remaining quantity” becomes visible in real time. On a 500-piece order, if the screen shows “100 remaining” after the fourth carton, the operator notices the missing fifth carton right there instead of two days later. That is what level-2 verification strength (scan verification, described below) buys you.

Push it further and refuse to let the order be marked packing-complete — or refuse to print the waybill — until the remaining quantity is zero, and you have level-3 strength. At that point the failure mode of “moving to the next step with a gap still open” is structurally blocked rather than merely visible. Split-packing omissions become substantially less likely once you reach this stage.

For items where scanning every single piece is impractical — several hundred small components in one carton, for instance — it is perfectly reasonable to verify only the link between the carton and its part number and quantity rather than inspecting each piece. What matters is not scanning everything. What matters is holding reference data at the level of the carton as a unit.

5. Shipping verification — extend the scope to loading

Finally, confirm that the packed carton is bound to the correct waybill and loaded onto the correct vehicle. This is the checkpoint that acts directly on cause category 3.

On Thai sites, multiple deliveries frequently overlap in the same time window, and loading proceeds while vehicles queue in the yard. An export shipment bound for Japan, a transfer to an affiliated domestic plant, and a local customer delivery all line up at the same dock. Scanning the carton ID at loading and confirming “does this carton belong on this truck?” reduces wrong-truck errors sharply.

If checkpoint 4 is implemented, checkpoint 5 costs almost nothing — you simply read the carton ID. The reverse is also true: if you skip 4 and attempt 5 alone, you have no means of guaranteeing what is inside the carton, so checkpoint 5 can only ever assert that the carton count is right. Treat 4 and 5 as a pair to be designed together.

Deciding the “strength” of each check — three levels

Once the flow is broken into five checkpoints, the next decision is the strength applied to each. “We verify here” can mean radically different things in practice.

Most plants stop at level 2

This is the investment decision point. Most plants reach level 2, scan verification, and stop there. Level 2 has one decisive weakness.

Level 2 records that a scan happened. It cannot prevent a scan from not happening.

When the operator is behind schedule, when the handheld responds slowly, or when the item is simply “the usual one,” the scan gets skipped. Work continues regardless. Reviewing the audit log afterwards will show that a particular shipment has no scan record — but that review happens after the truck has left.

Worse is what we call ritual scanning. A sample item is left permanently on the packing bench and scanned every time. Or the barcode printed on the instruction sheet is scanned instead of the barcode on the goods. Both produce a flawless “verification performed” record. Neither involves any bad intent — these are workarounds that busy operations invent spontaneously to keep the line moving. A level-2 design cannot detect either of them.

What level 3 system lock actually buys you

Level 3 makes progress to the next step impossible on a mismatch. In practice it is implemented as “the packing-complete button will not respond,” “the waybill will not print,” or “the next order will not appear on screen.”

The essence of level 3 is that it moves verification out of the operator’s goodwill and into the structure of the process. Level 2 lets you proceed even if you skip the read. Level 3 does not let you proceed without it. Dependence on individual diligence drops dramatically.

That matters especially at sites with a certain amount of local staff turnover. When people change, the system still applies the same constraint. The training burden shifts from “make them understand why verification matters” to “teach them which button to press.” That shift is the single biggest reason we recommend reaching level 3 on Thai sites.

What you have to design alongside level 3

Level 3 does carry its own difficulty: how exceptions are handled.

Situations the system did not anticipate occur on a regular basis. A label is torn and unreadable. An urgent additional shipment appears. A prototype not yet registered in the master has to go out. If level 3 is enforced rigidly with no route around it, the floor stops completely. And a floor that has stopped will, almost without exception, invent a bypass. Unlocking under a supervisor’s ID becomes routine, and before long a meaningful share of all shipments is going out through the override path.

So when you implement level 3, design these together with it:

• Who can override — restrict the privilege. If everyone can unlock, it is not level 3
• Whether an override requires a reason code — an unrecorded reason cannot drive improvement
• Whether override counts are reviewed on a cycle — look at count and reason monthly
• Whether frequent reason codes are treated as a signal to fix the design itself

The realistic goal is not zero overrides. It is a state where overrides are visible and declining by reason category.

Plot yourself on the 5 × 3 matrix

Combine the two axes and write down where your own site sits.

When most plants fill in this table, the result is the same shape: checkpoint 3 sits at level 2, and checkpoint 4 is blank. Then line up the actual mis-shipment claims from the past year, and the majority trace back to checkpoint 4. That correspondence is the core claim of this article.

On a return-on-investment basis, if you can add exactly one checkpoint, add packing verification.

Warehouse inspection and in-process wrong-part prevention are the same design

Everything so far has been framed as a warehouse and logistics topic. For a manufacturer, the more valuable observation is that this same verification design transfers directly to preventing wrong-part errors inside the production process.

In-process wrong-part errors look like this:

• The wrong component is fitted to work-in-process arriving from the previous step
• During changeover, material for a different model is loaded onto the machine
• In surface treatment or heat treatment, product from another lot is mixed into the same batch
• After inspection, good and defective parts are placed on the wrong shelf

Look at the structure of each one. All of them are a three-way match between an instruction (work order, kanban, production order), the physical goods, and a location or a machine. They are structurally identical to checkpoint 3, picking verification.

In-process errors typically cost more than logistics errors. A mis-shipment can sometimes be resolved by replacing the goods after delivery. A wrong part discovered after further processing means every affected work-in-process unit becomes a loss — and if the customer has traceability requirements, someone has to determine and report the full range of affected lots.

For that reason, we recommend against selecting a shipping and receiving inspection system as a logistics-only system. A configuration where the same verification engine, the same master data and the same label scheme can be extended into production changes the cost picture significantly when you later add in-process wrong-part prevention.

Item tags and label printing are where the design starts

Verification only works if the physical goods carry an identifier that can be read. Item tags and labels are how that identifier is issued.

The point that gets overlooked: when and where you issue the item tag determines the verification design itself.

• Issued at receiving → the item can be tracked consistently from checkpoint 1
• Issued at put-away → checkpoint 1 stays visual
• Issued at packing → only checkpoints 4 and 5 can be verified
• Issued midway through production → nothing before that point can be tracked

Deciding where you apply the label is the same decision as deciding where verification begins. Evaluate a label printing system separately from the inspection system and this relationship becomes invisible.

Plants running kanban can often use the kanban itself as the identifier. Add a barcode or QR code to the existing kanban and feed that into verification. Since no new paperwork is introduced, floor acceptance tends to be noticeably better.

GS1 Sunrise 2027 — choose with 2D in mind

If you are selecting an inspection system now, there is one international development you should factor in: GS1 Sunrise 2027.

This is a global transition initiative under which retail point-of-sale systems are to be capable of handling 2D barcodes — GS1 DataMatrix and QR — by the end of 2027. It reads as a retail story, but its meaning for manufacturing and logistics is direct.

A 1D barcode identifies only the type of product. A 2D barcode can identify down to the lot and even the individual item.

That difference matters enormously for verification design. Recall the failure described earlier: same part number, different lot, swapped cartons. As long as you verify with 1D codes, you have no mechanism to distinguish two cartons carrying the same part number. Encode lot information in a 2D code and the same part number with a different lot registers as a mismatch.

In other words, 2D raises the resolution of verification. The stronger your customers’ traceability requirements — automotive, medical devices, food — the larger this effect.

Three things to confirm when evaluating systems:

Realistically, no one converts an established 1D operation overnight. Phased migration is the assumption. Run a period where 1D and 2D coexist, apply 2D to new items first, and migrate existing items as they come up for revision. The critical requirement is that the system accepts both. When you evaluate a new inspection system, do not stop at “can it read 2D” — ask whether it can operate a period in which 1D and 2D are mixed.

Thailand in 2026 — the investment reality

For companies with operations in Thailand, the 2026 investment environment does not invite optimism.

Thai GDP grew 2.5% for full-year 2024, but the third quarter of 2025 registered -2.24% on a quarter-on-quarter annualised basis — the first contraction in roughly three years. The 2026 outlook has been revised down to around 1.8 to 2.0%. Household debt has reached approximately 90% of GDP, above the 80% threshold the BIS treats as a danger zone. Export dependence stands at roughly 60% of GDP, and automotive domestic sales are at historically low levels, with utilisation rates continuing to fall.

On the investment side, a different current is running. Applications to the Thailand Board of Investment reached a record 1.8 trillion baht in 2025, and the “Thailand Fast Pass” scheme has been formally launched, shortening approval timelines for advanced manufacturing investments worth over 700 billion baht. For BOI-promoted companies, restrictions on foreign employment have also been substantially relaxed.

What do these two currents mean for a plant-level investment decision?

Large automation capital requests are hard to get approved, but investment itself has not stopped. Putting an automated storage system or a sorter through approval while utilisation is falling is not realistic. Mis-shipments, however, translate directly into customer claims, and they consume both response hours and credibility. Starting from a low-cost verification design with a visible effect is a rational move in exactly this kind of environment.

In practice, the sequence looks like this:

1. If you already own handheld assets, add the packing verification software layer first — minimise new device purchases
2. Measure the effect in PPM and build three to six months of actual results
3. Use that record as the basis for the next request: level-3 system lock, extension into production, 2D migration

Do not try to push one large investment through in a single step. Create a measurable effect, then stack on top of it. In a low-utilisation environment, capital requests generally do not clear in any other order.

For higher-unit-cost technologies such as RFID, we have set out the cost picture in our article on RFID implementation cost for factories. We recommend deciding the verification design first, then asking which checkpoints RFID suits.

Practical rollout steps for a Thai site

Once the verification design is settled, implementation follows. Here is the sequence that actually works in Japanese-affiliated plants in Thailand.

Step 1: Sort your mis-shipment history by checkpoint

Lay out the claims and shipping errors from the past year and classify which of the five checkpoints each one occurred at. This exercise alone usually settles where the investment should go.

If no records exist, start by capturing three months. This level of granularity is sufficient:

If the “estimated checkpoint” column frequently cannot be filled in, that in itself is a signal: the record chain between process steps is broken.

Step 2: Resolve mixed item naming before anything else

A problem that repeatedly surfaces during implementation at Japanese-affiliated plants in Thailand is inconsistent item naming.

The same item carries a Japanese name in headquarters’ system, an English name in the Thai ERP, and a Thai nickname on the rack label. On top of that, local staff have settled on informal terms of their own — “the blue one,” “the big one.”

A verification system runs on part numbers, so in principle it works despite the inconsistency. But if the name displayed on screen does not match what the floor actually calls the item, operators stop trusting the screen. A mismatch alert appears and gets interpreted as “it’s just showing a different name again,” then overridden.

The remedy is straightforward: display the names the floor actually uses. Show part number plus English name plus the Thai colloquial name, in three lines. If space is constrained, prioritise the Thai name. The people reading the screen are the floor staff.

Step 3: Build training cost into the design

Design on the assumption that local staff will turn over. The key principle is to translate training from knowledge into operation.

• Reduce the number of buttons on screen — ideally one action per screen
• Indicate state with colour (green = OK, red = mismatch) so no reading is required
• Write error messages in Thai, and include the next action (“This item belongs to a different carton. Return it to its original location,” not “Mismatch”)
• Limit what a new hire touches in the first week to a single packing verification screen

Training people to understand why verification matters has real value, but do not build a design that depends on it. A site whose quality collapses the moment the person who understands the system resigns is a fragile one.

Step 4: Check what records customer audits and trace requests demand

Customers in automotive and medical devices frequently require lot-level traceability records. Plenty of sites still respond to “when and on which shipment did this lot go out?” by digging back through paper shipping records.

Implement a verification system and these records accumulate automatically as a by-product. When, which lot, in which carton, on which truck — all of it persists. That is a value entirely separate from mis-shipment reduction.

When writing the capital request, state this secondary benefit explicitly. Estimating the value of mis-shipment reduction requires collecting your own data, whereas “customer audit preparation hours go down” and “response time to trace requests gets shorter” can be explained immediately in staff hours. As a starting point, total up how many hours went into customer audits and trace requests over the past twelve months.

Step 5: Start small and measure in PPM

Do not put every item and every line in scope at once. Narrow the target using these criteria:

• Item groups with the highest mis-shipment history
• Delivery destinations where split packing or consolidated packing occurs
• Items requiring lot control
• High-frequency products where the effect will show up quickly

A narrower scope shortens the time until the effect is visible in PPM. If a trend emerges within three months, you have material for the next decision. A simultaneous company-wide rollout has the opposite structure: floor dissatisfaction arrives before the effect does, and the operation tends to get hollowed out midway.

How to think about cost

We avoid quoting definitive figures for a shipping and receiving inspection system, because the composition varies enormously by project. What is useful instead is the set of line items you should normalise across quotations before comparing them.

The line item to watch hardest is master data preparation. Load an inspection system on top of incomplete part masters, location masters and business partner masters, and verification simply does not function. Who performs that preparation — you or the vendor — changes the total materially. If a proposal has no line for master data preparation, assume that effort lands entirely on your side.

We do not present payback periods, because unfounded numbers are worse than no numbers. What is clear, however, is the data you need to collect internally in order to calculate one:

• Direct cost per mis-shipment (reshipment freight, cost of replacement production)
• Hours spent responding (root cause investigation, customer reporting, corrective action reports)
• Impact where a customer line stopped
• Annual incident count

With those four, you can build an estimate on your own assumptions. That produces a far more persuasive capital request than importing another company’s payback figure.

For comparison criteria on the systems themselves, see our article on factory inventory management system comparison. Evaluating products after settling the verification design narrows the comparison considerably.

Self-assessment checklist

Finally, a checklist for applying this article to your own site. Anywhere you answer “no” is a starting point for review.

Coverage of checkpoints

• [ ] At receiving, goods are matched against your own purchase order data (not against the delivery note)
• [ ] At put-away, goods are recorded against a location
• [ ] At picking, verification is a three-way match: instruction ↔ location ↔ goods
• [ ] At packing, the correspondence between carton and contents is recorded
• [ ] At shipping, the correspondence between carton and waybill / truck is confirmed

Strength of verification

• [ ] For each checkpoint, what happens on a mismatch has been decided
• [ ] You know which steps allow work to proceed even if the scan is skipped
• [ ] Where a system lock exists, override privileges are restricted to named roles
• [ ] Override counts and reasons are reviewed on a regular cycle

Sustainability of the operation

• [ ] On-screen item names match what the floor actually calls them
• [ ] Error messages are in the local language and state the next action
• [ ] The screen design allows a new hire to learn the operation within a week
• [ ] Mis-shipments are recorded in PPM and the trend is monitored

Readiness for what is coming

• [ ] The configuration has been confirmed capable of supporting 2D barcodes (GS1 DataMatrix / QR)
• [ ] The same verification mechanism can be extended into production for wrong-part prevention
• [ ] Records sufficient for lot- and serial-level trace requests are being retained

Common pitfalls

Patterns we see repeatedly in implementation discussions.

Starting from “let’s put handhelds in every process.” Decide the hardware first and the verification design gets dragged along by the hardware’s constraints. The order is the reverse: decide what is verified where, then select the equipment that design requires.

Starting without deciding the measurement metric. If the post-implementation verdict is “it feels like it’s gone down,” the next investment will not clear approval. Capture a PPM baseline before you start.

Deferring exception handling. Projects that decide to “run the standard case first and think about exceptions later” almost invariably run into confusion after go-live. Exceptions will occur, so design the override flow from day one.

Importing the headquarters specification unchanged. The Japanese operation is optimised for Japanese conditions — item mix, staff retention, language. It will not necessarily run as-is at a Thai site. Screen language and information density in particular are faster to rebuild locally than to force through unchanged.

Treating packing as an activity rather than a checkpoint. As covered at length above. Packing is a verification checkpoint, not simply a task.

Conclusion

When a shipping and receiving inspection system fails to stop mis-shipments, the cause is almost never the equipment. It is that the verification design was never decided. To restate the framework:

• There are five verification checkpoints: receiving, put-away, picking, packing, and shipping
• Of these, packing verification is the one most often missing, and it is where most wrong-quantity errors originate
• Verification has three levels of strength: visual double check, scan verification, system lock
• Scan verification records that a read happened but cannot prevent a read from not happening. Whether you go to system lock is the real investment decision point
• When implementing a system lock, design override privileges, reason codes and periodic review alongside it
• Warehouse inspection and in-process wrong-part prevention share the same three-way match structure. Choose a configuration that anticipates the extension
• If you are selecting now, assume phased migration to 2D barcodes (GS1 Sunrise 2027)
• In Thailand in 2026, large capital requests are hard to clear. Build a measurable effect first, then stack on top of it

Which of your five checkpoints is blank? Start by writing that down.

TOMAS TECH builds production management and logistics systems for Japanese-affiliated manufacturers with operations in Thailand. We are happy to talk at the stage where you are simply trying to work out which verification checkpoint is missing — including when you just want to lay out your recent shipping errors and identify which process each one actually came from. You can reach us through the contact form.

Frequently asked questions

How much does a shipping and receiving inspection system cost?

We avoid quoting a single figure, because the composition varies substantially by project. Cost divides into five categories: hardware (terminals, printers, wireless environment), software (application and subscription), implementation (requirements definition, master data preparation, integration with existing systems), training and go-live, and maintenance. Of these, master data preparation effort is the item most frequently misjudged. When comparing, re-sort every vendor quotation into these five categories and check for missing lines. If a quotation has no line for master data preparation, that effort will likely land on your side.

What is the difference between an inspection system and a WMS?

A WMS (warehouse management system) manages where stock is, how much of it there is, and the history of receipts and issues. An inspection system refers specifically to the portion that verifies whether the instruction and the physical goods agree. Many WMS products include inspection functionality, and the boundary varies by product. The deciding question is whether what you actually need is stock visibility or error detection through verification. If your problem is that stock quantities do not reconcile, lean toward a WMS. If your problem is shipping errors, starting from the verification design produces results faster.

Should we choose barcodes or RFID?

Each suits different checkpoints. Barcodes are strong where you need to read one item reliably at a time, which makes them appropriate for picking and packing verification — steps where the correctness of each individual piece is what matters. RFID’s strength is reading many tags at once, which suits shipping verification and stocktaking — steps where you need to confirm a quantity for a batch quickly. We recommend settling the verification design first, then deciding which technology fits each checkpoint. Cost considerations for RFID are covered in our article on RFID implementation cost for factories.

Why do mis-shipments still happen when we are already scanning?

Two main reasons. First, the step where you scan is not the step where the error occurs. Scanning at picking cannot detect a quantity error or a swapped carton generated at packing. Second, the scan is not functioning as verification. Unless the read value is matched against reference data and a mismatch stops the work, you cannot prevent skipped reads or ritual scanning — scanning a sample item on the bench, or the barcode printed on the instruction sheet. Start by sorting your own mis-shipments across the five checkpoints.

How should packing verification be implemented?

The basis is to give each carton a unique ID and bind the goods placed inside it to that ID. Print and apply a carton-ID label when packing begins, scan the goods going in, and fix the contents when the carton is closed so the order’s remaining quantity updates. Because the remaining quantity is then visible in real time, the failure where one carton of a split shipment is never built becomes far less likely. For items where several hundred small components go into one carton, scanning every piece is impractical, and it is reasonable to verify only the link between the carton and its part number and quantity. The point is not to read everything — it is to hold reference data at the level of the carton.

Do we need to migrate to 2D barcodes right away?

There is no need to switch everything at once, but if you are selecting an inspection system now, we recommend choosing on the assumption of 2D support. GS1 Sunrise 2027 is an international transition initiative under which retail POS systems are to handle 2D barcodes (GS1 DataMatrix / QR) by the end of 2027, and phased migration is the underlying assumption. A 1D code identifies only the product type, while 2D can identify down to the lot and individual item — which is what makes it possible to detect a swap between the same part number in different lots. Three things to confirm: whether your ERP/WMS can generate and manage the data, whether your production line can print 2D at sufficient quality, and whether you can operate a period in which 1D and 2D coexist.

Can the operation be sustained with high local staff turnover?

There are design choices that make it far more sustainable. The key is to place verification in the structure of the process rather than in the operator’s understanding or goodwill. Put a system lock (strength level 3) at the critical checkpoints so that a mismatch blocks progress, and the same constraint applies regardless of who is on shift. Combine that with a reduced button count, colour-coded status, and error messages written in the local language that state the next action, and training shifts from “understanding why it matters” to “learning the operation.” Limiting what a new hire touches to a single screen at first is also effective.