How to design a batch record that is both the work instruction your floor runs from and the traceability link tying the exact ingredient lots a batch consumed to the finished lot it produced.
Do these first
Real help from real food people
Chef Diego runs a real food plant. If this page didn't get you there, tell us — a person reads every message.
After this lesson you can design a batch record that does two jobs at once — tell the floor what to do, and capture what was actually done, with the specific ingredient lots that went in and the finished lot that came out — and capture it as the work happens, so a finished lot traces back to its inputs from the record alone. It helps to have turned a recipe into a bill of materials first, and to have your incoming material already tied to lot and date codes, though you can build the record either way.
The bill of materials from the last lesson tells a batch what it should consume: this material, this quantity, this unit. It is a plan. It is the same for every run of the product.
A is the other half. It is written for one specific run, and no two are identical, because no two runs consume the same lots. Where the BOM says "45 lb of peppers," the batch record says "45 lb of peppers from lot PEP-5512, weighed by Ana at 9:40." The BOM is what should happen; the batch record is what did.
That is why a batch record is two documents wearing one cover. Read forward, it is a work instruction: the steps, in order, with the checks to make and the limits to hit. Read afterward, it is a traceability record: proof of which lots were consumed, in what amounts, by whom, to produce which finished lot. Most operations already have the first half — a sheet the floor works from. The value is in making the same sheet carry the second half, so the act of running the batch is also the act of recording it.
Strip a good batch record down and it holds five things. The first four are the work; the fifth is the whole point of writing it down.
A header that names the run
The product, the batch's own code, the date, the line or kettle, and the operator. This is the identity of the run — the thing every other line on the record hangs off.
Every ingredient lot actually consumed
Not "peppers" but "peppers, lot PEP-5512, 45 lb." One line per material, each naming the specific supplier lot the floor drew from and the quantity taken from it. If two lots of the same ingredient fed the batch, both get a line. This is the part a plain recipe never carries and the part a trace lives or dies on.
The process steps and in-process checks
The ordered work, and the readings taken along the way — a temperature at a cook step, a pH after mixing, a fill weight — each with the value observed and the person who took it. A check nobody signed is a check nobody can stand behind later.
Who did it, and any deviation
Initials against the steps that need them, and a plain note wherever the run departed from the plan: a substituted lot, a re-weigh, a hold. The deviations are not failures to hide; they are the record telling the truth about what happened.
The finished lot the batch produced
The output's own lot code and the count of good units it yielded. This is the run's product — the thing you will ship, and the thing a recall will name. Tying it to the four items above is what turns a work sheet into a link.
If you carry SQF certification, this is not just tidy practice. Edition 9 of the SQF Food Safety Code, clause 2.6.1, requires you to identify raw materials, ingredients, packaging, , and finished products through every stage of production. Clause 2.6.2 requires records of material receipt and use, plus finished-product dispatch — and "use" is exactly what the ingredient-lot lines above capture. The batch record is where that identification lands on the floor.
A course earlier in this track drew a line between a lot-number field and real traceability. The lesson on why a lot-number field is not traceability named three seams where the chain breaks, and the middle one was production: the batch record names the recipe and the date but not the exact lots consumed, so a recall on one incoming lot becomes a recall on everything made that week.
The batch record is that seam. It is the one place in your whole operation where inputs stop being inputs and become a new product — the . Everything before it points forward to this moment; everything after points back to it. Which means the link that holds together is written here or it is written nowhere.
For a food on FDA's Food Traceability List, that link is not just good practice — it is federal law. Under 21 CFR 1.1350, when you transform a listed food you must keep records linking the traceability lot codes of the inputs to the new code you assign the output, along with the quantity used from each input lot. A is minted at only a few moments, and under 21 CFR 1.1320 transformation is one of them — shipping and receiving carry a lot's code forward, but transformation gives the output a brand-new one. So the finished lot on your batch record is a new identity, born at the batch, and the rule wants it tied to the inputs that made it. The lesson on what FSMA 204 asks you to record works through that requirement in full; the point here is narrower: the batch record is the document where the transformation link gets written, whether the rule reaches your product or not.
Here is where a batch record is won or lost, and it has nothing to do with what fields are on the page.
A record can be filled in two ways. You can capture each line as the work happens — write the lot when you open the tote, the reading when you take it, the finished count when you tally it. Or you can run the batch and reconcile at the end of the day, filling the sheet from memory, the scale's tape, and whatever the crew remembers. The first produces a record you can trust. The second produces a record that exists.
The gap between them shows up the instant two lots are open at once. Say two totes of peppers were on the floor that morning — lot PEP-5512 and lot PEP-5513 — and the batch drew mostly from the first and topped off from the second. Capture it as you weigh, and the record names both lots against this batch, cleanly. Reconstruct it at shift's end, across three batches you ran that day, and you are guessing which tote fed which batch. Guess wrong, or refuse to guess, and a recall on PEP-5513 now reaches every batch you made that day — because you can no longer prove it didn't reach any of them. The record that was supposed to narrow a recall has widened it.
Reconciled records fail the standard too. SQF's records clause, 2.2.3.2, asks that records be confirmed by the people who did the monitoring — a signature that the check was actually made, when it was made. A sheet backfilled at day's end by someone who wasn't at the kettle is not that.
Software built for food captures each ingredient lot against the batch at the moment it is consumed, and records the finished lot the batch produces — so the link is built as the work is logged rather than reconstructed afterward. Bettr Manager, the operations platform this site is part of, works that way; it is one way to make running the batch and recording it the same act, not the only one. A disciplined paper batch record with real cross-references reaches the same place — it just takes far more hand-work to keep the lots honest as the shift moves.
The test of a batch record is simple: hand it to someone who wasn't there, and see if they can walk the trace without asking a single question.
The codes here are made up to show the shape. Say a batch record for a hot pepper sauce reads:
From that one record, the backward trace answers itself: finished lot SAUCE-2607-14 was made from pepper lot PEP-5512, vinegar lot VIN-3301, and salt lot SLT-0088 — nothing else, and in exactly those amounts. If any supplier calls about any of those three lots, you can name the finished lot it reached without reconstructing anything.
The forward trace — which customers got SAUCE-2607-14 — is not on the batch record, and that is correct. That link lives on your shipping records, the third seam from the traceability lesson. The batch record's job is the middle link, the one only it can hold: inputs tied to the finished lot. Receiving ties each incoming lot to a code, the batch record ties those lots to the finished lot, and shipping ties the finished lot to the customer. Three records, one chain — and the batch record is the hinge in the middle.
One thing the record so far does not do: prove that a cook or cool step actually hit its limit before the batch moved on. The in-process checks above capture the reading, but capturing a reading and gating on it are different things — a batch can carry a failed temperature and still ship if nothing stops it. The next lesson takes on exactly that: the CCP log that won't let a step advance until its reading is in-limit. First, build a batch record you can trace from.
Do this in your operation