What this is
What is a lot coding verification?
What is a lot coding verification?
A lot coding verification is a checklist confirming that the date, batch and time code printed on product is correct, matches the work order, and is physically legible and scannable. It checks the pack, not the record of what should have been printed.
Why is print quality checked separately from code content?
A code can be entirely correct in content and still fail as a traceability aid if it cannot be read or scanned. Contrast, position, rub resistance and scan grade are checked independently of whether the date and batch digits are right, because either failure alone breaks traceability at the point someone needs it.
Why does the check happen at multiple points, not just start-up?
A coder that prints correctly at start-up can drift, run low on ink or ribbon, or shift position as a line runs. Checking at start-up, changeover, periodic intervals and end of run catches the failure window that a single check at the beginning of the shift would miss entirely.
Scope
When is a lot coding verification required?
This checklist verifies the physical code, not the traceability data behind it or the decision to act on a failure. Using it to cover those verifies the wrong thing and leaves the actual gap unchecked.
Use this template when
- A production run has started, changed over, or reached a periodic or end-of-run check point
- A new coder or format has been set and needs verifying before the run is trusted
- A new record is needed; each one gets its own ID in the form LCV-2026-000
- You are running the Traceability and Recall programme and this check is one of its steps
- A linked job or work order needs this check to confirm the code applied matches it
Do not use it for
- Batch Traceability Record, which links the raw material lots and quantities behind a batch to its finished output, not what is physically printed on the pack
- Despatch Record, which records what left the site, when, on which vehicle and to which customer
- Trace Exercise Record, which records a practice trace on a selected batch, forward and backward, outside of a live mock recall
- Label or artwork approval, which confirms the code format and content were approved before the run, not that today's print matches it
- Anything outside KnowQuality, which belongs in the workspace that owns that process
Compliance mapping
Which FSMA requirements does this satisfy?
Lot coding sits at the exact point named regulation and certification schemes require a traceability lot code to be assigned, which makes the physical check of that code a direct compliance control rather than a general quality practice.
| Clause | Requirement | Where it lands |
|---|---|---|
| 21 CFR 1.1315 | A traceability lot code must be assigned at each critical tracking event and must be legible on the product or associated documentation | Header |
| 21 CFR 1.1315 | The traceability lot code must correspond to the specific event, date and location it represents | Code content |
| SQF 2.6 | Product identification and traceability must be verified and records maintained showing the check was performed and its result | Print quality |
| SQF 2.6 | Traceability must be maintained through all stages of production, including from raw material to finished, packed product | Across the pack levels |
| 21 CFR 1.1315 | Where a code cannot be verified as correct, the affected product must be identified and controlled pending investigation | Outcome |
| SQF 2.6 | Verification frequency and method for identification and traceability checks must be defined and followed | Header |
What it does not cover
- Batch Traceability Record, which needs the input lots, quantities and output destinations linked, not the print quality of the code itself.
- Despatch Record, which needs the vehicle, driver and delivery detail this checklist does not capture.
- Trace Exercise Record, which needs a timed practice trace against a target, not a check of a single code at a single point.
- Mock Recall Record, which needs the withdrawal decision and communication trail this checklist can trigger but does not itself contain.
- Label or artwork approval, which confirms the code format and content were approved before the run started, not that this run's print matches that approval.
Global
Lot Coding Verification requirements by country
The obligation to assign a legible, verifiable lot code is now specific enough in the largest food markets that a coding failure is treated as a traceability failure in its own right, not a minor quality defect.
21 CFR 1.1315 (Food Traceability Rule); 21 CFR 117 current good manufacturing practice
A traceability lot code must be assigned and legible at defined critical tracking events, and product identification failures fall within general good manufacturing practice.
For foods on the Food Traceability List, an unreadable or incorrect code is a direct rule failure once the compliance date applies, not just an internal quality miss.
Food Information Regulations 2014 (date marking); Regulation (EC) 178/2002 Art.18 (traceability)
Date marking must be present and accurate, and traceability records must allow the immediate supplier and customer of a lot to be identified.
An incorrect or unreadable date code is both a labelling and a traceability failure, which is why retailer audits check it independently of the paperwork.
SQF Code, module 2.6 (Traceability); GS1 barcode verification standards
Certification requires defined, followed verification of identification and traceability, and GS1 sets the technical grading used to assess scan quality.
A barcode that scans but grades poorly is still a risk, because downstream scanners in a customer's own system are not guaranteed to be as forgiving.
How to complete it
How to complete a lot coding verification, step by step
The checklist prompts for a series of yes-or-no answers. Whether the check actually protects traceability depends on how those answers are treated once a marginal or intermittent result appears.
Start-up, changeover, periodic and end-of-run each catch a different failure window: a coder set up correctly can still drift mid-run, and a check performed only at start-up shows a clean record for a run that degraded an hour in. Skipping the periodic check because start-up passed defeats the reason the interval exists.
Legibility, contrast and rub test all carry a marginal band precisely because a binary pass or fail would understate a real, developing problem. Treat marginal as a trigger for a coder or ribbon check before the next interval, not as a result equivalent enough to pass to let the run continue unchanged.
A unit, case and pallet can each individually carry a correct-looking code and still disagree with each other, which breaks the trace as completely as any single code being wrong. The cross-level check is the one most likely skipped under time pressure, and the one that catches the failure a customer complaint actually reports.
A code scanning only on a second or third attempt at goods-out, in controlled conditions, is a leading indicator of one that will fail outright further down the chain, in worse lighting or a colder environment. Recording the scan grade, not just pass or fail, gives the check resolution to catch degradation before it becomes a failure.
What auditors find
Most common lot coding verification findings
Findings on lot coding verification concentrate on results that sit between pass and fail being treated as pass, and on checks not repeated through the length of the run.
| Finding | Clause | What fixes it |
|---|---|---|
| Check performed only at start-up, with no periodic, changeover or end-of-run check recorded for a long run. | SQF 2.6 | Enforce the defined check interval in the schedule that raises the record, not as a discretionary extra. |
| Legibility, contrast or rub test recorded as marginal, with the overall check result still marked pass. | 21 CFR 1.1315 | Route a marginal result to a coder or consumable check before the run continues, and treat it as a fail overall. |
| Unit, case and pallet codes each recorded as present with no check of consistency between them. | SQF 2.6 | Make the cross-level consistency question mandatory whenever more than one pack level is coded on the run. |
| Barcode recorded as scanning, with scan quality grade left blank or not recorded. | SQF 2.6 | Capture the GS1 grade, not just a scan or no-scan result, so degradation is visible before it becomes a failure. |
| Product affected by a failed check identified, but no hold reference or product location recorded. | 21 CFR 1.1315 | Require a hold ID and current location the moment a check is marked fail with product affected. |
| Code matches work order recorded as no with no linked correction or investigation. | 21 CFR 1.1315 | Treat a work order mismatch as a stop-and-fix condition, not a data point to record and continue past. |
Case in point
Case in point: the code that scanned every time at goods-out
A cheese packer ran lot coding verification at start-up and at the two periodic intervals its schedule called for. All three checks recorded barcode scans on the first attempt, print legible, contrast adequate, and the unit and case codes agreeing with each other. The end-of-run check was skipped because the shift change overlapped with the end of the run. A retailer complaint arrived six weeks later: a pallet's case labels carried the correct date, but roughly a third of the units inside, from the last hour of the run, carried the previous day's code. The coder had drifted in the window the skipped end-of-run check existed to cover, and the case-level label had been applied from a batch of pre-printed cases rather than generated live, so it never reflected the drift at all.
The three checks that were performed were genuinely accurate; they simply did not cover the hour that mattered. The fix was not a stricter pass criterion; it was making the end-of-run check non-skippable regardless of shift handover, and flagging pre-printed case labels for their own verification against the unit-level code rather than being assumed correct because they matched specification.
The template
The template, field by field
The form exactly as it installs. Every field, option, score and conditional rule is editable, and the links to other templates come with it.
5 sections
- Reference
- QUA-074
- Archetype
- Checklist
- Record ID
- LCV-2026-000
- Scoring
- Pass or fail
- Direction
- High is good
- Singleton
- No
- Basis
- FSMA, SQF 2.6
- Links
- Links Job; feeds Traceability
- Tags
- Traceability, Labelling
- Sections
- 5
- Fields
- 42
- Follow up fields
- 3
- Repeating sections
- 0
- Links out
- 3
Header
16 fieldsCheck ID*
Auto sequence. Format LCV-2026-0000.
The record's own ID. Other templates point at this value.
Status*
Drives who this goes to next.
- Planned2 pts
- In progress2 pts
- Complete3 pts
- Deferred0 pts
- Open0 pts
- Closed3 pts
- Overdue0 pts
Date and Time*
Raised By*
Site*
Site ID*
Format SITE-000.
Links to FDN-001 Site ID
Line*
Shift*
Line Lead
Batch Number*
Numeric key joining to your ERP batch record.
Links to External system reference
Product*
Production Date*
Coder
Asset ID
Links to FDN-002 Asset ID
Check Point*
An Unreadable Code Is No Code
Traceability records are worthless if the code on the pack cannot be read by a customer or a consumer holding the product in their hand.
Code content
6 fieldsDate Code Correct*
- Yes3 pts
- No0 pts
Batch Code Correct*
- Yes3 pts
- No0 pts
Time Code Correct
- Yes3 pts
- Not used3 pts
- No0 pts
Code Matches Work Order*
- Yes3 pts
- No0 pts
Shelf Life Calculation Correct*
- Yes3 pts
- No0 pts
Format Matches Specification*
- Yes3 pts
- No0 pts
Print quality
6 fieldsPrint Legible By Eye*
- Yes3 pts
- Marginal1 pt
- No0 pts
Contrast Adequate*
- Yes3 pts
- Marginal1 pt
- No0 pts
Position Correct*
- Yes3 pts
- No0 pts
Rub Test Passed*
Codes that rub off in the chill chain are a common complaint source.
- Yes3 pts
- Marginal1 pt
- No0 pts
Barcode Scans*
- Yes, first attempt3 pts
- Yes, multiple attempts1 pt
- No0 pts
Scan Quality Grade
- A4 pts
- B3 pts
- C2 pts
- D or F0 pts
Across the pack levels
5 fieldsUnit Pack Coded*
- Yes3 pts
- No0 pts
Case Coded*
- Yes3 pts
- No0 pts
Pallet Label Coded*
- Yes3 pts
- No0 pts
Codes Consistent Across Levels*
A case saying one date and the units inside saying another breaks traceability entirely.
- Yes3 pts
- No0 pts
Photograph
Outcome
9 fieldsCheck Result*
- Pass3 pts
- Fail0 pts
Product Affected By The Check*
- No3 pts
- Yes0 pts
Quantity Affected
Hold ID
Raise the hold record, then enter its reference.
Links to QUA-003 Hold ID
Product Location
Where the affected product physically is right now.
Operator*
Signature*
Quality*
Second Signature*
QUA-074 · record IDs look like LCV-2026-000 · Links Job; feeds Traceability
Open in KnowellaRun it with agents
From a document you fill in to a programme that runs itself
The check itself is quick. What fails around it is the interval that gets skipped under shift pressure and the marginal result that gets recorded without anyone following it up.
Holds the lot coding verification schedule against the run plan, flags skipped check points, and routes marginal or fail results to an owner.
Takes a marginal print or contrast result back to the coder itself, so a drifting device is serviced before it produces an outright fail.
Watches for end-of-run checks skipped at shift handover and for scan grades trending down across a run, and raises the review before the pattern becomes a fail.
This template lives in KnowQuality — quality and food safety. HACCP, nonconformance, traceability, laboratory and customer complaints.
Meet KnowQuality→Glossary
Lot Coding Verification definitions and key terms
- Traceability lot code
- The code applied to a pack that identifies the specific production event, date and location it represents, used to link the pack back to its batch record.
- Legibility
- Whether a code can be read by eye under normal conditions, checked separately from whether its content is correct.
- Rub test
- A check of whether printed or applied code survives handling and transport without smudging or wearing off, particularly relevant in chilled and frozen chains.
- GS1 scan quality grade
- A graded assessment of barcode scan performance beyond a simple scan or no-scan result, used to catch degrading print before it fails outright.
- Critical tracking event
- A defined point in production, such as coding at pack or case level, where traceability data must be created and verified.
FAQ
Frequently asked questions about lot coding verification
Is a code that scans but grades poorly a pass?+
Not without qualification. A poor grade means the code is close to failing under slightly worse conditions than the ones it was checked in, and recording it as a simple pass discards the information that would have caught the failure early. Record the grade, and treat a low grade the same way a marginal legibility result is treated.
Why check the code against the work order as well as checking it is legible?+
A code can be perfectly printed and completely wrong, if the wrong date or batch was keyed into the coder. Legibility and content correctness fail independently of each other, and a check that only reads the code without comparing it to the work order will pass a confidently printed error.
What should happen when product affected by a failed check has already left the immediate area?+
Record its current location and raise a hold immediately, rather than waiting until the check record is reviewed. The gap between a failed check and a hold being raised is exactly the window in which affected product moves further into distribution.
Do unit, case and pallet levels really need separate checks?+
Yes. Each level is coded by a different device or process, at a different point in the line, and each can fail independently of the others. A consistent code across all three levels is what a downstream scan or a recall actually relies on, not the correctness of any one level alone.
How often should the check run through a shift?+
At start-up, at any changeover, at a periodic interval through the run, and at end of run. A coder that was correct at start-up gives no assurance about the last hour of a long run, which is precisely the interval a periodic and end-of-run check are there to cover.
How is lot coding verification scored?+
Pass or fail, where high is good. Treat a marginal individual result as a trigger for corrective action on the coder or consumables, not as a result that should be allowed to round up to an overall pass.
Keep going
Related templates and programmes
Industries this is written for
Programmes this belongs to
Used together in Traceability and Recall
Recall Plan
Sets out how product would be traced, held and recovered if it had to be recalled
Mock Recall Record
Tests the recall plan by tracing a real batch forward and back without actually recalling it
Batch Traceability Record
Links raw materials to finished product batches and on to customers
Despatch Record
Records what product left, when, on which vehicle and to which customer
Trace Exercise Record
Records a practice trace on a selected batch, forward and backward, outside of a mock recall
Date Coding Verification
Verifies date and batch coding is present, legible, correct and in the right position
More in Traceability
Written and reviewed by
Siddarth Singh
Founder & Chief Executive Officer, Knowella
Certified Safety Professional and industrial and systems engineer with more than a decade inside food supply chain, freight and manufacturing operations. This page was written against the current text of the standards it cites, not against secondary summaries of them.
- Certified Safety Professional (CSP), Board of Certified Safety Professionals
- MBA, University of Chicago Booth School of Business
- MS and BS, The Ohio State University, Industrial and Systems Engineering
- Six Sigma Black Belt
Sources and last review. Reviewed 16 August 2026 against:
- 21 CFR 1.1315 — Traceability Lot Code requirements under the FSMA Food Traceability Rule
- SQF Code, Edition 9, module 2.6 — Traceability
- Food Information Regulations 2014 (UK) — date marking requirements
- GS1 barcode verification and grading standards
This page is general guidance, not legal advice. Confirm requirements with your jurisdiction’s regulator.