Thailand manufacturing traceability becomes an export capability only when it does more than print a QR code or retain transaction history. A useful system connects receipt, production, inspection, packing and shipment through consistent identities and events. It must also reveal only the authorised evidence requested by a customer, auditor or authority. The EU Digital Product Passport Registry became operational on 20 July 2026, but that milestone did not impose an immediate DPP obligation on every product. This guide explains how a Thailand export factory can avoid that overstatement and use an RFP and a 90-day proof of concept to demonstrate what can actually be traced.
First question: did DPP become mandatory for every product?
No. The European Commission describes a DPP as a digital container for information about products, components and materials. Establishing the Registry framework in July 2026 and making the Registry operational on 20 July were important infrastructure steps. Regulation (EU) 2024/1781—the Ecodesign for Sustainable Products Regulation, or ESPR—nevertheless applies concrete DPP requirements through product-group delegated acts. Those acts determine the covered products, required data, carrier and placement, model/batch/item granularity, and access rights.
The Commission’s timeline current in September 2026 says that economic operators will have a transition period of at least 18 months following adoption of ESPR delegated acts. An operating Registry is therefore not the same as a legal duty covering every product a factory exports. A proposal claiming that “all exports to the EU require DPP from 2026” would be inaccurate. Before specifying software, an RFP should map every relevant product classification to the controlling legislation, delegated act and application date.
Battery passports are a specific application beginning on 18 February 2027
Batteries are an early, concrete product group. Updated Commission guidance published on 21 August 2026 organises 71 battery-passport data points. That does not create one universal 71-field schema for every DPP. The guidance indicates whether each point is mandatory, optional, conditionally applicable, or not currently required for the relevant battery category. Under Article 77 of Regulation (EU) 2023/1542, the passport requirement begins on 18 February 2027 for each EV battery, light-means-of-transport battery and industrial battery above 2 kWh placed on the EU market or put into service.
The responsibility boundary also matters. The Commission explains that the economic operator placing the finished battery on the market is responsible for creating and maintaining its passport; an individual component or module supplier is not automatically that legal operator. A Thailand supplier may nevertheless receive contractual data requirements from the responsible customer. “We are not the passport issuer” is not a reason to ignore readiness. It is a reason to separate the legal responsibility from the evidence that the supply contract requires.
The Registry is an index, not a central warehouse for every detailed record
According to the Commission, the DPP Registry indexes passports for products placed on the EU market. It holds unique identifiers, registration information and high-level metadata rather than all detailed passport information. The responsible economic operator maintains detailed data in the decentralised system and presents it according to legally defined access rights.
Translated into RFP language, asking whether a vendor can “upload everything to a DPP cloud” is inadequate. The factory must decide which evidence remains in ERP, MES, QMS, LIMS, PLM, WMS or document management; which identities join it; who approves disclosure; which service registers the passport; and how changes to authoritative source data propagate without breaking the audit trail.

