Key Data Elements Under FSMA 204: A Practical Guide for Operations

Key Data Elements — KDEs in FDA's shorthand — are the specific data points that must be captured and retained in a traceability record at each Critical Tracking Event (CTE) under FSMA Rule 204. Getting the KDE requirements right is the foundation of any compliant traceability implementation. Getting them wrong — capturing some KDEs but not all, or capturing them in a format that does not allow sorting and searching — means your records may not satisfy a 24-hour FDA response request even if you have been diligently logging lot events.

This article provides a practical, field-by-field guide to the KDE requirements for each CTE type, with notes on implementation considerations for each field. It is designed for QA managers and systems teams configuring traceability records, not as a regulatory interpretation document — if you have questions about specific applicability to your operations, consult your regulatory affairs team or outside counsel.

Common Principles Across All KDEs

Before walking through the per-CTE KDE requirements, a few principles apply across all of them:

Electronic format, sortable and searchable: All records must be maintained electronically and be sortable and searchable. Each KDE should be a discrete, queryable field — not embedded in a narrative comment or a PDF document. A lot code that appears in a free-text notes field cannot be sorted or filtered; it must be its own structured field.

Real-time vs. same-day: FDA does not specify that records must be created at the exact moment of the CTE event — but they must be created promptly. Same-day creation is the practical standard. Reconstructing records days after the event is problematic both for accuracy and for audit defensibility.

Reference document linkage: Most CTEs require a reference document type and number. This is the connection between your trace record and the underlying transactional document (BOL, PO, batch record). This field must contain an actual document identifier that can be found in your records management system — not a generic note.

Location description standards: FDA accepts both a plain-language name and physical address format and GS1 Global Location Numbers (GLNs). GLNs are preferred for high-volume operations because they enable automated record linking. For smaller operations or suppliers not using GS1, name + full physical address is sufficient.

KDEs for Initial Packing CTE

The initial packing CTE is where the traceability lot code is first assigned. The KDE requirements are:

KDE	Required content	Implementation notes
Traceability lot code (TLC)	A unique identifier for the food at this packing event	Must be assigned at or before packing; should be printed on the case label in a format scannable by downstream receiving partners (GS1-128 with GTIN + lot code is the standard). The TLC format you choose here propagates through the entire downstream chain — consistency matters.
TLC source	Name and address of the person who assigned the TLC (if different from the packer)	Typically the packer assigns the TLC; this field is relevant when a separate labeling entity or co-packer assigns lot codes on behalf of the brand.
Quantity and unit of measure	Amount packed (e.g., 480 cases; 1,200 lbs)	Must use a consistent unit of measure that matches your downstream CTE records. If you record production in pounds but ship in cases, ensure the unit conversion is documented.
Product description	Commodity name and variety, sufficient to identify the FTL food	Use the FTL product category descriptor; do not use an internal SKU code as a substitute for the product description.
Location description	Name and physical address of the facility where packing occurred	If you use multiple packing facilities or contract pack at different locations, each facility has its own location description. Verify that your records system captures the specific facility, not just a generic "production facility."
Date of packing	Date (and time if multi-shift) when packing occurred	Date field must be in a sortable format (ISO 8601: YYYY-MM-DD is the standard). Date-only text fields like "March 14" are not sortable by year.
Reference document type and number	The type and identifier of the document that corresponds to this packing event	Typically the production order number, packing ticket number, or batch record number. Must be a real document that exists in your records management system and can be retrieved on request.

KDEs for Receiving CTE

The receiving CTE is created when you receive a covered food at your facility. The KDE requirements are:

KDE	Required content	Implementation notes
TLC	The lot code as assigned by the person who packed the food (the supplier's lot code, not your internal item number)	This is the most common gap: capturing your own internal receiving number instead of the supplier's TLC. Your receiving record must capture the TLC that is already on the product — the same code that appears in the supplier's shipping CTE record. If you assign a different internal lot code upon receipt, you must link the two in your records.
TLC source	Name and address of the person who assigned the TLC (your supplier's packer or packing location)	Your supplier's facility address. This field creates the link to the upstream part of the chain.
Quantity and unit of measure	Amount received	Should match the quantity on the BOL and COA. Discrepancies between the BOL quantity and the received quantity should be documented in a receiving discrepancy record.
Product description	FTL food description	Match to the product description on the supplier's shipping CTE and the COA.
Location description (receiving location)	Name and address of the facility where you received the food	Your facility's address, not a generic company name. If you receive at multiple docks or buildings, specify the location.
Date of receipt	Date the food was received at your facility	The actual date of physical receipt, not the PO date or COA date.
Reference document type and number	The BOL number or PO number for the inbound shipment	The BOL number links your receiving CTE to the shipper's shipping CTE — this is the cross-entity link in the chain. Capturing just the PO number (without the BOL) is weaker because the PO was created before the shipment; the BOL is the shipment-specific document.

KDEs for Transformation CTE

The transformation CTE links input ingredient lots to output finished goods lots. The KDE requirements are the most extensive of any CTE:

KDE	Required content	Implementation notes
Input TLC(s)	The TLC for each FTL food used as an input in the transformation	Every FTL ingredient has its own input TLC entry. If 6 FTL ingredient lots were used in a production run, all 6 must appear as input TLCs in the transformation CTE record. Non-FTL ingredients do not need to be captured here, but all FTL ingredients do.
Input TLC source(s)	Name and address of the person who assigned each input TLC	Your suppliers. These link backward to the receiving CTEs for each ingredient lot.
Input quantities	Quantity of each input TLC used	Must be at the lot level, not the aggregate production run level. If you used 200 lbs of lot A and 150 lbs of lot B of the same ingredient, these should be separate input TLC entries with their respective quantities.
Output TLC	The TLC assigned to the transformed food	The finished goods lot code. This is the code that will appear in your shipping CTEs and on the case labels your customers receive.
Output TLC source	Name and address of the person who assigned the output TLC	Your facility (or your co-man's facility if the transformation occurred there). If a co-man assigned the output lot code, use the co-man's facility address here.
Output quantity	Quantity of the transformed food produced	The finished goods quantity produced in the production run. Yield variance between input and output quantities is normal; document any significant variance in your batch record.
Output product description	Description of the FTL food produced	The finished goods product description. If the output product is not itself on the FTL (e.g., a highly processed shelf-stable product that used an FTL ingredient), transformation CTE records may still be required — consult your regulatory team.
Location description	Name and address of the facility where transformation occurred	Your production facility or your co-man's facility. If you use multiple co-mans, each facility has its own location description.
Date of transformation	Date the transformation occurred	The production run date, not the release date or ship date. If a production run spans midnight (multi-shift), document the start date.

KDEs for Shipping CTE

The shipping CTE is created each time you ship covered food to a customer, distributor, or retailer. Required KDEs:

KDE	Required content	Implementation notes
TLC	The lot code of the food being shipped	For mixed-lot shipments (multiple lot codes on the same truck or order), each lot code must have its own entry in the shipping CTE record. One shipping CTE record per lot code per shipment destination is the correct structure.
TLC source	Name and address of the person who assigned the TLC	Your facility (or the co-man who produced it). This links backward to the transformation CTE.
Quantity and unit of measure	Amount shipped of this TLC to this destination	Lot-level quantity, not order-level total. If you shipped 40 cases of lot A and 60 cases of lot B to the same customer on the same truck, these are two separate shipping CTE entries with quantities 40 and 60.
Product description.	FTL food description	Consistent with the output product description from the transformation CTE.
Location description of immediate subsequent recipient	Name and physical address of the entity receiving this shipment	The specific receiving location (DC address, not just the retailer's headquarters address). If the same customer has multiple DCs, use the specific DC that received this shipment.
Date of shipment	Date the food was tendered to the carrier or picked up	The ship date, not the delivery date or the order date. If your carrier picks up one day and delivers the next, the ship date is the pickup date.
Reference document type and number	The BOL number for the outbound shipment	The BOL number is the cross-entity link — it should match the BOL number that your customer captures in their receiving CTE. If your 3PL generates the BOL, ensure your traceability system captures that BOL number, not just your internal shipment ID.

Running a KDE Completeness Check

Once your traceability system is configured, verifying KDE completeness across your actual records is the step that closes the gap between implementation intent and operational reality. A KDE completeness check asks: for each CTE record in my system, are all required fields populated with non-null, valid values?

Common completeness failures found in production systems:

• TLC field populated with an internal item code instead of the supplier's lot code (receiving CTE)
• Input TLC fields missing for some ingredient lots in a production run (transformation CTE)
• Location description fields containing only a company name without a physical address
• Reference document fields containing "N/A" or "see file" rather than an actual document number
• Date fields formatted inconsistently (some records as YYYY-MM-DD, others as MM/DD/YY), which prevents reliable date-range sorting

Running a completeness audit across 6 months of production records — before an FDA trace-back request arrives — identifies these gaps when there is time to address them. The audit report also provides a useful baseline for GFSI or customer auditor discussions about the status of your FSMA 204 traceability implementation.

Foodtrce includes a KDE completeness report that surfaces incomplete fields across all CTE types in your system, with a filterable view by product, date range, and facility. If you want to see how the completeness check works against your actual data, we can walk through it in a working session.