Production Traceability: Linking Process Data to Batches

A customer complaint arrives with a photo of the pack and its production code. QA has to answer fast: which raw material lot went in, which machine processed it, under what conditions, and which other batches might be affected. When the answers are spread across paper logsheets, spreadsheets, and operators' memories, the investigation takes days, and the hold or recall ends up drawn wide.

Production traceability is the ability to follow every batch from raw material to shipment. This guide focuses on the part most plants leave out, the process data from machines: what to record per batch, how to tie machine data to a batch number, and how to start small.

What production traceability means

Traceability works in two directions:

• Tracing back. From the code on the pack to the batch number, raw material lots, machine, process parameters, and quality results.
• Tracing forward. From one suspect raw material lot, or one process deviation, to every finished batch and every customer that received it.

The principle is simple: each stage records what came in and what went out. What often gets missed is the link when batches merge or split, such as two raw material lots going into one mix, or one batch packed into several pallet lots. That record is called product genealogy.

For processed food in Indonesia, BPOM Regulation No. 22 of 2025 on the withdrawal and destruction of processed food requires producers, importers, and distributors to run a food traceability system as the basis for effective recalls. ISO 22005:2007 sets out general principles for designing one. In other industries, traceability is usually a customer or quality system requirement.

Why process data decides how wide a recall is

Many plants already record incoming lots and outgoing goods in an ERP or on stock cards. What they lack is a record of process conditions per batch. Without it, the only safe response to a problem is to hold every batch made in that period.

As an illustration, a complaint comes in for product packed on a Tuesday. With no process data, all twelve batches from that week look equally risky. Temperature records per batch show that only one batch dipped below its heating limit, for a few minutes, so the investigation can focus there while the other batches have written proof that they stayed within limits. The final call still follows your quality procedures and the regulator, but it now rests on data.

What to record for each batch

Data group	Examples	Typical source
Identity	Batch number, product, batch size, production code on the pack	Production planning or ERP
Inputs	Raw material and packaging lots, quantities used	Warehouse, scans or operator entry
Place and time	Line, machine, start and end of each stage	PLC or operator entry
Critical process parameters	Temperature, pressure, hold time, speed, dosing	Sensors and PLCs
Checks	In-process QC, lab results, release decision	QC and lab
Events	Alarms, stoppages, setting changes, rework	PLC, platform alarms, operators
Outputs	Finished quantity, pallet lots, shipments	Warehouse or ERP

You do not need every number. Start with parameters that have limits in your procedures, such as the critical control points in a food plant's HACCP plan. From the detailed data, build a summary per batch: minimum and maximum, time outside limits, and alarms raised. That summary is what people read during an investigation.

Linking machine data to batch numbers

Machines record data by time, while batches are tracked by number. The bridge is the start and end of each batch on each machine, captured in one of three ways:

1. From the PLC. If the batch or recipe number is sent to the PLC or HMI, start and end times can be read automatically. It is the most reliable option, but needs access to the PLC program.
2. From operator input. Operators scan a QR code or barcode on the batch card at start and end, or pick the batch on a tablet. It is cheap and quick to set up; to avoid missed scans, add simple rules such as no new batch until the previous one is closed.
3. From the production schedule. Data is matched to the planned time windows. Schedules drift, so this is the weakest option and only a first step.

Three more things decide whether it works:

• Clocks must agree. Synchronise PLCs, gateways, servers, and tablets. A few minutes of drift can push data into the wrong batch.
• Record per stage, not per line. Product leaving a mixer may reach the filler tens of minutes later, so each stage needs its own start and end.
• Continuous processes need a lot definition. Where there is no natural batch, define lots by time, for instance per shift, and log every lot change.

Start small: one line, one product

1. Pick one line with the highest complaint risk, or whose customers ask hardest for process evidence.
2. Choose three to five critical parameters and their sources. If they still live on paper, start with our guide to digitising production logsheets.
3. Decide how batch start and end are marked, through the PLC or a QR scan.
4. Generate the per-batch summary automatically, with limits and alarms.
5. Test it with a trace exercise. Take a random product code from the warehouse and time how long the team needs to answer: which raw material lots, which machine, what the parameters were, and which other batches used the same lot. Repeat once the system runs.
6. Extend to other lines and connect batch numbers to the ERP, using the patterns in our article on integrating IoT with an ERP.

Once process data and quality results are linked per batch, the same data can also feed models that predict production defects.

Things to keep in mind

• Retention. Keep records for at least the product's shelf life plus the period your procedures set. Export batch summaries regularly or send them to your own systems instead of relying on raw history.
• Data integrity. Records that can be edited without a trail weaken the evidence. Limit edit rights and log changes.
• Traceability does not replace QC. It shows what happened to a batch, not whether the product is safe.
• You can only trace what you measure. Sensors need calibrating, and unmeasured parameters stay blind spots.
• The pack code must be readable. A smudged code, or one not tied to a batch number, breaks the chain at the very end.

Frequently asked questions

What is the difference between traceability and tracking?

Tracking tells you where a product is now: which warehouse, which customer. Traceability follows its history: the materials, machines, and process conditions when it was made. Both rely on the same lot identity.

Do we need barcodes or RFID?

Not at first. What you need is a consistent batch identity at every stage. Barcodes or QR codes just reduce typing errors when operators log batch start and end.

Does production traceability require an ERP?

Not to get started. The ERP usually holds material and shipping data, while process data comes from machines. The value comes from linking the two through the same batch number.

Production traceability with INCLUDE

The INCLUDE platform takes process data from sensors and PLCs over MQTT, HTTP, or IncludeGateways for Modbus RTU devices, stores every value as time-stamped history, and raises alarms when a parameter leaves the limits you set.

The parts specific to each plant are built through our IoT & AI software development services on top of that platform: a scan screen for operators to open and close batches, per-batch process summaries, trace reports for QA, and batch number sync with your ERP.