Food Traceability Software for Fresh Supply Chains

A sourcing calendar records what you planned to buy, from whom, and when. Fresh food doesn't stay on that plan. Growing regions shift, a grower's lot fails inspection, or a buyer pauses a region, and the calendar stays wrong until someone retypes it. Our position is direct. If you supply fresh product, you need food traceability software in the supply chain that tracks the current state of every lot and every supplier, keyed on exact identifiers and checked by deterministic code. Build it as a module that runs alongside your ERP. Don't attempt a replacement project to get it, and don't add another spreadsheet tab.

Taylor Farms' seasonal sourcing halt is the reason this topic is in the news. We don't have inside knowledge of how Taylor Farms made that decision or what its systems showed, and we won't guess. The general lesson holds for any fresh supplier. When a sourcing decision changes mid-season, the cost depends on how fast you can answer three questions. Which lots came from the affected source? Where did those lots go? Which open orders now depend on supply you no longer have? A calendar can't answer any of them. A spreadsheet answers them slowly and with mistakes. A system built on your actual lot and order data can answer them in minutes.

What a Manual Sourcing Calendar Actually Knows

A sourcing calendar is a forecast. It says that a crop comes from one region in these weeks and moves to another region in those weeks, with these growers as primary and those as backup. That knowledge matters, and the people who maintain the calendar usually carry far more in their heads than the file holds.

The calendar can't track three things:

• Lot-level reality. It plans by crop and week. Recalls, holds and audits happen at the level of a traceability lot code.
• What's already committed. It doesn't know which customer orders consume which supply, so it can't tell you who gets shorted when a source goes dark.
• Change over time. Every update overwrites the previous plan. Nothing records what you believed last Tuesday, so you can't reconstruct why a decision was made or measure how often the plan held.

In practice, the calendar works until something changes, and change is the normal condition in fresh food. A sourcing halt, a weather event, or a grower who fails an audit turns the calendar into a historical document. The team rebuilds the real picture by hand from email, phone calls and the ERP.

What Food Traceability Software in the Supply Chain Has to Do

Food traceability software is a system that records each critical event in a food lot's life (growing, receiving, transformation, shipping) along with its identifiers, and that can trace any lot one step back to its source and one step forward to its recipients on demand. For fresh suppliers, a second requirement sits on top of that. The same data has to support supplier-risk decisions, because you can't judge a supplier's risk without its lot history.

The FDA's Food Traceability Rule under FSMA Section 204 gives a useful vocabulary even if you aren't yet working toward it. The rule organizes records around Critical Tracking Events (CTEs) such as harvesting, cooling, initial packing, shipping, receiving and transformation. It ties each event to Key Data Elements (KDEs), with the traceability lot code as the anchor. Covered firms must be able to give FDA an electronic, sortable spreadsheet of the relevant records within 24 hours of a request. No calendar can meet that requirement. A shared drive full of grower PDFs can't meet it reliably either.

A working system has five jobs:

1. Capture events as they happen, from every channel your suppliers and your floor actually use.
2. Key everything on exact identifiers: lot codes, supplier IDs, item numbers, location IDs.
3. Validate each record deterministically against your master data before it counts.
4. Link supply to demand, so every lot connects to the open orders and shipments that use it.
5. Aggregate across records, so a pattern spread over dozens of lots becomes visible as one supplier-level fact.

Most of the hard engineering sits in the last two jobs. They're also the jobs that a generic traceability add-on to an ERP tends to handle worst.

Exact Identifiers or Nothing

Traceability fails when two records that look similar get treated as the same record. Two lot codes that differ by one character are two different lots. A grower name that appears inside a packer's name is a different company. During a recall, a system that decides two things are probably the same has given you a wrong answer.

We learned this rule from our own work on customer matching, where the stakes are lower than a food recall. In one order pipeline, the same failure (an order booked to the wrong customer) came back five times in five different forms. One was a shared portal domain. One was a shared network domain. Then came an affiliate's email address, a semantic embedding match, and finally a brand token embedded inside another company's name. One of those paths sat dormant until a data backfill switched on the code that used it. Each fix we tried in replay repaired some cases and broke others. A first gate we built to catch the problem flagged mostly good orders, so we killed it in replay before it reached production.

The rule we ended up with is the one we'd apply to every traceability system: exact identifiers outrank similarity, and fuzzy matching only suggests. If a receiving record carries a lot code that matches your data exactly, that match wins. If the code doesn't match, the system can propose candidates, but a person confirms the link before it counts. We wrote up the full sequence in why fuzzy matching must never book a customer order. For lot linkage, the same principle carries even higher stakes.

