Food traceability often fails for a surprisingly ordinary reason: people are not using the same words.
One team calls a product “chilli sauce 2kg”. Another calls it “hot chilli catering tub”. The supplier uses a slightly different name. The recipe file has an old description. The stock spreadsheet shortens it to “chilli 2k”. The label template says something else again. Everyone knows what they mean — until someone has to trace a batch quickly, compare two records, or explain the answer to a customer.
This is the “Standardise” stage, and it is where many digital projects quietly succeed or fail. It is not glamorous. It will not impress anyone in a software demo. Yet it is the work that allows traceability data to become reliable.
Before a food producer thinks seriously about a digital traceability system, it should ask whether the basic language of the business is under control. Product names. SKU codes. Supplier names. Ingredient descriptions. Batch number formats. Date formats. Units of measure. Location names. Status labels. Recipe versions. Packaging codes. Customer names. These are the nuts and bolts of traceability. If they are inconsistent, every system built on top of them will wobble.
Confusion arrives through convenience
The difficulty is that inconsistent language rarely feels like a crisis. It builds slowly. A new customer wants a slightly different description. A product is reformulated but the old name remains in one spreadsheet. A supplier changes packaging. A member of staff creates a shortened code to save time. A second spreadsheet is made because the first one is locked. Nobody sets out to create confusion. The confusion arrives through convenience.
One product, one name
The first area to standardise is product identity. Each finished product should have one approved name and, ideally, one code used consistently across production, technical, warehouse, sales and dispatch. That does not mean customer-facing descriptions can never vary. A product may be described differently on a customer specification or label. But internally, the business needs one stable identity that ties records together.
Ingredients that hide in plain sight
The same principle applies to ingredients and raw materials. If an ingredient can appear under three names, it can also hide in three places during a trace. This becomes especially important for allergens, high-risk ingredients, short shelf-life materials, and materials supplied by more than one approved supplier. If “skimmed milk powder”, “SMP” and “milk powder skim” all appear in different records, the team may know they are the same today. But would a new starter know? Would an auditor accept the explanation without delay? Would a digital system match them automatically? Probably not without careful set-up.
Supplier names are another common source of drift. The trading name, legal entity, depot name and invoice name may not match. A supplier may be listed differently in accounts, purchasing, technical and intake records. During normal trading, this is irritating. During a traceability investigation, it can become genuinely unhelpful. Standardising supplier identity does not require a complex master data programme. It requires one approved supplier list and the discipline to use it.
Get batch numbers under control
Batch numbers deserve particular attention. Food producers often inherit supplier batch formats rather than design their own. That is normal. But once ingredients enter production, the business should be clear about how supplier lots link to internal production batches and finished product codes. If batch numbers are handwritten, are characters easy to misread? Is “O” confused with zero? Is the date embedded in a consistent way? Are shifts or lines included where they need to be? Can a finished batch be distinguished from a supplier lot? Can rework be linked back to its source?
Date formats can also cause avoidable trouble. The UK habit of day-month-year may meet systems or supplier documents that use year-month-day or month-day-year. A date that is obvious to one person may be ambiguous to another, particularly when data is retyped. In food production, ambiguity is rarely your friend. Standard formats reduce the risk of silent error.
Units of measure are just as important. Ingredients may be bought in cases, recorded in kilograms, issued in bags, used in grams and dispatched as finished units. That is manageable where conversions are defined, controlled and understood. It is risky when one spreadsheet uses cases and another uses kilograms without making the difference clear. Traceability is not only about identity; it is also about quantity. If you cannot reconcile what came in, what was used, what remains and what went out, your traceability story is incomplete.
Name your locations and statuses
Location names are another quiet source of uncertainty. “Chiller 1”, “main chiller”, “finished goods chiller” and “back chiller” may or may not refer to the same place. Temporary areas often have no formal name at all. Quarantine zones, returns areas, rework holding points and sample fridges need identities that the whole team recognises. A digital system cannot track a location that the business has never named properly.
Status labels matter because they govern decisions. “On hold”, “quarantined”, “awaiting inspection”, “released”, “rejected”, “blocked”, “pending technical review” and “for rework” should not be used casually or interchangeably. Each status should mean something specific. Who can apply it? Who can remove it? What evidence is needed? Can production use the stock? Can dispatch ship it? If the meaning is vague, the label becomes decoration rather than control.
This may sound like administration, but it is really risk reduction. Standard language reduces the number of times staff have to interpret, remember or translate information. It also reduces dependence on experienced individuals. A new person can follow a clear code more easily than a local nickname. An auditor can review consistent records more quickly than a set of explanations. A customer can have more confidence in a producer that can answer precisely.
Standardisation also makes future software far easier to brief. Many producers discover too late that software implementation is slowed not by the technology, but by unresolved naming and coding decisions. The supplier asks for product lists, units, locations, users, batch formats and process rules. The business then realises that these exist in several conflicting forms. What was sold as a digital project becomes a master data clean-up under time pressure.
It is better to do the clean-up before the pressure arrives.
Start small, one product family
Start small. Choose a product family and create a simple standardisation table. For each product, record the approved internal name, SKU, pack size, unit of measure, shelf-life rule, label reference, recipe version and any customer-specific descriptions. Then do the same for key ingredients: approved name, supplier, supplier code, internal code, allergen status, unit, storage condition and batch capture requirement.
Next, look for duplicates. Duplicates are not always obvious because they may be almost the same rather than identical. “Tomato diced 10mm”, “diced tomatoes”, “tomato dice” and “tomato 10 mil” may be one material. Or they may not. That is precisely the point. The business should not rely on guesswork.
Crown one version as the truth
Once duplicates are found, crown one version as the truth. This phrase matters. Standardisation is not complete when you have spotted the duplicates. It is complete when the business has decided which version stays, which versions are retired, and how future changes will be controlled. Otherwise the old names continue to circulate in spreadsheets, labels, order forms and habits.
Ownership is important here. Someone must have authority over product data, supplier data, location data and batch rules. In a small business, that may be one person wearing several hats. That is fine. The danger is when everyone can create data but nobody owns it. Data without ownership decays. It becomes stale, duplicated and mistrusted.
Firm but not bureaucratic
Standardisation should be firm but not bureaucratic. The aim is not to bury a small producer in forms. The aim is to remove unnecessary interpretation from daily work. Good standards make life easier for busy people. They reduce questions, corrections and rework. They make training simpler. They make audits less theatrical. They make digital tools more likely to work.
This is also where British understatement is useful: standardisation is not exciting, but it is rather important. It is the difference between records that merely exist and records that can be joined together. It is the difference between a trace that depends on memory and a trace that follows a consistent thread.
For an SME food producer, the message is simple. Do not digitise inconsistent names, unclear codes and ambiguous locations. Standardise them first. The work may feel modest, but it is the groundwork for everything that follows.
A system cannot create one version of the truth if the business has never agreed what that truth is called.
Manager’s pain point
“One product has three names, two spreadsheets and four slightly different batch references.”
AI prompt to try
Review the following list of product names, ingredient names, supplier names, batch formats, units and storage locations. Identify duplicates, inconsistent naming, unclear codes and possible traceability risks. Then suggest a simple standard naming convention suitable for a small UK food production business.Why this helps
This prompt gives the manager a practical way to spot data inconsistency before it becomes a software problem. It helps create a cleaner foundation for batch tracking, stock control, audit evidence and future digital systems.