Define the outcomes of Thailand manufacturing traceability first
Traceability is not merely the existence of records. It is the capability to determine an object’s history or location for a defined purpose. Product safety, quality containment, customer audits, anti-counterfeiting, warranty, sustainability and export compliance require different granularity, retention and audiences. Bundling every purpose into one vague requirement creates excessive collection and missing evidence at the same time.
Thailand’s TISI มตช. 22005-2567 is a national conformity-assessment standard setting general principles and basic requirements for designing and implementing traceability in feed and food chains. It was announced in the Royal Gazette on 8 November 2024 and follows the scope of ISO 22005:2007. It is not a universal legal requirement for all industries. Its management logic is nevertheless useful beyond food: establish the objective, design and implement a system to meet it, then assess and review the result.
The GS1 Global Traceability Standard likewise offers a process-neutral framework for traceability across trading parties rather than tying the programme to one product or application. At RFP initiation, agree on five outcomes:
- Manufacturing-history tracking: work backwards from a finished lot or serial to the related components, equipment, process conditions, work and inspection evidence at the required granularity.
- Destination tracking: work forward from a suspect input, lot or serial to shipments, customers, delivery points, quantities and remaining locations.
- Containment decisions: explain the affected scope from actual transformation, aggregation, split and rework relationships—not simply “all production that day”.
- Evidence delivery: reproduce who approved which source, when, which version was disclosed and to whom.
- Future interoperability: connect product-specific DPP schemas, customer portals or EPCIS without changing the meaning of source records.
For the broader investment structure, see traceability-system cost in Thailand. For cross-company event exchange, read supply-chain traceability with EPCIS. This article focuses specifically on RFP acceptance evidence and a DPP-aware PoC.
Design identities, relationships and events before choosing the code carrier
QR, barcode, RFID and direct marking are data carriers. They are not traceability by themselves. The core is what the scanned identity uniquely represents and which relationships and events the system can return.
Identities: prevent the same number from acquiring different meanings
At minimum, distinguish item, production lot, unit serial, material lot, package or logistic unit, location, trading party and equipment. Overwriting a customer item number with an internal item number, a supplier lot with a receipt lot, or the old package identity with the repacked identity breaks the chain.
Prioritise issuing authority, uniqueness, prohibition of reuse, creation time and controlled reprinting over a number that is merely easy for a person to interpret. For DPP readiness, preserve the option to map model, batch or item granularity as the applicable product law requires. Applying unit-level tracking to everything can impose unnecessary operations; locking the system to lots can make an item-specific obligation or contract impossible. Granularity should be selectable based on risk, process behaviour and legal or customer requirements.
Relationships: preserve transformation, aggregation, splitting and rework
A chronological log alone cannot reconstruct manufacturing genealogy. If material lots A and B become semi-finished lot C and C is split into finished lots D and E, preserve A/B → C → D/E. Model practical exceptions: rework entering another lot, subcontract material returning in multiple packs, selected conforming pieces moving into a new lot, bulk consumption and repacking.
One genealogy can then support both trace backward and trace forward. The IATF 16949 traceability guide for Thailand provides an additional automotive-sector perspective on disciplined production evidence.
Events: use a common account of what happened, where and when
GS1 EPCIS 2.0.1 enables disparate applications to create and share visibility-event data within and across enterprises. Its normative artefacts include JSON/JSON-LD validation and REST query definitions. Whether EPCIS compliance belongs in a specific RFP depends on the trading network and use case, but its event questions are highly practical:
- What: product, lot, serial or logistic unit involved
- When: event time, recording time and time zone
- Where: process, machine, warehouse, shipping or receiving location
- Why: receipt, consumption, transformation, inspection, hold, release, packing or shipping state
- How: relevant sensor, measurement or certification evidence
Do not paste standards vocabulary blindly into screens. Map Thai shop-floor language, Japanese headquarters terminology and customer English codes to one governed business vocabulary. Prevent one physical action from being counted twice merely because two applications report it.
Twelve questions for a Thailand traceability RFP
An RFP should require accountability and acceptance evidence, not a feature yes/no answer. Ask at least the following:
- Scope and purpose: which products, sites, processes, customers and regulations are covered, and which decision time should improve?
- Identification granularity: where are items, lots, serials and logistic units issued, and how are duplicates and reuse prevented?
- Genealogy: how are mixing, splitting, substitutes, rework, subcontracting, sorting and repacking represented?
- Event capture: which record is authoritative—ERP/MES entry, scanner, PLC, inspection device or IoT gateway?
- Time and sequence: how are ICT, UTC, overnight shifts, late transmission, clock drift and offline replay handled?
- Master-data governance: who owns item, BOM, routing, machine, supplier, customer, location, unit, revision and effective date?
- Data quality: where do missing values, duplicates, conflicts and unknown codes stop, and who may release an exception?
- Forward/backward search: what is the starting key, response target, displayed quantity/location/destination and evidence format?
- External exchange: how are GS1/EPCIS, customer API, CSV, portal and DPP services integrated and versioned?
- Access control: how are public, customer-restricted, authority/auditor and internal fields separated?
- Retention and change evidence: how are retention, correction reason, approval, backup and recovery tests handled?
- Operational ownership: who handles first response, data stewardship, interface failure, label reprint, SLA and change control?
Require responses as Standard, Configuration, Interface, Customisation, Process Change or Unsupported. “Supported” is not comparable evidence. Each response should identify assumptions, owner, incremental cost, maintenance, upgrade retesting and the PoC test that will prove it.