Your Suppliers Send Data in Every Shape

Here's the practical obstacle to real-time traceability. Your largest trading partners may send structured EDI. Your growers, packers and smaller suppliers send PDFs, emailed spreadsheets, photographed bills of lading and free-text notes. Someone keys those in by hand, or they never get keyed at all. The lot data you need most often arrives in the formats your systems handle least.

Template-based document capture doesn't solve this. It depends on a fixed layout per sender and breaks when a sender changes its layout, which small suppliers do without notice. Hand-coded rules for every sender bring back the old knowledge-acquisition bottleneck that Edward Feigenbaum described for expert systems in 1977: someone has to pull the rules out of an expert's head and code them one by one.

Our approach separates reading from deciding. A deterministic parser reads what it can. A language model reads only what the parser can't settle, and it extracts business meaning into a typed record: supplier, item, lot code, quantity, harvest or pack date, destination. Deterministic code then validates that record against your supplier, item and location data. An exact match in your own data outranks anything the model inferred. When a check fails, a person sees the source document and the reason. The model never writes to the ERP itself, and a separate downstream check compares what was entered against the source document. We call this approach semantic EDI and explain it in What Is Semantic EDI?. We've run this pattern in production for order-to-cash at High Caliber Line, where emailed orders become sales orders.

For a fresh supplier, the payoff is coverage. Traceability built only on the EDI channel leaves a gap exactly where your riskiest small suppliers sit.

Supplier Risk Is an Aggregate, and Nobody Aggregates by Hand

Supplier risk rarely shows up in a single record. It shows up as a pattern: a grower whose lots keep arriving with missing pack dates, a packer whose quantities keep differing from the shipping document, a region whose holds cluster in one month. Each record gets fixed when someone touches it. Nobody adds them up.

We've watched this exact failure in our own extraction system. A learned override mapped a generic charge line onto a real, valid product code that didn't belong on those orders. The code was legitimate. The mapping was wrong. It survived about ten months and touched 201 distinct orders and 247 charge lines. Throughout that period, a deterministic downstream comparison in our QC-Check stage kept flagging it by asking one question: is this line actually on the source document?

The human review layer worked one order at a time. Of the affected orders, 67 went through human review, and an audit found that none of those 67 still carried the bad line. The reviewers caught it every time they saw it. The other two-thirds or so never reached a person, either because they had no review coverage or because they were auto-closed. The edit log shows zero hand-edits for that code, because reviewers fixed it at approval rather than as a logged field change. Every individual correction was right, and nobody aggregated across orders. The pattern stayed invisible until someone looked across the whole set at once.

Supplier risk in fresh food fails the same way. Your receiving team corrects a missing lot code on Monday, a mismatched quantity on Wednesday and a late pack date on Friday, for the same grower. The individual corrections are fine. Without a system that rolls corrections up to the supplier level, the trend never reaches the person who decides whether that grower stays on next season's plan.

So a supplier-risk module needs to record every correction as data, including what was wrong, on which supplier's record, and what it was changed to. Then it needs to count those corrections by supplier, by item and by period. The counting is simple code. The hard part is capturing the corrections in the first place.

Plans and Dates Are Schedules, Not Facts

Sourcing calendars carry dates, and operators tend to treat those dates as facts. They're estimates that someone keeps moving.

We saw a version of this in an order pipeline, outside fresh food. The ERP's estimated ship date got re-baselined whenever schedules slipped. It almost never matched the customer's requested date, and the misses had no consistent direction. The in-hands date was missing on a large share of open orders. Order type, the field that encoded the service level, was present on essentially every order. The field everyone looked at was the least reliable one. The most reliable field was the one nobody thought of as a date. We covered this in more depth in ERP Ship Date Is a Schedule, Not a Fact.

Fresh sourcing has the same structure. The calendar's expected harvest window, the grower's promised pack date and the carrier's ETA are all schedules that get revised. A useful traceability and supplier-risk system stores each revision with a timestamp instead of overwriting it. That history lets you ask how often a supplier's promised dates held last season, and it gives you a record of what you knew when you made a sourcing call. When a halt hits, you can see which commitments rested on dates that were already slipping.

Automatic Decisions Need a Brake

Once lot data flows in cleanly, it's tempting to automate the downstream steps: auto-allocate supply to orders, auto-release holds when paperwork arrives, auto-switch to the backup grower when the primary slips. Some of that is worth doing. All of it needs a brake that someone built on purpose.

