Food traceabilityBatch traceability
Internal lot codes: make identifiers stable before making them clever
An internal lot code needs to identify the intended production or handling unit consistently. Its value comes from reliable links to records, not from encoding every possible detail into a label that becomes difficult to read or maintain.
At a glance
An internal lot code needs to identify the intended production or handling unit consistently. Its value comes from reliable links to records, not from encoding every possible detail into a label that becomes difficult to read or maintain.
Define the decision behind the record
Document where the code is created and how duplicate codes are prevented. Keep product identity alongside the code and avoid using a date alone when more than one distinct batch can exist on that date.
Make the identifier stable and the relationship explicit
Define the unit of identification: supplier lot, receipt event, internal production batch or packaging event. These can be related without being the same object. Choose who assigns internal identifiers and how collisions are prevented across products, sites and repeated production on the same day.
Keep the original supplier identity and record its link to the internal code. Do not rely only on encoded characters to explain origin or destination; retain explicit receipt and transformation records. If an identifier is corrected or replaced, preserve the mapping and reason rather than overwriting history.
Test the design with two batches produced on one day, two sites and a delivery containing several supplier lots. Ask a colleague to retrieve the source record from the label and then trace its outputs. A code that looks informative but resolves to more than one object is less useful than a simple stable identifier with complete linked records.
Worked example
Two preparations occur on the same day. The team assigns distinct identifiers and links each to its actual inputs. Staff can find the correct batch without guessing which run the date refers to.
Build a usable record
Use the fields below to capture the facts needed for this particular decision. Keep the actual observation separate from any later correction or approval.
- Lot creation event
- Product and internal lot identifier
- Relevant source references
- Creator and creation time
- Duplicate check and correction history
Example record and review decision
Fictional record example: REC-01 / supplier ING-A: source identity; internal LOT-2026-001: stable identifier; MAP-01: explicit connection.
Create a second batch at another site and check that it cannot accidentally reuse the same internal identity.
Encoding only a date can create collisions when several products or production runs share that day.
Test the review, not just the form
Try creating two batches with similar names and dates. Test lookup from a printed label and a typed code. Retiring an identifier or correcting a label must not transfer the historical records to another batch.
A few useful answers
Must the lot code contain every production detail?
No. Keep the identifier usable and store the associated details in linked records. Follow any applicable identification requirements separately.
Is a production date a sufficiently unique lot code?
Not necessarily. Several products, runs or sites can share the date. Test uniqueness within the intended scope and retain explicit mappings to supplier lots, receipts and outputs rather than assuming the date encodes all required relationships.
Sources and further reading
MarkdownExplore starter templates
Start with a useful checklist
English