Build a data-responsibility matrix for product-specific DPP duties
A frequent DPP programme failure is assigning all data to one department. Product identity may originate in engineering, material declarations in procurement and suppliers, production events in the plant, quality in QMS, destination in ERP/WMS, and disclosure approval across legal, quality and sales. For every candidate data point, define:
- Legal source: regulation, delegated act, customer contract or internal policy
- Applicability: mandatory, optional, conditional or not applicable, including decision authority
- Source system: authoritative source and interface
- Granularity: model, batch, item or shipment unit
- Owner: accountability for meaning, accuracy, approval and correction
- Visibility: public, trading partner, authority/auditor or internal
- Update trigger: design revision, manufacturing completion, inspection, repair or reuse
- Evidence: provenance, approval and change history
- Retention: period based on product life, contract and applicable law
When a new delegated act appears, the matrix distinguishes data already governed, data newly required from suppliers and data requiring new process capture. That is more reliable than immediately buying another “DPP module”.
A 90-day PoC that produces evidence, not a product demonstration
The 90-day pattern below is an illustrative planning model—not a statutory timetable, industry benchmark or guarantee. Adjust it for product scope, sites, machines, parties and data quality. The purpose is to retire investment uncertainty in a deliberate sequence, not to complete an enterprise rollout in three months.
Days 1–15: fix the product, law, contract and decision rights
Choose one exported product, one representative line and one destination. Confirm product classification and applicable law with qualified experts; separate current evidence duties from future candidates. For an in-scope battery, use Regulation (EU) 2023/1542 and the current guidance. For another product, determine whether an ESPR delegated act applies. Ban vague requirements such as “DPP-ready”. State a use case, for example: “from a customer complaint serial, reproduce the consumed material lots, inspection evidence, the full scope of products affected by the same cause, and destinations.”
Deliver an applicability note, current process, identity register, data-responsibility matrix, exception catalogue and PoC acceptance sheet. Keep legal applicability decisions separate from solution-design decisions.
Days 16–30: reconcile the physical and data flows
Observe receipt, storage, issue, transformation, mixing or splitting, inspection, packing and shipment. Do not limit the study to the standard work instruction. Follow damaged labels, substitutes, rework, bulk material, remainders, night shift, network interruption and corrections. At each point, record physical identity, capture method, actor, source application and the relationship passed forward.
If the mapping exposes many gaps, do not automate all of them. Prioritise genealogy and destination gaps with the greatest containment impact. Separate controlled procedural workarounds from points that truly require a reader, device or interface.
Days 31–60: connect one representative evidence chain
Ingest only the required events from ERP, MES, QMS, WMS and IoT sources, then connect the selected product upstream and downstream. If EPCIS will be used externally, govern internal meaning and data quality first. Include the normal flow and at least two real exceptions among split, mix, rework, subcontract, hold/release and repack.
Prioritise repeatability: the same governed input should reproduce the same trace result and evidence pack. Verify that Thai-language operations can yield semantically correct English evidence without changing the underlying meaning.
Days 61–75: break the interfaces and permissions deliberately
Create scanner loss, network interruption, duplicate delivery, clock drift, unknown item, label reprint, interface timeout and incorrect destination association. Verify that missing evidence is not silently accepted, replay does not create duplicate events, and correction preserves the original record.
Switch among public, customer, internal quality and administrator roles. Confirm that cost, supplier terms, personal data or commercial details remain hidden across screen, API and export. DPP is not only a public page; access control is a core design concern.
Days 76–90: conduct a mock audit and an evidence-based RFP gate
Ask quality, sales, IT, management and actual users to work the same mock complaint or recall. Record start time, question, search process, exclusion logic, output, approval and completion time. Return unresolved items to the RFP. Make PoC logs, reconciliations, permission tests and recovery results the contract gate—not a vendor presentation.

