KDE – Key Data Elements (FSMA 204)

This glossary term is part of the SG Systems Global regulatory & operations guide library.

Updated January 2026 • FSMA 204 traceability rule, Key Data Elements (KDEs), Critical Tracking Events (CTEs), lot code linkage, event-time capture, 24-hour record response, EPCIS alignment, receiving & shipping KDE capture • Primarily Food Supply Chain Traceability (high-risk foods, compliance-ready traceability systems)

KDE – Key Data Elements (FSMA 204) are the specific data fields that the FDA traceability rule expects you to capture and maintain for defined Critical Tracking Events (CTEs) when you manufacture, process, pack, hold, or ship foods on the Food Traceability List (FTL). KDEs are the “what, when, where, and which lot” evidence that enables rapid trace investigations—especially the ability to provide an FDA-requested traceability dataset within tight timelines.

FSMA 204 is not asking you to build a perfect end-to-end digital twin. It’s asking you to be able to respond quickly with consistent, lot-linked event data when traceability matters. KDEs are the minimum viable dataset that makes that possible. The trap is that many organizations already store “some data” (purchase orders, bills of lading, inventory moves), but they don’t store it consistently, they don’t link it to lot identity, and they don’t capture it at the time the event occurs. In a real trace investigation, that gap becomes an operational crisis.

Tell it like it is: KDE compliance is not a paperwork problem. It’s an execution discipline problem. You have to capture the right data at the right time, in the right structure, without relying on humans to remember later. That’s why FSMA 204 pushes companies toward scan-driven receiving and shipping, lot-level ship confirm, structured transformation records, and event-based traceability models such as EPCIS.

“KDEs are the traceability receipts your supply chain must be able to produce on demand—linked to lots, not just documents.”

1) What KDEs are in FSMA 204 (plain-English definition)

KDEs are the data points that describe each critical traceability event for Food Traceability List foods. In plain English, KDEs answer:

• What happened? (receive, transform, create, ship, etc.)
• What product was involved? (item identity)
• Which lot(s) were involved? (lot code(s) and container identities)
• How much was involved? (quantity and UOM)
• When did it happen? (event time)
• Where did it happen? (facility/location)
• Who were the trading partners? (ship-from, ship-to, carrier where relevant)

KDEs are not “optional details.” They are the required minimum data fields that allow rapid trace investigation without guesswork.

2) KDEs vs CTEs: why FSMA 204 is event-based

FSMA 204 is built around Critical Tracking Events (CTEs)—key moments when product changes custody or transforms. KDEs are the data you record for those events. This matters because traceability failures usually occur at events:

• receiving without lot capture,
• shipping without lot-linked ship confirm,
• transformation without linking input lots to output lots,
• commingling/mixed pallets without preserving identity.

Event-based traceability is operationally realistic: it focuses on the boundary moments that define where product is and what it became.

3) Why KDEs exist: the “rapid trace request” problem

KDEs exist because in real outbreaks and contamination events, regulators need fast, consistent trace data to identify sources and stop spread. If each company stores trace information differently—some in emails, some in spreadsheets, some in proprietary ERP fields—trace investigations slow down.

KDEs standardize the minimum dataset so trace can happen quickly. The operational takeaway: if you can’t produce a lot-linked dataset quickly, your traceability is not functional in the way FSMA 204 expects.

4) Scope map: who must capture KDEs and where they show up

KDE responsibilities vary by where you sit in the supply chain. The same event may be called different things operationally, but the traceability need is the same.

Even if you’re not subject to every CTE, the KDE mindset still matters: capture identity and event context at the boundary where you take or release custody.

5) KDE categories: who/what/which lot/how much/when/where

The easiest way to operationalize KDEs is to treat them as categories. Every CTE record should have these categories present:

If any category is missing, your dataset becomes ambiguous in a trace investigation.

6) Lot identity: the critical KDE that everything depends on

Lot identity is the key that ties KDEs together across events. Without lot codes, you can’t connect receiving to transformation to shipping. Lot identity must be:

• captured accurately (preferably scan-based),
• consistent across systems (WMS/MES/ERP),
• preserved through repack and mixed pallet handling,
• linked through transformations (input lots → output lots).

If lot identity is wrong, your KDE dataset is wrong—even if all other fields are correct.

7) Receiving KDEs: starting the one-step-back chain

Receiving KDE capture is where your one-step-back starts. Practical receiving KDE discipline includes:

• supplier (ship-from) identity,
• supplier lot identity and internal lot mapping,
• quantity received and discrepancies,
• receipt time and facility location,
• disposition (quarantine/hold/release) and acceptance evidence (CoAs, inspections).

See Receiving KDE Capture for the operational workflow.

8) Shipping KDEs: proving one-step-forward traceability

Shipping KDE capture is the one-step-forward proof. Practical shipping KDE discipline includes:

• ship-to (consignee) identity,
• shipment identifiers (order/BOL/ASN),
• lot identity shipped (and SSCC/case IDs where used),
• quantity shipped,
• ship time and facility location,
• carrier handover evidence.

See Shipping KDE Capture.

9) Transformation KDEs: when materials become new lots

Transformation events are where internal genealogy is created. Transformation KDE capture requires:

• input lot list (what was consumed),
• output lot assignment (what was created),
• quantity relationships (mass balance and yield),
• time and location of transformation,
• linkage to batch/run identifiers so the event is retrievable.

Transformation is the hardest event to do well because it requires disciplined lot-level consumption capture and clear output lot definitions. If you don’t capture transformation KDEs, your trace becomes “we received it and we shipped it” with no proof of what happened in between.

10) Commingling, mixed pallets, and aggregation: real-world complexity

Real operations commingle product: mixed pallets, partial case picking, consolidation at DCs, and repack operations. KDE capture must preserve lot identity through these realities.

Operational strategies include:

• case-level lot identity (GS1-128) so mixed pallets remain traceable,
• SSCC pallet identity linked to pallet contents,
• rules for commingling (when allowed and how recorded),
• exception handling workflows when identity would otherwise be lost.

If you lose identity in aggregation, you can still comply in a narrow sense, but your recall scope will be broad and expensive.

11) Traceability plan and record structure: making KDEs retrievable

KDE capture is useless if you can’t retrieve it. FSMA 204 expects a traceability plan and the ability to provide datasets quickly. Practically, record structure should support:

• lot-based search across all event types,
• time-window search (for suspect windows),
• trading-partner search (ship-from/ship-to),
• export formats that regulators and partners can consume (CSV, EPCIS where used),
• audit trail integrity (no silent edits).

This is why KDE programs push companies toward event-based systems, not spreadsheets.

12) 24-hour response expectation: assembling KDE datasets quickly

Operationally, KDE readiness is tested by response speed. If FDA requests a traceability dataset, you must be able to produce it quickly. That aligns with the “24-hour record response” operational benchmark.

To meet fast response expectations, you need:

• predefined export templates,
• lot-centric evidence bundles (receiving + transformation + shipping),
• automated linkage across systems (WMS/MES/ERP),
• controlled exception handling so missing KDEs are rare.

If you have to manually stitch together receiving documents and shipping spreadsheets, you will not respond fast enough under pressure.

13) EPCIS alignment: turning KDE capture into exchange-ready events

EPCIS is a common way to represent KDE/CTE data as standardized events. If your KDE capture is event-based already, EPCIS alignment is straightforward:

• each CTE becomes an event with time, location, identifiers, and business context,
• ship/receive events become object events,
• transformations become transformation events,
• business transaction IDs (PO/BOL/ASN) map naturally.

The practical point: EPCIS does not fix weak capture. It amplifies strong capture. If your KDE capture is inconsistent, EPCIS outputs will be inconsistent too.

14) Controls and validation: preventing KDE capture from becoming fiction

KDE capture can be faked if controls are weak. Preventing fiction requires:

• scan-driven capture: minimize manual entry,
• validation rules: format checks and context checks (expected item/lot),
• hold/release enforcement: prevent shipping or use of ineligible lots,
• audit trails: edits require reason-for-change and cannot be silent,
• movement exceptions: prevent identity loss through wrong moves and commingling mistakes.

If people can change KDEs after the fact without controls, your dataset becomes legally and operationally unreliable.

15) Testing KDE readiness: mock recalls and retrieval drills

The best KDE test is a mock recall. Pick a finished lot and produce:

• receiving KDEs for implicated inputs (one step back),
• transformation KDEs linking inputs to outputs (internal genealogy),
• shipping KDEs showing where outputs went (one step forward),
• mass balance reconciliation.

If any KDE category is missing, you’ll feel it immediately because the trace chain leads to a dead end. That is why drills are the fastest way to prove KDE readiness.

16) KPIs: measuring KDE completeness and drift

Useful KDE KPIs include:

KPIs should drive system improvements, not punish reporting. KDE programs succeed when they reduce manual work and increase confidence, not when they add bureaucracy.

17) Failure patterns: how KDE compliance gets faked

• After-the-fact entry. KDEs filled in later to “make the trace work.”
• Document-only trace. POs and BOLs exist but aren’t linked to lot identity.
• Lot identity drift. Supplier lots, internal lots, and shipping lots don’t reconcile.
• Mixed pallet blindness. Commingling not captured; scope becomes broad.
• Transformation gaps. Inputs and outputs not linked; internal trace chain breaks.
• Manual entry normalized. Typing is treated as acceptable; error rates rise.
• Holds not enforced. You can ship ineligible lots; the record becomes a confession.

The antidote is execution discipline: scan capture, validation rules, hard gates, and routine drills.

18) How this maps to V5 by SG Systems Global

V5 supports FSMA 204 KDE capture by making traceability event capture native to receiving, production transformations, and shipping workflows. In practice, V5 can:

• capture scan-driven receiving KDEs with supplier lot mapping and disposition gating,
• capture transformation events linking input lots to output lots with quantities,
• capture scan-driven shipping KDEs tied to SSCC/case identity and BOL/ASN outputs,
• enforce hold/release and movement rules so KDE capture matches real control,
• export event data in traceability exchange formats including EPCIS where needed,
• generate rapid trace packages for “24-hour response” expectations and mock recalls.

These capabilities align with V5 WMS (receiving/shipping), V5 MES (transformations), and integration via V5 Connect API to connect external ERPs and trading partner systems.

19) Extended FAQ

Q1. Are KDEs the same as “traceability records”?
KDEs are a defined subset of traceability records: the specific data elements required for specific events. Traceability records can be broader; KDEs are the minimum that must be consistent and retrievable.

Q2. Do we have to use EPCIS to comply?
Not necessarily. EPCIS is a common standard for event data exchange, but compliance is about capturing and producing the required KDE datasets. EPCIS becomes useful when trading partners demand standardized exchange.

Q3. What’s the hardest KDE/CTE for most companies?
Transformations and aggregation. Linking input lots to output lots with quantities is where identity gaps and mass balance failures appearHOOK. The second hardest is mixed pallet handling in distribution.

Q4. What’s the fastest KDE compliance upgrade?
Make receiving and shipping scan-driven and lot-linked. If you still type supplier lots at receiving or ship lots without scanning/validation, you will always be reconstructing under pressure.

Q5. How do we prove KDE readiness?
Run mock recalls: pick a finished lot and produce the full event dataset (receive/transform/ship) with reconciled quantities quickly. If the dataset is complete and fast, your KDE program is real.

Related Reading (keep it practical)
KDE compliance becomes operational when you build scan-driven receiving and shipping (receiving KDE capture and shipping KDE capture), preserve lot identity through transformations (lot genealogy), reconcile quantities (mass balance), and test readiness with mock recalls and rapid record response drills.