Food Traceability Software Problems: The 7 That Widen a Recall, and How to Avoid Them

Why does traceability scope stop at receiving and shipping so often?

The commonest scope failure here is a project that instruments the dock at both ends and treats the middle of the plant as a black box. Receiving gets a handheld. Shipping gets a handheld. The wash line, the dice line, the blender and the pack line get nothing, because whoever wrote the scope was thinking about product movement, and at a dock the product identity does not change.

That failure is specific to food because transformation is where the traceability lot code is actually created. A distributor moving sealed cases can genuinely live with dock to dock capture: the lot that arrives is the lot that leaves. A processor cannot. The moment three supplier lots of romaine are washed, blended into one batch and packed into forty finished lots, the link between input and output exists only inside the plant. If you did not capture it there, it does not exist anywhere, and no amount of clever reporting later will reconstruct it.

The fix is to write the scope as a list of Critical Tracking Events rather than a list of screens. Walk the physical process with the quality manager and the line lead, mark every point where product is received, transformed, created or shipped, and require a named capture point for each. If a transformation appears in the process walk but not in the scope document, that is your future recall gap. Arguing about it in week two costs a meeting. Discovering it during a mock recall in month nine costs the project.

What goes wrong when you migrate historical lot and supplier records?

Teams assume the food ERP (Enterprise Resource Planning) export is the historical record. It is not. It holds receipts and shipments, while the batch sheets that connect them sit in photographed clipboards, the certificates of analysis sit as PDFs in a shared drive, and the supplier lot codes appear in five different formats because five different clerks typed them.

The trap unique to food is that you cannot backfill a genealogy graph you never recorded. Prior lots have no transformation links, so importing them into a genealogy schema produces records that look traceable and are not, which is worse than an obvious gap. Meanwhile the rule requires traceability records to be retained for two years, so the old data still has to be answerable during that window.

The fix has three parts. Migrate identity data properly: items, suppliers, ship-from locations, customers and unit conversions, deduplicated and normalised, because every future lot depends on them. Migrate pre-cutover transactional lot records as flat receipts and shipments, explicitly flagged as having no genealogy, so nobody mistakes them for traced product. Then keep the legacy system queryable for the full retention period and write down, before cutover, who runs a trace on a pre-cutover lot and how. Most of the migration effort goes into supplier lot code normalisation, so budget it as its own workstream.

Why do the ERP, WMS (Warehouse Management System) and label printer integrations break after launch?

The integration that fails is almost never the one that was hard to build. It is the lot sync with the food ERP, and it fails quietly. A developer maps the ERP lot field one to one onto the traceability lot code because on day one they look identical. That mapping holds until the first commingled batch, at which point one ERP lot corresponds to several traceability lot codes, and the sync starts creating duplicate lot records that nobody notices for a month.

The second failure is item master drift. Someone in purchasing adds a new SKU in NetSuite or Deacom without the traceability attributes, so product starts flowing through a code path that has no lot requirement, and the first sign is a hole in a trace. The third is label printing. Zebra and SATO integrations are stable until a printer is swapped or firmware changes, and a pack line that cannot print a lot code will keep packing.

The fix is ownership plus monitoring. Decide, field by field, which system is authoritative and never write back to the other, so there is no bidirectional loop to reconcile. Run a nightly divergence report that counts lots present in one system and absent from the other, and route it to a human rather than a log file. Alert when a new item appears in the ERP without traceability attributes, and alert when a printer has not confirmed a print in a shift. None of that is interesting engineering, and it is what keeps the genealogy honest six months after go-live.

What happens when the 24-hour FDA export is not genuinely covered?

Plenty of builds get the genealogy right and then treat the regulatory export as a reporting task for later. The Food Traceability Rule lets the FDA request an electronic sortable spreadsheet of your traceability Key Data Elements, and the clock is 24 hours. A team that has never run that export against real production data will find out under the clock that the ship-from location was captured as free text, or that the reference document number was never required at receiving, or that the export times out on a year of data.