Example PoC acceptance matrix
The thresholds are company decisions. The table below shows test design, not external statistics or promised performance.
| Acceptance domain | Illustrative test | Illustrative decision rule |
|---|---|---|
| Genealogy completeness | Trace selected serials and lots upstream | No unexplained gap across mandatory operation, input and inspection relationships |
| Destination trace | Search downstream from a suspect lot | Destination, quantity, date and remaining location reconcile to shipment records |
| Mix and split | Reproduce many-to-one, one-to-many and rework | Affected scope matches a frozen expected result |
| Response | Query production-scale sample data | Return result and evidence within the factory-defined target |
| Offline replay | Disconnect and recover the route | Identify delay and avoid missing or duplicate events |
| Data quality | Send unknown code, missing mandatory data and time contradiction | Reject automatically or preserve as an approved exception |
| Access rights | Query the same passport from each role | Unauthorised fields remain hidden in UI, API and export |
| Correction | Correct an error with approval | Reproduce old value, reason, requester, approver and time |
| Recovery | Restore a representative backup | Validate recovery objectives and recheck the genealogy chain |
Freeze the expected result and source ledger before execution. Use anonymised real data, actual exceptions, Thailand plant network conditions and plant users—not only vendor demonstration records.
An integration architecture that keeps manufacturing history intact
The best product mix differs by factory, but responsibilities can be separated clearly:
- ERP: order, purchase, item, BOM, production order, inventory, shipment and customer records
- MES/QMS/LIMS: execution, equipment, operator qualification, test, disposition, deviation and rework
- WMS/barcode/RFID: location, handling unit, movement, pick, pack and dispatch scan
- IoT/PLC/gateway: equipment state, measured value, time and edge buffering
- Traceability repository/EPCIS: cross-system genealogy, event search and controlled exchange
- DPP service: product schema, public/restricted views, carrier and Registry connection
There is no requirement to duplicate everything into one database. Select the minimum events and source references needed for traceability. Corrections should propagate from governed source systems. Allowing arbitrary edits in the aggregation layer makes the authoritative evidence unclear.
Test offline operation and time explicitly in Thailand factories
If a shop-floor connection can drop, queue at the terminal or gateway, distinguish event time from record time and use replay identities to prevent duplicates. Define ICT and UTC storage and display; do not mix headquarters time informally. Overnight shifts may require both calendar date and production date.
Manual contingency is also a system requirement. If operators record on paper during an emergency, define who enters it later, which material remains on hold, how the original record is attached and how duplicate entry is prevented.
Destination tracking and mock recall: explain the boundary
Destination tracking must do more than display a customer name. From the issue origin, reconcile affected item/lot/serial, package, shipment document, delivery point, quantity, date and the locations of returns, inventory and work in process. If production, scrap, samples, stock, shipment and return quantities do not reconcile, a narrow-looking result is not reliable.
In a mock recall, choose one suspect material lot and trace it forward. Then take a customer complaint serial and trace materials and processes backward. Both should resolve through the same genealogy. Products classified as unaffected need exclusion evidence too.
DPP does not replace this foundation. A polished public view cannot compensate for missing internal genealogy. Conversely, reliable event capture and accountability make it easier to map the data required by a future product-specific schema.
Phase supplier and customer participation
Overseas factory traceability cannot end at one company boundary, but requiring one API from every supplier on day one creates gridlock. A pragmatic progression is:
- Narrow the first wave by product and material risk.
- Inventory current COAs, lots, origin/material declarations and shipping data.
- Contract a minimum specification for identities, units, time, correction and version.
- Permit maturity levels such as CSV, portal, API and EPCIS while governing common semantics.
- Share data-quality findings and exception processes before relying only on penalties.
- Separate customer disclosure from supplier-confidential information.
Matching field names is not interoperability. Agree on units, code systems, event meaning, time zone, update and cancellation. When EPCIS is used, govern business-step/disposition vocabulary, identity issuance and query access between partners.
Evaluate BOI support separately from system design
Thailand BOI’s Smart and Sustainable Industry industrial-upgrade measure supports efficiency enhancement and operational upgrades in manufacturing and services. Its current English page describes a minimum efficiency-enhancement investment of THB 1 million excluding land and working capital, machinery import-duty exemption and conditional corporate income-tax incentives. It also states conditions involving machinery linked to the domestic automation industry.
A traceability project is not automatically eligible. Confirm activity, project status, eligible investment, timing, domestic development or certification and implementation deadlines against current BOI announcements and with BOI and qualified tax/legal advisers. Build an RFP base case that works without an incentive, then model the approved case separately. Do not treat an unapproved incentive as ROI.
Operating KPIs after implementation
System launch is not the outcome. Establish baselines during PoC, then set company-specific targets for:
- completeness and on-time capture of required trace events
- unknown codes, duplicates, reversed time and unresolved exceptions
- forward/backward trace completion time for representative items
- quantity reconciliation variance and root-cause category
- label reprint, manual capture and offline replay frequency
- supplier delivery timeliness and correction lead time
- access violations, over-disclosure and audit-log gaps
- mock-recall time for scope, approval and notification preparation
- delays and rejection of DPP or customer evidence submissions
Use KPIs to locate broken ownership, master data and interfaces rather than punish operators. A missing-entry metric alone encourages meaningless placeholder values; combine completeness, accuracy, timeliness and consistency.
Frequently asked questions
Is EU DPP mandatory for every product from 2026?
No. The Registry became operational on 20 July 2026, while ESPR requirements are phased through product-group delegated acts. The Commission says operators receive at least an 18-month transition after adoption of those acts. Confirm the latest act and classification for each product.
Which batteries need a passport, and when?
Article 77 of Regulation (EU) 2023/1542 applies from 18 February 2027 to EV batteries, LMT batteries and industrial batteries above 2 kWh placed on the EU market or put into service. The Commission’s 21 August 2026 guidance organises 71 data points and their category applicability. Confirm the current guidance and your legal role.
Where should a Thailand traceability implementation begin?
Define the product, purpose, start/end point, granularity, decision owner and evidence before selecting technology. Map one representative physical and data flow, then test actual mix, split, rework and network-loss conditions.
Is a QR code enough to track manufacturing history?
No. QR carries an identity or link. Manufacturing history also needs material-to-product genealogy, process and inspection events, correction evidence, destination, quantity reconciliation and access governance.
Is EPCIS 2.0.1 mandatory?
Not universally. It is a strong standard for sharing visibility events across applications and companies, but adoption depends on the applicable product requirement and trading network. Govern internal data and vocabulary first.
Does the 90-day PoC finish the entire production rollout?
No. It is an illustrative investment-decision pattern. Limit the proof to a representative product, line and destination, validate genealogy, exceptions, security, failure and evidence, then decide how to scale.
Conclusion
Thailand manufacturing traceability in the DPP era should not begin with a large purchase justified by a regulatory slogan. The Registry going live on 20 July 2026 was a major infrastructure milestone, but ESPR obligations apply in phases through product-specific delegated acts. Batteries provide a specific case under Regulation (EU) 2023/1542, beginning on 18 February 2027 for stated categories. With that boundary understood, factories can govern identity, genealogy, events, destinations, ownership, access and correction evidence in a way that improves today’s quality response and supports tomorrow’s product-specific DPP mapping. Demand accountability and evidence in the RFP; break exceptions, interfaces and permissions in the PoC.
TOMAS TECH can support Thailand factories with physical/data-flow discovery, traceability RFPs, ERP/MES/WMS/IoT integration, forward and backward tracing, EPCIS exchange and 90-day PoC acceptance design. You can contact us while checking product-specific DPP applicability and before committing to a platform or vendor.
Research sources
- European Commission, Digital Product Passport
- European Commission, The DPP Registry
- EUR-Lex, Regulation (EU) 2024/1781 (ESPR)
- European Commission, battery-passport guidance announcement, 21 August 2026
- EUR-Lex, Regulation (EU) 2023/1542
- GS1, Global Traceability Standard 2.0
- GS1, EPCIS Standard 2.0.1
- TISI, มตช. 22005-2567
- Thailand BOI, Smart and Sustainable Industry