Blog

2026.09.06

Thailand Manufacturing Traceability: an EU DPP RFP and 90-Day PoC

Thailand Manufacturing Traceability: an EU DPP RFP and 90-Day PoC

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.

Thailand Manufacturing Traceability: an EU DPP RFP and 90-Day PoC - figure 1

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:

  1. 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.
  2. Destination tracking: work forward from a suspect input, lot or serial to shipments, customers, delivery points, quantities and remaining locations.
  3. Containment decisions: explain the affected scope from actual transformation, aggregation, split and rework relationships—not simply “all production that day”.
  4. Evidence delivery: reproduce who approved which source, when, which version was disclosed and to whom.
  5. 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:

  1. Scope and purpose: which products, sites, processes, customers and regulations are covered, and which decision time should improve?
  2. Identification granularity: where are items, lots, serials and logistic units issued, and how are duplicates and reuse prevented?
  3. Genealogy: how are mixing, splitting, substitutes, rework, subcontracting, sorting and repacking represented?
  4. Event capture: which record is authoritative—ERP/MES entry, scanner, PLC, inspection device or IoT gateway?
  5. Time and sequence: how are ICT, UTC, overnight shifts, late transmission, clock drift and offline replay handled?
  6. Master-data governance: who owns item, BOM, routing, machine, supplier, customer, location, unit, revision and effective date?
  7. Data quality: where do missing values, duplicates, conflicts and unknown codes stop, and who may release an exception?
  8. Forward/backward search: what is the starting key, response target, displayed quantity/location/destination and evidence format?
  9. External exchange: how are GS1/EPCIS, customer API, CSV, portal and DPP services integrated and versioned?
  10. Access control: how are public, customer-restricted, authority/auditor and internal fields separated?
  11. Retention and change evidence: how are retention, correction reason, approval, backup and recovery tests handled?
  12. 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.

Thailand Manufacturing Traceability: an EU DPP RFP and 90-Day PoC - figure 2

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.

Thailand Manufacturing Traceability: an EU DPP RFP and 90-Day PoC - figure 3

Example PoC acceptance matrix

The thresholds are company decisions. The table below shows test design, not external statistics or promised performance.

Acceptance domainIllustrative testIllustrative decision rule
Genealogy completenessTrace selected serials and lots upstreamNo unexplained gap across mandatory operation, input and inspection relationships
Destination traceSearch downstream from a suspect lotDestination, quantity, date and remaining location reconcile to shipment records
Mix and splitReproduce many-to-one, one-to-many and reworkAffected scope matches a frozen expected result
ResponseQuery production-scale sample dataReturn result and evidence within the factory-defined target
Offline replayDisconnect and recover the routeIdentify delay and avoid missing or duplicate events
Data qualitySend unknown code, missing mandatory data and time contradictionReject automatically or preserve as an approved exception
Access rightsQuery the same passport from each roleUnauthorised fields remain hidden in UI, API and export
CorrectionCorrect an error with approvalReproduce old value, reason, requester, approver and time
RecoveryRestore a representative backupValidate 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:

  1. Narrow the first wave by product and material risk.
  2. Inventory current COAs, lots, origin/material declarations and shipping data.
  3. Contract a minimum specification for identities, units, time, correction and version.
  4. Permit maturity levels such as CSV, portal, API and EPCIS while governing common semantics.
  5. Share data-quality findings and exception processes before relying only on penalties.
  6. 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