This is specific to food because the required fields differ by event type. Receiving, transformation, creating and shipping each carry their own Key Data Elements, and a build that models one generic event with optional fields will pass its own tests and fail the actual request. Optional fields get skipped by busy people.

The fix is to make the export a first-class deliverable with its own acceptance criteria, exercised every month. Run a scheduled mock recall against a randomly chosen real lot, produce the sortable spreadsheet, and have somebody who did not build it try to break the output. Make each Key Data Element mandatory at its own event type rather than nullable, so the capture screen refuses an incomplete receipt at the dock instead of a report discovering it a year later. If your team cannot produce the file in under an hour today, the requirement is not covered whatever the specification says.

Should you build custom or configure what you already own?

Some readers should not build, and this is the honest boundary. If you are a single-facility distributor receiving sealed cases and shipping them without transformation, your food ERP's lot module plus a supplier document tool is genuinely sufficient. The lot that comes in is the lot that goes out, so there is no genealogy to reconstruct, and NetSuite, Aptean Ross, Deacom, BatchMaster or Sage will carry the receiving and shipping records you need. Add FoodLogiQ or TraceGains for supplier certificates and you have a defensible position for a short list of Food Traceability List items. Building a genealogy graph for a pass-through operation is over-engineering.

The line moves when transformation enters the picture. Configure first, and only build when two or more of these are true at once: your mock recall takes more than a day; your recall bracket is routinely wider than the actual exposure; you commingle or split lots so the one-in-one-out lot field no longer matches reality; you run more than one facility with different processes; or your team keys the same lot data into three systems every shift. Configuration exhausts itself at exactly the point where the ERP has no place to store the link between an input lot and an output lot, and no amount of custom fields creates one.

How do hidden costs get into the quote?

Quotes in this category understate the physical world. Handheld hardware, mounting, charging and spares for a plant floor are a real line item and get left to the client to discover. Label printer integration is quoted as one printer and delivered against six, each on a different line. Offline capture gets treated as a toggle when it is a design decision that touches every write path, and skipping it means the app is unusable in the cooler, which is where receiving happens.

Then there is supplier onboarding. A quote that includes a supplier portal rarely includes the effort of getting suppliers to use it, or the per-partner electronic data interchange mapping for the high-volume growers where a feed is worth it. GS1 EPCIS support appears late when a retail customer asks for it. A second facility is quoted as a copy of the first and is not. And training is quoted once when a plant runs three shifts.

The fix is a scoping conversation that names counts before price: how many facilities, how many capture points per facility, how many printers, how many suppliers on a feed versus a form, how many shifts, and whether any customer requires GS1 formats today. A vendor who quotes without those numbers is guessing, and the difference between the guess and reality lands on you as a change order.

What separates a build that works here from one that fails?

The builds that hold up share four habits. First, the data model is settled before any screen is designed, and it treats genealogy as a graph of transformation events rather than a lot field on an inventory row. Ask a candidate to whiteboard three supplier lots commingled into one batch and split into forty finished lots. If they reach for a flat lot column, they will rebuild the model twice on your budget.

Second, the plant floor is in the design sessions. The person who will scan in a freezer at 5am knows which pallets arrive with unreadable tags and which supplier sends handwritten packing slips, and that detail decides half the interface. Builds designed entirely in a conference room produce capture screens that crews route around, and a routed-around screen is a hole in the trace.

Third, the acceptance test is a mock recall, not a feature checklist. Pick a real lot, run the trace both directions, produce the FDA sortable spreadsheet, and time it. Repeat it monthly forever. Fourth, one facility goes to production and runs a full season before the second one starts, so you learn what the model got wrong while it is still cheap to change.

Finally, settle ownership in writing before kickoff: the repository, the schema and the hosting accounts are yours from the first commit. In this domain the genealogy graph and the regulatory export logic become evidence during a recall, and renting the ability to change them is a poor position to be in the week an inspector calls.