Lot coding for produce: how to design codes that survive a recall

What the code has to do, and the two ways it fails

A lot code exists to answer one question fast: if this specific unit turns out to be a problem, what else is affected, and what is not? Everything about the design should be judged against that question. A code succeeds when it lets you draw a tight boundary around the affected product. It fails when the boundary is either too loose or too fine to use.

Too coarse is the more common failure, and the more expensive one. A packhouse that issues one lot code per week, or one per variety per month, is not really doing lot coding, it is doing batch coding at a scale that guarantees over-recall. If a single contaminated pallet forces you to pull every carton packed that week because they all share one code, you have converted a narrow, defensible recall into a plant-wide one. Coarse codes feel efficient at packing time because there is less to print and track, but they transfer the cost onto the one day you actually need precision.

Too fine is the less common but still real failure. A scheme that issues a new code per pallet position, per hour of the shift, or per individual picker creates thousands of codes a season that a receiving clerk has to key by hand, and hand-keyed long codes generate transposition errors at a rate that defeats the purpose. The right grain is usually one code per distinct receival or pack run within a shift, tight enough to bound a recall to hours of production, coarse enough to still be typed correctly under pressure.

The anatomy of a workable code

A good produce lot code answers two questions at a glance: when, and from what. A date-based prefix plus a daily sequence, for example R-260704-02 for the second receival on 4 July 2026, is readable on the dock without a lookup table. The prefix letter signals the operation type (R for receival, P for pack, in some schemes C for cold storage entry), the date block anchors it in time, and the sequence number disambiguates multiple events on the same day.

Resist encoding everything, grower, block, variety, grade, into the code itself. It is tempting, because in the moment it feels like the code is doing useful work by carrying that detail on its face. In practice, codes that carry too much meaning become long, error-prone to transcribe by hand, and wrong the moment something is re-graded or a mixed-grower receival gets split after the fact. The code should be a pointer, short enough to write on a carton and read back correctly, and the record behind it, held in whatever system issued the code, should carry the grower, block, variety, grade and every other attribute that matters for a trace. Keep the identifier and the metadata in separate places, and only one of them ever has to be perfectly accurate on the printed label.

Human-readable, barcode, or GS1: choosing the format

The same lot code can be represented three ways, and which one you need depends entirely on who is reading it. A human-readable string like R-260704-02 is enough for an internal receival log, a whiteboard, or a small buyer who keys lot numbers into a spreadsheet by hand. It costs nothing to produce and any staff member can read it without equipment.

A linear barcode encoding that same string speeds up warehouse scanning and cuts keying error, but it still only carries the one value you chose to encode.

A GS1-128 barcode is a different tier: it is a structured format that can carry multiple application identifiers in one symbol, commonly a Global Trade Item Number (GTIN) for the product, a batch or lot number, and a pack or best-before date, each in its own defined field. Retailers and larger foodservice buyers increasingly specify GS1-128 as a receiving requirement, not as a preference, because their receiving systems parse the application identifiers automatically rather than relying on a human to read a printed string correctly. If a buyer's vendor manual references GS1 standards, that is a receiving gate, not optional labeling advice: pallets without a conformant barcode get held or rejected at the dock regardless of whether the product itself is fine. Confirm the requirement directly against the buyer's own specification rather than assuming a format that worked for one customer will satisfy another.

Dates: the ambiguity that gets pallets turned away

Date formatting causes more rejected pallets than almost any other labeling issue, because the same six digits can mean three different things depending on convention. 040726 could be read as DD/MM/YY, MM/DD/YY, or YY/MM/DD, and a receiving clerk who reads it the wrong way will log a pallet as already past its expected shelf window, or flag it as dated in the future, either of which can trigger a hold. The fix is not to write the date more carefully, it is to remove the ambiguity structurally: use a fixed-length numeric format with the year first, YYMMDD or YYYYMMDD, so there is no locale-dependent reading of which segment is the day and which is the month. This is also the convention GS1 date fields expect, so a lot code built this way slots into a GS1-128 barcode without reformatting.

The same discipline applies to week-based dating, common where a buyer wants a shelf-life window rather than a single pack day. A YYWW format (year and ISO week number) avoids the ambiguity of a written date range and is straightforward to validate against a delivery window automatically. Whichever convention you pick, use it identically everywhere the date appears, the carton, the pallet tag, the packing list and the invoice, because a date that reads one way on the box and another way on the paperwork is exactly the kind of mismatch an auditor is trained to flag, even when nothing about the product itself is wrong.

Where the code has to appear, and what has to match

A lot code that exists only in your internal system is not doing its job. It has to physically travel with the product: printed on the carton label at the point of pack, on the pallet tag that summarizes what the pallet carries, and again on the packing list or delivery document that accompanies the shipment. Three places, minimum, and all three have to agree exactly.

This is where informal schemes quietly break. A carton gets relabeled by hand because the printer ran out of stock, a pallet tag gets written from memory instead of pulled from the system, or a packing list gets generated from a slightly earlier version of the pick than what actually loaded. Any one of those gaps means the code on the box does not match the code on the paper, and a buyer's receiving check, or your own mock recall, will find the mismatch immediately. The reliable pattern is to generate all three, carton label, pallet tag, and packing list, from the same system record at the same moment, rather than transcribing the code by hand at each stage. Every manual re-entry point is a place a transposed digit or a stale value can enter the chain.

Sequencing and reset rules

The daily sequence number in a code like R-260704-02 has to follow a rule that never produces a collision, and the common failure points are season rollovers and system restarts. If the sequence resets to 01 at the start of every day, that is fine as long as the date prefix changes with it, since the combination of date and sequence stays unique. Problems appear when a system is restarted mid-season, a new receiving terminal is added, or two sites share a numbering pool without coordination, any of which can produce a sequence that restarts from 01 while the date prefix is unchanged, silently duplicating a code already issued earlier that day.

The safe rule is to make the numbering authority a single system of record, not a habit followed by whoever is on the dock that shift. If receivals happen at more than one physical point, the sequence needs to be issued centrally, or each point needs its own reserved letter or number range, so two clerks working simultaneously never hand out the same code.

Surviving repacking, consolidation and mixed pallets

A code's hardest test is not the day it is issued, it is everything that happens to the product afterward. When received fruit is packed, the output is a new lot with a new code, and the critical discipline is recording which input lots fed it. That link is the trace chain. A pack run that consumes three grower lots and produces one packed lot must record all three parents, or a recall stops at the pack line with no way to say which of the three growers is actually implicated.

Consolidation, where product from multiple lots is combined onto one outbound pallet or shipment, needs the same discipline in the other direction: the pallet tag or shipping document has to list every lot code it carries, not just the dominant one. A mixed pallet with a single code on its tag is one where a recall cannot distinguish the affected lot from the others riding alongside it, forcing the same over-recall problem a too-coarse code produces at the receiving end. Repacking, splitting a lot across smaller pack formats for different customers, similarly has to preserve the parent link on every child lot, so a trace from any resulting carton still resolves back to the original receival.

Handwritten codes drift: transposed digits, reused sequences, formats that change mid-season. The reliable pattern is system-issued codes at the moment of receival and packing, printed straight onto carton and pallet labels, with every parent-child and consolidation link captured automatically rather than reconstructed from memory during a drill or a real event. Fernable issues date-sequenced codes automatically, enforces uniqueness at the database, and keeps the parent-child links, so the trace chain builds itself while the line runs.