QR code inventory management succeeds or fails long before a label is scanned. The decisive questions are what each code identifies, who owns the corresponding master data, which event changes stock, and how the ledger remains correct when a device is offline or an event is resent. This implementation guide is for manufacturing and warehouse leaders in Thailand who need to turn a QR concept into an RFP, a 90-day proof of concept, FAT/SAT evidence and an investment decision.
The scope is deliberately narrow. It does not repeat a generic QR-versus-RFID comparison, handheld buying guide or WMS overview. For those decisions, see our factory RFID cost guide and Thailand handheld terminal implementation guide. Here, the subject is the control architecture behind the scan.
The key principle: a QR code carries an identifier, not inventory
A QR code can contain an item ID, batch, serial, handling-unit ID, location ID or a URI referring to those data. It does not itself prove that 20 pieces moved from rack A to rack B, passed inspection or were found short during counting. Those are business events created and validated by the inventory application.
Separate four layers before selecting hardware or software.
| Layer | Decision | Common failure |
|---|---|---|
| Identifier | What is uniquely identified, who issues it, whether it is reused | Treating an item code as if it also identified a batch and container |
| Master | Item, unit, pack, batch rules, location and status | Allowing operators to reconcile inconsistent names mentally |
| Event | Meaning of RECEIVE, MOVE, ISSUE, COUNT and ADJUST | Treating a successful scan as a completed movement |
| Ledger | System of record, authorization, idempotency and ERP reconciliation | Assuming that encoded data removes the need for controls |
This distinction turns a barcode management system from a scanner purchase into a data and control project. Without it, the same code scanned during receipt, movement and counting has no unambiguous stock effect.
Ordinary QR codes and GS1-standardized 2D data are not the same
An ordinary QR code can contain arbitrary text or a URL. A short internal ID can be a sound choice for locations or reusable handling units if a server resolves the attributes. When identifiers must be exchanged with suppliers, customers, logistics providers or retailers, GS1 data structures and GS1 Digital Link deserve consideration.
GS1 Digital Link expresses standard identifiers using Web URI syntax and connects identifiers carried in barcodes with online information. The current ratified GS1 Digital Link URI Syntax is version 1.7.0, August 2026. GS1 retail guidance and GS1 Thailand show examples that combine a GTIN with data such as batch/lot, expiry date and serial number.
The end-of-2027 ambition is frequently misunderstood. It is an industry target for retail point-of-sale systems to process both traditional linear and 2D barcodes. It is not a statutory deadline requiring every factory inventory process to convert to 2D. A factory should decide based on trading-partner requirements, interoperability, existing symbols, label space and scanner compatibility—not on a false legal deadline.
Eight questions for identifier design
- What entity is identified: item, batch, serial, box, pallet, location, asset or order?
- What granularity is needed: a batch quantity or every handling unit?
- Who issues the ID: supplier, customer, group ERP, local MES, WMS or printer service?
- What happens after split, merge, repack, return or rework?
- Can the ID be reused? Location IDs may be reusable; serial and event IDs normally should not be.
- What belongs in the symbol? More changing attributes mean a larger symbol and more relabelling.
- What human-readable data is needed for recovery when a scan fails?
- Is external standardization required for a trading network, or is this an internal control?
A useful default is to encode a short, immutable identifier and retrieve changing descriptions, units and storage rules from masters. Where external partners must obtain lot or expiry directly from the carrier, use appropriate standardized data elements. In either case, parse and validate the payload through an interface layer instead of embedding raw strings in business logic.
Master data is the foundation of real-time inventory
Real-time inventory does not mean that a screen refreshes every second. It means a valid event resolves to the correct master, posts once to the ledger, and exposes exceptions. Posting a wrong unit conversion or obsolete location faster only makes the error travel faster.
| Master | Typical required fields | Candidate authority | Negative test |
|---|---|---|---|
| Item | item ID, description, base unit, lot/serial policy | ERP | unknown, inactive, similar code |
| Pack and conversion | case/each, pallet/case, effective date | ERP/WMS | remainder, conversion change, rounding |
| Location | zone, rack, bin, capacity, status | WMS | closed, duplicate, relocated |
| Label template | template, printer, DPI, revision | WMS/print service | obsolete revision, missing language |
| Reason code | variance, damage, repack, correction | WMS | free-text abuse, missing approval |
| User/device | worker, role, device, shift | IAM/WMS | shared ID, leaver, lost device |
Every master feed needs an effective time, version, approver, destination list and recovery procedure. A description may change without changing the item ID. A unit conversion change must not silently rewrite historical transactions. A location should not be closed while stock or unfinished work remains.
Define receipt, movement, issue and count as events
Write the event contract before the screen list. Each event should carry an event ID, event type, identifier, quantity, unit, from/to location, lot/serial, timestamps, worker/device, business reference and result status. The server uses the event ID and business state to ensure that a retry does not post inventory twice.
RECEIVE
The operator selects an expected receipt, scans the item or handling unit, and confirms quantity, lot, expiry and inspection state. Separate “code read” from “receipt posted” so mistakes can be corrected before stock changes. If a supplier symbol is mapped to an internal ID, distinguish first-time binding from subsequent verification.
MOVE
Validate source location, stock identifier and destination location. Decide whether stock enters an in-transit state or moves atomically. Use reservation or version checks to stop two devices from moving the same balance. A cancellation should be a traceable reversal event, not an overwritten row.
ISSUE
Validate the production order or sales order, eligible stock, quantity and destination. FIFO/FEFO, quarantine, substitutions and over-issue rules belong on the server, not only as a handheld warning. Decide explicitly whether a high-risk issue may be confirmed while offline.
COUNT and ADJUST
Choose blind count, expected-quantity display or variance-only recount based on control objectives. A COUNT is an observation, not an immediate adjustment. Variances should trigger recount, cause classification and approval before an ADJUST event is posted. For the broader operating model, see our Thailand inventory-count time-reduction guide.
Inventory variance: investigate five cause layers
A reason code is useful for reporting but does not prevent recurrence. Classify causes so that process, data and system owners can act.
| Cause layer | Example | Detection | Countermeasure |
|---|---|---|---|
| Identification | old label, duplicate ID, one code reused across packs | duplicate query, revision check | controlled issuance and expiry |
| Master | wrong conversion, location or lot rule | change history, exception rate | dual approval, effective date, validation |
| Event | duplicate send, missed reversal, reversed sequence | event ID and queue monitoring | idempotency, state machine, reversal |
| Shop floor | unrecorded move, skipped scan, relabel | observation and sampling | shorter UI, forced match, training |
| Integration | delayed ERP, ignored error, partial success | reconciliation | retry queue, owner and SLA |
Monitor not only the final variance rate but also unsent events, resend count, duplicate rejection, label reprints, manual-entry share, unresolved reasons and interface queue age. These leading indicators reveal a failing control before month-end counting does.
Offline synchronization needs a local queue and a commit boundary
Metal racks, cold rooms, yards, docks and machinery create uneven radio conditions. Treat disconnection as an ordinary test scenario. A handheld can continue low-risk work by storing events in an encrypted local queue and resending them after connectivity returns.
Device controls
- Generate the event ID at scan time and retain it across every retry.
- Store device time and server receipt time; do not treat the device clock as the only ordering authority.
- Display unsent, sending, accepted, rejected and review-needed states separately.
- Preserve the queue through app termination, reboot and battery replacement.
- Encrypt local storage and support remote revocation for lost devices.
- Warn about a rapid repeat scan without deleting legitimate repeated transactions automatically.
Server controls
- Deduplicate by event ID and validate business state as a second line of defense.
- Reject or isolate an impossible state transition even when events arrive out of order.
- Isolate events created under a stale master revision when risk warrants it.
- Route shortages, closed locations and lot conflicts to CONFLICT REVIEW.
- Define the boundary between inventory commit, ERP delivery, retry and reconciliation.
Not every event should be allowed offline. A count observation or low-risk movement draft can continue, while quality release, stock adjustment, high-value issue or shipment confirmation may require an online check. An RFP must request an event-by-event matrix of allowed, blocked, pending and recovery behavior—not a single “offline supported” tick box.
QR label quality: error correction is not a magic shield
DENSO WAVE’s official QR Code explanation gives approximate codeword restoration levels of L 7%, M 15%, Q 25% and H 30%. This does not mean that any 30% of the printed area can be damaged and an H-level symbol will always scan. Quiet-zone damage, contrast, reflection, curvature, print resolution, module size, scan distance, camera capability and payload length all matter. Higher error correction also creates a larger symbol for the same payload.
Industrial projects sometimes shortlist Q or H, but the answer must come from testing the actual printer, stock, ribbon, surface, laminate, contamination, lighting and distance. Packing a long URL and many changing attributes into a tiny symbol and selecting H is not automatically safer.
| Variable | Minimum test conditions | Evidence |
|---|---|---|
| Printer | production model, DPI, speed and darkness | settings and sample |
| Media | paper/synthetic stock, adhesive, ribbon, laminate | lot and specification |
| Surface | carton, plastic, metal, curved or oily surface | applied sample and retention test |
| Environment | low light, glare, dust, oil, humidity, cold | read rate and failure reason |
| Distance/angle | close, upper rack, oblique and in motion | result by device model |
| Degradation | abrasion, soil, chip and condensation | rescan and manual recovery |
Control the template revision and print history. A reprint must invalidate or detect simultaneous use of the old label. Include a short human-readable ID and a governed lookup, reprint and supervisor-approval procedure.
What to require in a QR inventory RFP
An RFP should be the first draft of the acceptance test, not a product brochure questionnaire. Give every requirement an ID, priority, response format, evidence type, FAT/SAT flag and contractual treatment.
| Area | Required response | Acceptance evidence |
|---|---|---|
| Identifier | entity, syntax, issuer, parent/child, reuse, standard | specification and parsed sample |
| Master | authority, sync, revision, effective time, rejection | valid and invalid records |
| Event | state transition, reversal, idempotency and role | logs and ledger before/after |
| Offline | allowed events, storage, encryption, retry, conflict | outage and recovery test |
| Label | template, quality, reprint and verification | real printer/media/site sample |
| Integration | ERP/WMS boundary, API, order, retry, reconcile | fault injection and reconciliation |
| Security | authentication, roles, device control, logs, retention | configuration and denied-action record |
| Operations | monitoring, SLA, backup, change and training | runbook, drill and restore record |
Do not accept “supported” as the complete response. Require standard/configuration/custom/third-party/unavailable, limits, incremental cost, lead time, maintenance owner and demo evidence. For the wider WMS responsibility boundary, use our Thailand WMS implementation guide.
A 90-day PoC that tests recovery, not just read rate
Ninety days is a planning model, not a delivery or performance guarantee. Adjust it for site scope, shifts, seasonality, ERP change windows and procurement lead times.
Days 0–15: baseline and data contract
Limit the PoC to one representative area, item set and shift pattern. Measure current variance, search time, manual entry, reprints, open transactions and radio dead spots. Freeze the identifier dictionary, master ownership, event list, role model and acceptance scenarios.
Days 16–30: labels and masters
Include unknown items, obsolete codes, unit changes, long descriptions, mixed packs and splits—not only clean samples. Print with production equipment and media. Test actual distance, angle, lighting and contamination. Exercise reprint and old-label detection.
Days 31–60: normal events and integration
Run RECEIVE, MOVE, ISSUE and COUNT with physical stock. Inject ERP delay, duplicate messages, reversed order and cancellation. Verify that the ledger changes correctly once. Have local operators use Thai/English screens with real gloves, light and noise.
Days 61–75: outage and misuse
Cut connectivity immediately before and after the scan, and immediately before and after confirmation. Terminate the app, reboot the device, change the battery, operate the same stock from another device, skew the device clock and change a master. Verify unsent counts, deduplication, conflict isolation, retry and physical/WMS/ERP reconciliation.
Days 76–90: acceptance and decision
Review requirement-to-evidence traceability, open defects, workarounds, residual risk, operating ownership and TCO. Allow GO, CONDITIONAL GO, RETEST, reduced scope or STOP.
FAT, SAT and roll-out are separate evidence gates
Factory Acceptance Testing validates logic, configuration, interfaces and negative paths in a vendor or controlled environment. Site Acceptance Testing uses the real radio network, terminals, printers, materials, lighting, racks, operators and shifts. Passing FAT is not a substitute for SAT.
FAT should cover payload validation, master revision, every event and reversal, duplicates, out-of-order arrivals, local queue behavior, ERP timeout and replay, authorization denials, audit logs, backup restoration and post-restore reconciliation.
SAT should cover every target aisle and route, roaming and dead zones, real label retention and contamination, peak concurrency, shift handover, battery change, Thai operator training, outage recovery with the production-like ERP, cutover and rollback.
Every acceptance record should include preconditions, input, steps, expected and actual result, timestamp, software/configuration versions, device, evidence link, defect ID and approver. Define absolute gates: one stock-integrity breach or unauthorized adjustment can block roll-out even if the overall pass percentage looks high.
Traceable TCO and investment decisions
The following numbers are an illustrative model, not quoted prices, guaranteed savings or a promised payback. The simple model excludes financing and taxes. Replace every assumption with site-specific supplier quotations and PoC measurements.
Three-year TCO model
| Item | Assumption | Calculation | THB |
|---|---|---|---|
| Requirements and design | lump sum | estimate | 350,000 |
| Software and integration | lump sum | estimate | 900,000 |
| Handhelds | 20 × 35,000 | 20×35,000 | 700,000 |
| Printers and radio improvement | lump sum | estimate | 380,000 |
| Initial labels and fixtures | lump sum | estimate | 120,000 |
| Training, PoC and cutover | lump sum | estimate | 450,000 |
| Support/cloud | 420,000/year × 3 | 420,000×3 | 1,260,000 |
| Label consumables | 18,000/month × 36 | 18,000×36 | 648,000 |
| Spare/replacement devices | 15% of device cost | 700,000×0.15 | 105,000 |
| Three-year TCO | sum above | shown inputs summed | 4,913,000 |
Annual quantifiable benefit model
| Benefit | Assumption | Calculation | THB/year |
|---|---|---|---|
| Less search/recording time | 12 people × 0.75 h/day × 260 × 180 | 12×0.75×260×180 | 421,200 |
| Less count time | 24 people × 20 h × 4 × 180 × 40% | 24×20×4×180×0.40 | 138,240 |
| Less variance investigation | 35/month × 2.5 h × 350 × 12 × 50% | 35×2.5×350×12×0.50 | 183,750 |
| Avoided issue/emergency cost | 18/month × 2,800 × 12 × 35% | 18×2,800×12×0.35 | 211,680 |
| Annual quantifiable benefit | sum above | displayed inputs summed | 954,870 |
Three-year benefit is 954,870×3 = 2,864,610 THB. The simple three-year net effect is therefore 2,864,610−4,913,000 = −2,048,390 THB. Under these assumptions, a full deployment does not have a strong quantified case. The team should reduce scope, reuse equipment, simplify integration, focus on high-risk stock, or validate material downtime and quality-loss benefits not yet included.
If 20 people save 1.5 hours daily and variance costs are higher, the result changes. The discipline is to measure baseline and after with the same definition and run sensitivity analysis, not to insert an optimistic improvement percentage.
Do not make BOI incentives a hidden dependency
Thailand BOI public material for Smart and Sustainable Industry describes a THB 1 million minimum investment and a three-year corporate income tax exemption equal to 50% of qualifying investment; it also describes a 100% level when domestic automation or machinery procurement reaches at least 30%, subject to the measure’s conditions and BOI approval. A QR-only project does not automatically qualify. Confirm the current measure, eligible investment, timing and documentation with BOI and professional advisers before committing.
BOI/OSOS reported 132 Smart and Sustainable applications totalling THB 17.2 billion in the first half of 2026. This is background on investment activity, not a count or market size for QR inventory projects.
Weighted supplier scorecard
| Evaluation area | Example weight | Focus |
|---|---|---|
| Identifier and event fit | 20% | standard features, idempotency, reversal, audit |
| Master and ERP integration | 20% | authority, negative paths, reconciliation, maintainability |
| Offline and site fit | 15% | queue, conflicts, devices, Thai-language work |
| Label quality | 10% | real-media testing, reprint and revision |
| Security and operations | 10% | roles, device control, logs and recovery |
| Delivery and local support | 10% | Thailand coverage, training and SLA |
| Three-year TCO | 15% | initial, recurring, change and exit costs |
Agree the weights before proposals are opened. A mandatory-condition failure should disqualify a bid regardless of its weighted score. Use your own data and failure scenarios in demos: unknown item, duplicate scan, outage, ERP timeout, old label and unauthorized adjustment.
Common failures and practical prevention
- Encoding too much: keep immutable IDs separate from changing master attributes.
- Equating “read” with “valid transaction”: validate order, quantity, location, role and state before commit.
- Creating a new ID on retry: retain the original event ID and use an idempotent API.
- Adjusting away every variance: separate COUNT from ADJUST and retain recount, cause and approval.
- Testing labels only in a meeting room: use production printers, stock, racks, light, contamination and gloves.
- Ending the PoC at a demo: include negative paths, recovery, reconciliation and signed evidence.
Implementation checklist
Before RFP
- [ ] Separate item, batch, serial, handling-unit and location identifiers.
- [ ] Define issuance, reuse, parent/child, expiry and reprint.
- [ ] Assign authorities for item, unit, location, label and reason masters.
- [ ] Model RECEIVE, MOVE, ISSUE, COUNT and ADJUST state transitions.
- [ ] Define allowed, blocked and pending offline behavior by event.
- [ ] Measure current label conditions and baseline KPIs.
During PoC
- [ ] Test obsolete codes, bad masters, duplicate and out-of-order events.
- [ ] Cut connectivity around scan and confirmation boundaries.
- [ ] Confirm the same event ID survives reboot and retry.
- [ ] Reconcile physical, inventory application and ERP at one cut-off.
- [ ] Use local operators and every relevant shift.
- [ ] Agree absolute gates for severe defects.
Before roll-out
- [ ] Approve FAT/SAT evidence and open defects.
- [ ] Define cutover, degraded mode, rollback, freeze and opening reconciliation.
- [ ] Prepare monitoring, retry, reprint and lost-device runbooks.
- [ ] Assign owners for 30/60/90-day reviews.
- [ ] Update TCO and sensitivity analysis.
FAQ on QR code inventory management
How is QR code inventory management different from a barcode management system?
QR is one type of two-dimensional barcode and can carry more data than a typical linear symbol in a compact area. A barcode management system is the wider application and control layer: it resolves identifiers, validates masters and events, enforces roles, synchronizes transactions and reconciles the ledger. Choosing QR changes the data carrier; it does not replace those system controls.
Is a QR code inventory system automatically real time?
No. Real-time value requires validated events, a controlled commit, idempotent delivery, monitoring and reconciliation. An offline scan should be visibly marked as pending until the server accepts it.
Is H always the best QR error-correction level?
No. H offers more restoration capability but increases symbol size for the same payload. Test Q and H candidates against module size, media, surface, contamination, distance and actual devices.
Can handheld stock counting work offline?
Yes, if the device durably stores an event with a stable ID and the server deduplicates and isolates conflicts. It can be sensible to allow count observations offline while requiring online approval for adjustments.
What data should be checked first when investigating inventory variance?
Alongside the variance rate, inspect unsent events, duplicate rejection, manual entry, reprints, master errors, unresolved reasons and ERP retry queues. Classifying causes by identifier, master, event, shop-floor and integration layers leads to accountable actions.
Must every factory migrate to 2D by 2027?
No. The GS1 ambition concerns retail POS capability for linear and 2D codes; it is not a legal deadline for every factory inventory operation. Use partner requirements and the business case.
Does a QR inventory project automatically qualify for BOI incentives?
No. Eligibility depends on the current measure, business and investment conditions, application timing, qualifying costs and approval. Validate the case with BOI or qualified advisers and ensure the investment still makes sense without the incentive.
Conclusion: turn a label project into an inventory-control project
The value of QR code inventory management is not the inexpensive printed symbol. It is the ability to record identifiers and events consistently and reconcile physical stock, the inventory ledger and ERP. Separate identifier, master, event and ledger; preserve event identity through outages; validate labels at the site; and use the RFP as the draft acceptance test. A 90-day PoC should test duplicate delivery, reversed order, outage, conflict and recovery—not only successful scans. Connect FAT, SAT and roll-out through evidence gates, then replace every model assumption with measured site data before approving investment.
TOMAS TECH supports factories and warehouses in Thailand with QR identifier and label design, ERP/WMS integration, RFP preparation, 90-day PoCs and FAT/SAT evidence. You can contact us while requirements are still being shaped or when an existing barcode process needs a structured variance investigation.
Primary references
- GS1, “GS1 Digital Link URI Syntax Version 1.7.0”: https://ref.gs1.org/standards/digital-link/uri-syntax/
- GS1, “2D Barcodes at Retail Point-of-Sale Implementation Guideline”: https://ref.gs1.org/guidelines/2d-in-retail/
- GS1 Thailand, “Global Standard 2D Barcode”: https://gs1th.org/globalstandard-2dbarcode/
- GS1 Thailand, English page: https://gs1th.org/en/globalstandard-2dbarcode-en/
- GS1 Thailand, “2D Migration”: https://gs1th.org/2d-migration/
- DENSO WAVE, “Error correction feature”: https://www.qrcode.com/en/about/error_correction.html
- DENSO WAVE, “QR Code standards”: https://www.qrcode.com/en/about/standards.html/index.html
- Thailand Board of Investment, “Smart and Sustainable Industry”: https://www.boi.go.th/index.php?language=en&page=smart_sustainable
- Thailand BOI/OSOS, H1 2026 investment release: https://osos.boi.go.th/EN/news/2430/Thailand-Secures-43-6bn-1H-2026-Investment-Surge-as-Big-Tec/
This article is a general implementation guide based on public information checked on 16 September 2026. It is not legal or tax advice, an incentive-eligibility opinion, a product-performance warranty or an investment-return guarantee.