We learned that the hard way too. An automatic release for small orders looked clean at the approval gate. Then the floor sent most of those releases back for missing art and shipping instructions. The sent-back orders took far longer to re-approve than normal approvals did. Volume far exceeded the forecast, and the warnings the system produced had no one assigned to read them. We paused it, added a circuit breaker that trips on the send-back rate once it has a minimum sample, and re-enabled it for a narrow slice. The first day was clean.

For fresh food, the equivalent is an auto-release on held product or an auto-substitution of supply. Judge it at the next station. Did the receiving dock accept the lot? Did the customer reject the substitution? A gate that only checks whether paperwork exists will approve a lot whose paperwork belongs to a different lot. Also check whether your confidence scores mean anything before you gate on them. We measured one confidence score in our own stack as anti-calibrated: its top buckets needed fixes more often than its bottom ones. If a traceability tool tells you a lot match is "98% confident," ask to see how often its 98% matches turned out to be wrong.

Build It Beside the ERP, Not Inside It

The usual answer to this problem is to buy the traceability module your ERP vendor sells, or to replace the ERP with one that has stronger food features. Both answers force your operation to fit the software's model of how fresh supply works, and both carry the risk of a big cutover in the middle of a season.

We'd go the other way. Build the traceability and supplier-risk layer as its own module that reads from and writes to your existing systems, and run it in parallel with the current process until it proves itself.

That path has three practical steps:

1. Start read-only. The new module ingests receiving records, supplier documents and open orders, links lots to orders, and produces trace reports. Nothing it does changes the ERP. Your team keeps working exactly as before.
2. Compare against reality. For several weeks, check every trace the module produces against what your team reconstructs by hand. Mismatches are the backlog. Fix them in the module.
3. Promote one decision at a time. When the trace data has earned trust, let the module start making one narrow decision, such as flagging lots with missing KDEs at receiving. Add a circuit breaker and a kill switch before it goes live.

Two cautions from our own work apply directly. First, test a change by replaying it through the whole pipeline, not by calling one function in isolation. We once overstated an impact estimate because a later gate reversed some outcomes the function produced. Second, include negative controls in your test data. A cleanup rule of ours passed every check and then archived freshly customer-approved orders, because its test set had no cases it was supposed to leave alone. We switched it off with a kill switch, fixed it, and restored the affected orders the same day. In traceability, the equivalent mistake would be a rule that closes holds it should keep open.

We describe the parallel-run approach in Parallel Operation Deployment. It's the same pattern we use whenever a client needs new capability without stopping the operation that pays the bills.

What We'd Build First

If a fresh supplier asked us where to start, this is the order we'd recommend:

• Module 1: Lot capture across every channel. Ingest receiving records and supplier documents in whatever form they arrive. Extract lot code, supplier, item, quantity and dates into typed records. Validate against master data. Flag failures to a person with the source document attached.
• Module 2: Lot-to-order linkage. Connect every received lot to the orders and shipments that consume it, using exact identifiers only. This is the module that answers "who's affected?" when a source goes dark.
• Module 3: Correction ledger. Record every human correction to supplier data as structured data, and roll it up by supplier, item and week.
• Module 4: Supplier-risk view. Combine correction rates, date reliability and hold history into a per-supplier picture that informs next season's sourcing plan. At this point the calendar becomes an output of real data instead of a separate file someone maintains by hand.

Each module delivers value on its own, and each one feeds the next. You don't need all four to get through the next sourcing disruption. Module 2 alone changes how fast you can answer the question that matters most when supply stops. For the broader picture of how these modules fit into supply-chain operations, see our approach to AI for supply chain operations.

Where We Could Be Wrong

If your supply base is small, stable and mostly on clean EDI, a commercial traceability product configured well may serve you better than a custom module. The custom case gets stronger as supplier formats get messier, as the gap grows between how your operation works and how a packaged tool assumes it works, and as more of your risk sits with small suppliers who will never send structured data. If a vendor can show you lot-level linkage across your actual mix of PDF and EDI suppliers, using exact identifiers and with a measured error rate, take that seriously. We'd still run it in parallel before trusting it.

The Short Version

A sourcing calendar is a plan, and fresh supply changes faster than any plan. When a source halts, the suppliers who recover fastest are the ones who can trace lots to orders immediately and who already knew which suppliers were slipping before the halt. That takes a system keyed on exact lot identifiers, fed from every channel your suppliers use, checked by deterministic code, and built to aggregate the corrections your team already makes every day. Build it module by module, beside the ERP, and run it in parallel until it earns trust.

If your traceability still runs through a calendar, a shared drive and a few people who remember everything, let's map your lot flow and find the first module worth building. Book a discovery call.

---