Ask ten fresh produce operations to show you their lot codes, and you will see ten different formats. Some use a simple date code: 20251015. Others use a combination of plant line identifier and Julian date: PLT2-288-25. Some use customer-specific formats assigned by their retail buyer. Some use GS1 application identifiers. A few still use informal batch identifiers that make sense only to the person who assigned them. The variation is not a problem in itself. The problem is that none of these formats necessarily contain the information that FSMA 204's traceability lot code requirements expect a compliant lot identifier to support.
This post covers what a lot ID needs to do under FSMA 204, what information it should encode or reference, and how to think about designing or auditing your lot coding system for compliance.
What FSMA 204 Requires from a Traceability Lot Code
The FSMA 204 final rule (21 CFR Part 1, Subpart S) defines a "traceability lot code" as a descriptor that a food entity assigns to a food to identify the food for traceability purposes. The rule does not mandate a specific format. There is no requirement to use GS1 identifiers, no minimum character length, and no prescribed encoding scheme. What the rule requires is functional: the lot code must be unique enough that, when combined with the other Key Data Elements assigned to that lot, the traceability record can be used to identify the specific quantity of food represented by that lot at a Critical Tracking Event.
The practical implication is that the lot code does not have to encode all the information about the food by itself. It is a reference identifier that links to a record. But it does have to be unique within your operation (no two different lots should carry the same lot code at the same time), it has to be assigned at or before the first relevant CTE, and it has to appear consistently on all records, labels, and documents that reference that lot through the supply chain.
Why Many Current Lot Codes Fail in Practice
The failure mode we see most often is not that lot codes are too simple. It is that they are not unique across time or across origin. A date code of 20251015 seems specific, but if a facility receives product from three different growers on the same date and assigns the same date code to all three, the lot code is no longer uniquely identifying a specific supply chain origin. A recall query that asks "what happened to lot 20251015" cannot distinguish between three different grower relationships compressed into a single identifier.
Similarly, a plant-line identifier like PLT2-288 (Julian day 288, line 2) identifies a production run on a specific line and date, but does not encode anything about the source ingredient lot from which the production run was made. If a recall is driven by a contamination event at a specific grower, the downstream records need to connect the finished product lot back to the supplier lot that was used as input. A lot code that does not include or reference the input lot creates a gap in the backward trace.
Customer-specific formats are a special case. Some retail buyers require their suppliers to use a buyer-assigned lot format, often embedded in a case label specification. These formats are designed for inventory management and recall notification purposes on the buyer's side. They may not satisfy FSMA 204's KDE requirements for the seller, because the seller still needs to maintain their own traceability records with a lot code that links back to their supply chain, not just to the buyer's receiving system.
What a Compliant Lot ID Structure Should Include or Reference
Given the functional requirements above, a well-designed traceability lot code should encode or unambiguously reference the following elements. It does not have to encode all of them in the lot code string itself. Some can be captured in the associated record rather than the identifier. But the combination of lot code plus KDE record must make all of these answerable without requiring manual cross-referencing.
First, the immediate previous source. For a food entity that is receiving a covered food from a supplier, the lot code in the receiving record should link to the supplier's lot code for that food. This is often handled by carrying the supplier's lot code as a separate KDE field in the receiving record, with a distinct internal lot code assigned by the receiving entity. Both identifiers should be present in the record and linked to each other.
Second, the location or facility where the lot was packed, processed, or created. For grower-shippers, this is the harvest location and packing shed. For processors, this is the processing facility. The lot code or its associated record needs to identify this location specifically enough to isolate the production run.
Third, the date or date range of the activity that created the lot. For harvest lots, this is the harvest date or harvest window. For processed lots, this is the production date. A lot code that encodes only a date without a location identifier, or a location without a date, leaves the record incomplete.
Fourth, a way to distinguish between multiple lots created at the same location on the same date. If a packing facility runs three different grower lots through the same production line on the same day, each needs a distinct identifier. Adding a sequence number, shift identifier, or grower code suffix to the date-location combination is sufficient.
Handling Lot Transformation: When a New Lot Code Is Required
FSMA 204 defines the Transformation CTE as the point where one food is converted into a new food with a new traceability lot code. This is one of the more nuanced areas of the rule. If you combine multiple input lots into a single finished product, that finished product needs its own traceability lot code, and the records for the Transformation CTE must link the new lot code to all of the input lot codes that were used to create it.
The implication for lot code design is that your system needs to support multi-input lot linkages. A simple date-plus-line identifier for the finished product lot is not sufficient if the record does not also capture the input lot codes. When we build the traceability graph for a produce processor, each Transformation CTE node carries edges to all the input lot nodes that were consumed in that transformation event. The finished product lot code is the node identifier for the transformed lot, and the input lot codes are the upstream nodes connected to it.
This is where spreadsheet-based lot tracking tends to break down at scale. A spreadsheet can capture a finished lot code and a single input lot code in the same row. Capturing three to five input lots per finished lot, across hundreds of production runs per month, creates a data model that does not fit well into a row-based structure and becomes hard to query quickly in a recall scenario.
Assigning Lot Codes Consistently Across Partners
One practical challenge in multi-tier supply chains is that different entities in the chain assign lot codes at different points using different systems, and these codes need to be cross-referenced at every handoff. A grower assigns a harvest lot code. A packing shed creates a packing lot code that references the harvest lot. A distributor may assign its own shipment lot code that references the packing lot. By the time the food reaches a retailer, there can be three or four lot codes associated with the same physical quantity of food.
FSMA 204 does not require the supply chain to harmonize these codes into a single identifier. It requires each entity to maintain records that link their lot code to the immediately preceding and following entity's lot code. The chain of linkages is what creates traceability across tiers. What that means operationally is that your receiving records need to capture both your own internal lot code assignment and the supplier's lot code from their shipping documents. Both belong in the record. If a recall query starts at the grower's harvest lot code, the chain of records should allow an investigator to follow it forward through every intermediate lot code assignment to the retail distribution point.
A Practical Audit of Your Current Lot Code System
To assess whether your current lot codes are FSMA 204-ready, ask these questions. Can you take any lot code that appears on a current outbound shipping document and use it to pull the complete traceability record for that lot within 24 hours? Does that record include the immediate previous source lot code from your supplier? Does it include your facility location and production date? If you combined multiple input lots to create that output lot, does the record capture all of the input lot codes?
If any of those answers is uncertain, the gap is worth addressing now. Lot code design is one of the foundational decisions in a traceability program. Getting it right early avoids the more expensive work of retrofitting records that were created under an incomplete coding scheme.