What this is
What is a date coding verification?
What is a date coding verification?
A date coding verification is a line check that confirms the date code and batch code printed on a pack are present, correct, legible and in the right position, and that the code the coder is applying matches the batch actually running. It is done against the pack in hand, not against the coder's setup screen.
Why check the code separately from the label?
Label verification confirms the artwork is right for the product. Date coding verification confirms the variable data, the date and batch, printed onto that artwork at production is also right. A correct label with a wrong or illegible date still breaks traceability, which is why both checks are needed.
Who should carry out the check?
The operator running the line, at defined points: start up, after a changeover, and at a set interval through the run. It needs to be someone who can physically hold a pack up to the light and read it, not someone relying on the coder's display, because the display can be right while the print is not.
Scope
When is a date coding verification required?
This checklist verifies the code applied to the pack in hand. It sits next to, and is frequently confused with, the checks that verify the artwork and the packaging material feeding the line, which cover different failure points.
Use this template when
- A production run is starting and the coder needs to be confirmed against the batch before packs leave the line
- A changeover has occurred and the previous product's code needs to be confirmed clear before the new one starts
- The periodic interval check during a run is due
- A complaint or trace request has raised a question about whether the code on a specific pack is genuine
- The reject system or vision system status needs to be recorded as part of line start up
Do not use it for
- Label Verification Record, which verifies that the label on the line matches the specification for that product, covering allergens, claims, dates and barcodes as a set, before this check verifies the variable print on top of it
- Artwork Approval Record, which approves new or amended artwork before it is printed, and has nothing to do with what a specific coder applies at run time
- Packaging Material Inspection, which inspects incoming packaging for damage, contamination and food contact compliance before it ever reaches the coder
- Shelf Life Study Record, which establishes the shelf life the date code is calculated from, rather than checking that a code already applied is correct
- Mock Recall Record, which tests whether miscoded or affected product can be traced and withdrawn once it has already left the check point
Compliance mapping
Which BRCGS cl.5.2 requirements does this satisfy?
Date and batch coding sits inside product labelling and traceability requirements rather than as its own named clause, so the print is covered by the labelling requirement and the trace-back by the traceability requirement separately.
| Clause | Requirement | Where it lands |
|---|---|---|
| BRCGS cl.5.2 | Product labelling, including variable date and batch information, must be legally compliant, accurate and applied to the correct product | Code content |
| Codex CXS 1-1985 sec.4.7 | Date marking on prepackaged food must state the date in the prescribed form and be calculated against the product's determined shelf life | Code content |
| BRCGS cl.3.9 | Traceability system able to identify and trace product one step forward and back via batch or lot coding | Code content |
| BRCGS cl.6.4 | Calibration and control of measuring and monitoring devices, extending to coding and inspection equipment used to verify print quality | Print quality |
| BRCGS cl.5.6 | Product release procedures preventing non-conforming product, including miscoded product, from being despatched | Control |
| BRCGS cl.3.11 | Management of incidents and product withdrawal, including identification of the quantity and location of affected product | Control |
| BRCGS cl.3.7 | Internal audit and verification activities confirming that recorded checks were actually completed, not only scored | Result |
What it does not cover
- Label Verification Record, which checks the fixed artwork, allergen declaration and claims against specification, a different failure point from the variable print covered here.
- Artwork Approval Record, which approves new or amended artwork before it goes near a coder.
- Shelf Life Study Record, which sets the shelf life duration the date code is calculated from, and is not re-derived by this check.
- Mock Recall Record or Recall Plan, which test and define the actual withdrawal once miscoded product has left this check point.
- Packaging Material Inspection, which covers packaging arriving undamaged and food-contact compliant before the coder ever touches it.
Global
Date Coding Verification requirements by country
No jurisdiction runs a standalone date-coding law; the duty sits inside general food labelling and traceability rules, with the practical detail carried by certification schemes.
FDA food labelling rules; USDA-FSIS for meat and poultry; no federal open-dating mandate outside infant formula
Most product dating in the US is voluntary, governed by state law or retailer requirement rather than a single federal rule.
A miscoded date is rarely a direct federal violation, but it is a misbranding and traceability exposure, and a certification non-conformance under any GFSI scheme the site holds.
Food Information Regulations 2014, implementing Regulation (EU) 1169/2011 on date marking
Use-by and best-before dates are legally mandated on relevant categories, with defined rules on what may and may not be altered after the fact.
An incorrect use-by date is a food safety and legal labelling failure, not just an internal quality miss, and enforcement runs through trading standards and environmental health.
BRCGS Global Standard for Food Safety; Codex Alimentarius general standard for labelling
Certification schemes require date and batch coding to be verified as part of product control and traceability, applied consistently across issue versions.
Auditors expect a documented, repeated verification record, not a one-off setup check, and will ask for the record covering the specific batch under trace.
How to complete it
How to complete a date coding verification, step by step
The checklist prompts for yes and no answers at each check point. What makes the record defensible is what stands behind those answers.
A correct-looking date proves nothing about how it got there. The record needs the date derived from the production date and the approved shelf life, and where entry is manual, that derivation should be visible, not assumed because the number matches expectation.
A code passing under line lighting on a dry pack has been verified for the easiest condition it will ever face. Chilled product needs the condensation check, and rough handling needs the rub resistance check. Skipping these because the code looks fine today defers the failure to somewhere harder to trace back.
A coder pulling its date directly from the production order removes the operator as a source of error; a wrong date there is a system fault. A manually set coder makes every entry a human input needing a second check, and a record that does not distinguish the two treats controlled and uncontrolled process as equally reliable.
Recording that a coding error reached product is the start of the entry, not the end. The quantity affected and where that product is now are what make the record usable for a hold decision; stopping at the yes/no flag documents that something happened without saying what to do about it.
What auditors find
Most common date coding verification findings
The check is simple enough that it is almost always run. The findings are about what the record proves once an error is traced back to it.
| Finding | Clause | What fixes it |
|---|---|---|
| Date code marked correct without evidence it was calculated from the production date and approved shelf life. | BRCGS cl.5.2 | Recalculate the expected date independently against the shelf life table before comparing it to the pack. |
| Legibility passed with no check for rub or condensation resistance on a chilled or heavily handled line. | Codex CXS 1-1985 sec.4.7 | Add rub resistance and condensation checks for product that is chilled, frozen or handled through multiple touchpoints. |
| Coder set to manual entry with no record of a second person double-checking the date. | BRCGS cl.6.4 | Require a documented second check on any manually entered date before the line is released to run. |
| Previous product's code not confirmed cleared before the next product's coding began. | BRCGS cl.3.9 | Make code clear-down a mandatory, verified step in the changeover sequence, checked before start-up, not after. |
| Coding error reached product, but the quantity affected and product location were left blank because those fields are not marked required. | BRCGS cl.3.11 | Enforce quantity affected and product location as mandatory once the error flag is set to yes, not left to judgement. |
| Verification pass rate reported high on a record with a low completeness score. | BRCGS cl.3.7 | Report completeness alongside the pass rate and treat a partially completed record as unverified, not as a high score. |
Case in point
Case in point: the code that was right on the box and wrong in the batch
A dairy plant ran a changeover from cream cheese to yoghurt on the same filling line. The verification at start up confirmed the new product's date code was present, correctly formatted and legible, and the operator signed it off within the target window. What the check did not catch was that the coder had not been repointed at the new production order, so it was still applying a batch reference from the cream cheese run that had just finished.
The batch code looked entirely plausible, formatted correctly and printed cleanly, which is exactly why nobody flagged it. It was only picked up three days later when a customer complaint referenced a batch number that traced back to a product that, on paper, had already finished its run an hour before the yoghurt started.
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-091
- Archetype
- Checklist
- Record ID
- DCV-2026-000
- Scoring
- Verification pass rate
- Direction
- High is good
- Singleton
- Yes
- Basis
- BRCGS cl.5.2
- Links
- Links Traceability, Changeover
- Tags
- Labelling, Coding
- Sections
- 5
- Fields
- 51
- Follow up fields
- 6
- Repeating sections
- 0
- Links out
- 3
Header
16 fieldsVerification ID*
Auto sequence. Format DCV-2026-000.
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*
Illegible Breaks Traceability Just As Completely
A code that cannot be read at the customer is the same as no code when a withdrawal is called. Check legibility, not just presence.
Check Point*
Coder Reference
Packs Checked*
Code content
6 fieldsDate Code Present*
- Yes3 pts
- No0 pts
Date Code Correct*
Calculated from the production date and the approved shelf life, not typed from memory.
- Yes3 pts
- No0 pts
Shelf Life Applied Correctly*
- Yes3 pts
- No0 pts
Batch Code Present*
- Yes3 pts
- No0 pts
Batch Code Matches Production Record*
- Yes3 pts
- No0 pts
Time Or Shift Code Present
- Yes3 pts
- Not required3 pts
- No0 pts
Print quality
6 fieldsCode Legible To The Naked Eye*
- Yes3 pts
- Marginal1 pt
- No0 pts
Code In Correct Position*
- Yes3 pts
- Marginal1 pt
- No0 pts
Code Contrast Adequate*
- Yes3 pts
- Marginal1 pt
- No0 pts
Code Rub Resistant
Codes that survive the line and fail in a chilled distribution chain are a common complaint source.
- Yes3 pts
- Marginal1 pt
- No0 pts
Code Survives Condensation
- Yes3 pts
- Marginal1 pt
- No0 pts
Vision System Verifying
- Yes3 pts
- Fitted, not in use1 pt
- None0 pts
Control
10 fieldsCoder Locked To Production Order*
Where the coder takes its date from the production system, an operator cannot type the wrong one.
- Yes3 pts
- Partly1 pt
- Manual entry0 pts
Manual Entry Double Checked
- Yes3 pts
- No0 pts
Previous Code Cleared At Changeover*
- Yes3 pts
- No0 pts
Reject System Working
- Yes3 pts
- Faulty0 pts
- None fitted1 pt
Uncoded Packs Found*
Miscoded Packs Found*
Coding Error Reached Product*
- 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.
Result
13 fieldsItems Assessed*
Excludes anything marked N/A.
Items Failed*
Score Percent*
Calculated on submission. High is good. N/A items leave the denominator.
Result Band*
- Pass3 pts
- Caution1 pt
- Fail0 pts
Completeness Percent*
How much of the template was actually answered. A high score on a half completed form is not a high score.
Action Required*
Raise the action record, then enter its reference here.
- No2 pts
- Yes0 pts
Priority
- High0 pts
- Medium1 pt
- Low3 pts
CAPA ID
Format CAPA-2026-00000.
Links to FDN-014 CAPA ID
Action Owner
Operator*
Signature*
Line Lead*
Second Signature*
QUA-091 · record IDs look like DCV-2026-000 · Links Traceability, Changeover
Open in KnowellaRun it with agents
From a document you fill in to a programme that runs itself
The check itself takes a minute. What fails afterwards is the hold that never gets raised, the coder left unlocked from the last changeover, and the trend nobody notices until a complaint forces a look back.
Holds the date coding verification record against the batch and hold registers, and chases the Hold ID when a coding error is flagged but never followed through.
Tracks coder calibration and vision system service history, so a legibility failure can be matched against when the equipment was last serviced.
Connects the manual-entry double-check requirement to the training record for coder operation, so it is a verified competency rather than an assumption.
Watches for coding errors that reach product without a completed Hold ID, and raises the trace before it becomes a customer complaint.
This template lives in KnowQuality — quality and food safety. HACCP, nonconformance, traceability, laboratory and customer complaints.
Meet KnowQuality→Glossary
Date Coding Verification definitions and key terms
- Date code
- The printed use-by or best-before date on a pack, calculated from the production date and the product's approved shelf life.
- Batch or lot code
- The printed reference tying a pack back to the specific production run it came from, used for one-step traceability.
- Coder lock
- A coder configured to take its date and batch data directly from the production order, removing manual entry as a source of error.
- Rub resistance
- A code's ability to stay legible after handling and abrasion through packing and distribution, not just at the point of print.
- Uncoded or miscoded pack
- A pack that left the coder without a date or batch code, or with one that does not match the production record for that run.
FAQ
Frequently asked questions about date coding verification
How is date coding verification different from label verification?+
Label verification confirms the fixed artwork, allergen statement and claims are correct for the product. Date coding verification confirms the variable print, the date and batch, applied to that label is also correct. A pack can pass label verification and still carry a wrong or illegible date, which is why both checks exist.
Should the date be checked against the coder's display or the pack itself?+
The pack. The coder's display shows what it was told to print, not what it actually printed. Faults in the print head, ribbon, or laser can produce a correct setup and a defective result, so the verification has to be a physical read of the pack, not a screen check.
What counts as a legible code?+
Readable to the naked eye, in the correct position, with adequate contrast, and still readable after the handling and storage the product will actually go through. A code meeting the first three only under bench lighting has not been verified for a chilled or heavily handled product.
What should happen if a miscoded pack is found?+
The record needs to capture that an error occurred, how many packs are affected, and exactly where that product is now, then route to a hold record. A flag with no quantity and no location cannot support a hold or trace decision, which defeats the purpose of catching the error.
How often should this check run?+
At start up, at every changeover, and at a set interval through the run, plus end of run. Start up and changeover catch the failures that matter most, a wrong or leftover code from the previous product, while the periodic check catches drift in print quality.
Does a vision system replace the manual check?+
It reduces the risk but does not replace the record. A vision system verifies print consistency at speed in a way a person cannot, but it needs to be confirmed as fitted and in use, not assumed, and its status is itself part of what this check records.
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
Lot Coding Verification
Confirms the lot or date code printed on product is correct and readable
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
More in Packaging and Labelling
Label Verification Record
Verifies that the label on the line matches the specification for that product, covering allergens, claims, dates and barcodes
Artwork Approval Record
Records approval of new or amended artwork before it is printed, with each checker named
Packaging Material Inspection
Inspects incoming packaging for damage, contamination, correct print and food contact compliance
Packaging Reconciliation Record
Reconciles packaging and label quantities issued, used and returned at the end of a run
Seal Integrity Test Record
Records seal strength, burst or dye testing on packs, with the result against specification
Pack Weight Control Record
Records average and individual pack weights against legal and specification limits
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:
- BRCGS Global Standard for Food Safety, clauses 5.2, 3.9, 3.11, 5.6 and 6.4
- Codex Alimentarius CXS 1-1985, General Standard for the Labelling of Prepackaged Foods, section 4.7
- Regulation (EU) 1169/2011 on the provision of food information to consumers, as implemented by the Food Information Regulations 2014 (UK)
- FDA guidance on food product dating (US)
This page is general guidance, not legal advice. Confirm requirements with your jurisdiction’s regulator.