Shipping KDE Capture

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

Updated January 2026 • FSMA 204 shipping KDEs, outbound traceability, lot-level ship confirm, SSCC & GS1-128, BOL/ASN evidence, chain-of-custody, carrier handover, mixed pallet logic, audit-ready retrieval • Primarily Food & Beverage Manufacturing & Distribution (FSMA 204, SQF/BRCGS traceability, recall readiness)

Shipping KDE Capture is the disciplined process of collecting and validating the required outbound Key Data Elements (KDEs) at the shipping event so you can prove exactly what was shipped, which lots it came from, how much was shipped, when it shipped, and to whom it shipped—without reconstructing the truth later. In practice, this means shipping is not just “send an order.” It is a traceability event that must produce lot-linked evidence that stands up during a mock recall, a recall drill, or an inspection.

Shipping KDE capture becomes critical under FSMA 204, because the shipping event is where “internal lot genealogy” becomes “external one-up/one-down.” If you ship without capturing lot identity, you may still be able to trace internally, but you cannot reliably identify which customers received which lots. That forces broad notifications and oversized recall scope. It’s the exact opposite of what a mature recall readiness program is supposed to deliver.

Tell it like it is: most traceability programs look good until shipping happens. That’s where controls are most likely to be bypassed (because the dock is busy), and where data is most likely to be entered late (because the truck is leaving). Shipping KDE capture fixes that by turning ship confirm into a governed, scan-driven event that enforces completeness before the trailer door closes.

“If you can’t prove which lots left the dock on which truck, you don’t have outbound traceability—you have outbound hope.”

1) What “shipping KDE capture” actually means

Shipping KDE capture means you treat ship confirm as a controlled evidence event. At the moment product leaves your custody, you record the identity and quantity of what left, link it to the consignee and shipment identifiers, and preserve that record in a retrievable structure.

In a mature system, “capture” is not a free-form note. It is validated data created by execution:

• lots/cases/pallets are scanned, not typed,
• shipments are linked to BOL/ASN/manifest objects,
• quantities reconcile with picks and inventory,
• exceptions are captured as structured events,
• holds are enforced so you can’t ship what shouldn’t ship.

If your KDEs exist only because someone typed values after the truck left, you do not have “capture.” You have reconstruction.

2) Why shipping is the make-or-break traceability event

Shipping is where traceability becomes external. Internally, you can often reconstruct which lots were used in a batch using production records. Externally, you cannot reconstruct who received what if you didn’t capture it at ship time, because customers receive mixed loads, repack at DCs, and break pallets immediately.

Shipping also creates irreversible consequences:

• once shipped, you lose physical control,
• if identity is wrong, notifications and retrieval become broad,
• if quantities don’t reconcile, your mass balance becomes suspicious,
• if you cannot prove handover time and consignee, your one-up/one-down becomes weak.

That’s why regulators and customers increasingly treat outbound traceability as a core compliance capability, not a clerical task.

3) Scope map: shipments, transfers, and outbound movements

Shipping KDE capture is not only “customer shipments.” It applies to any outbound event that changes custody or location in a way that matters to traceability:

In each case, the KDE logic is the same: capture identity, quantity, location/time, and counterparty.

4) Core shipping KDEs: what you must capture at ship confirm

Shipping KDEs typically cluster into a few categories. The exact fields vary by program, product, and trading partner, but the operational “minimum viable set” looks like this:

The key is that these fields must be lot-linked. Without lot linkage, “who/what/how much” becomes a generic shipping record with weak traceability value.

5) Identity model: lot, case, pallet, SSCC, and mixed loads

Shipping KDE capture lives or dies on identity granularity. You have three common identity levels:

• Lot-level only: shipment records list which lots were shipped, but not which cases/pallets contained them.
• Case-level: cases are identified (e.g., GS1-128) and linked to lots; shipments capture cases.
• Pallet-level (SSCC): pallets are identified via SSCC and linked to contained cases/lots; shipments capture SSCCs.

Pallet-level identity is often the best operational compromise: scan one SSCC and capture the contents link, rather than scanning every case manually. But this only works when pallet build and pallet content records are accurate.

Mixed loads complicate identity. A single trailer can contain multiple products and multiple lots. A single pallet can be mixed. If you don’t maintain identity at the appropriate level, forward trace becomes broad and expensive. That’s why many programs pair shipping KDE capture with GS1-128 case identity and SSCC pallet identity.

6) Scan-driven capture: how to eliminate “typed traceability”

Typed traceability is slow and error-prone. Scan-driven KDE capture is the clean solution because scanning produces:

• fewer transcription errors,
• time-stamped event capture,
• context validation (you can reject wrong lots or wrong SSCCs),
• fast ship confirm under pressure,
• audit-ready proof that identity capture occurred in real time.

A scan-driven shipping workflow typically includes:

• scan order or load ID,
• scan staging location and trailer/door assignment,
• scan SSCCs or case labels as they are loaded,
• validate that the scanned objects match the order and are eligible (released status),
• close shipment and generate manifest/BOL/ASN outputs.

If scanning is optional, it will be bypassed on busy days. That’s why scan failure escalation and exception handling matter in shipping environments.

7) Shipping documents: BOL, ASN, manifest, and proof of handover

Shipping KDE capture is stronger when it links to formal shipping documents. At minimum, you need a coherent “handover record.” Common documents include:

• Bill of Lading (BOL): legal shipment document defining consignee, carrier, and load details.
• ASN: electronic notice to trading partner, often including case/pallet identities.
• Shipping Manifest: itemized handover summary (what’s on the truck).
• Proof of pickup: carrier signature, time stamp, and seal/door control evidence where used.

The key is linkage: the BOL/ASN/manifest must be tied to the scanned identities (lots/SSCCs), not generated from generic order quantities. If documents can be generated without lot identity, you have paperwork without traceability.

8) Shipping as a CTE: event-time, location, and custody evidence

Shipping is a “critical tracking event” in most traceability models because it represents a custody transition. Operationally, shipping KDE capture must answer:

• when did custody transfer (date/time),
• where did it transfer (facility/dock),
• who took custody (carrier/trading partner),
• what identities moved (lot/SSCC/case IDs),
• what quantity moved (units/weight).

This is why shipping KDE capture is not optional if you want rapid forward trace. You can’t call customers if you can’t prove which customers received which lots.

9) Cold chain & lane controls: when shipping KDEs include temperature integrity

For temperature-controlled products, shipping KDE capture often extends to cold chain integrity evidence. That can include:

• trailer pre-cool confirmation and dock dwell time,
• lane validation (cold product loaded to cold trailer),
• temperature logger assignment and verification,
• trailer seal verification as part of custody integrity,
• exception triggers if dwell time or temperature requirements are breached.

Cold chain controls fail at shipping because the dock is where product is exposed. If you can’t prove ship-time conditions, downstream temperature disputes become unresolvable and risk assessment becomes broad and conservative.

10) Exceptions: partials, substitutions, split shipments, and short picks

Shipping KDE capture must handle real-world exceptions without destroying traceability.

Common shipping exceptions include:

• Short picks: less product shipped than ordered; must record actual quantity and which lots shipped.
• Substitutions: different lot or alternate item shipped; must enforce eligibility and capture the change as an auditable exception.
• Split shipments: one order shipped in multiple trailers/days; each shipment must have its own KDE package.
• Mixed pallets: mixed lots on a pallet; must preserve case-level identity or pallet content linkage.
• Rework/repack at shipping: last-minute repack creates new packaging identity; must preserve lot identity.

A robust system treats exceptions as structured events with approvals where needed, not as free text notes. Otherwise, the shipping record becomes untrustworthy.

11) Stop-ship and holds: preventing KDE capture from becoming fiction

Shipping KDE capture is only credible if you cannot ship held product. If your warehouse can ship lots on hold, your KDE record can still look complete—but it proves you shipped something you shouldn’t have shipped. That’s a compliance failure, not a documentation failure.

So shipping KDE capture should be integrated with:

• hold/release status gating,
• quarantine movement blocks,
• movement exception alerts for wrong-lot or wrong-status picks,
• shipment confirmation blocks when any included lot is not eligible.

Tell it like it is: if your ERP can “ship confirm” without checking lot eligibility, your traceability records become fiction under pressure. The system must block bad shipments, not document them.

12) EPCIS outputs: turning shipping KDEs into exchange-ready events

Many organizations use EPCIS for event-based traceability exchange. Shipping is a natural EPCIS event because it is an “object event” and/or “shipping event” with identities, time, location, and business context.

Shipping KDE capture supports EPCIS by ensuring the event has:

• event time and event location,
• business step (shipping) and disposition,
• identifiers (SSCCs, case IDs, lot references as applicable),
• read point (dock/door) where applicable,
• business transaction references (ASN, BOL, PO),
• party identifiers (shipper, receiver, carrier where required).

The point: if you capture KDEs correctly at ship confirm, generating exchange-ready EPCIS becomes a reporting output rather than a manual data project.

13) 24-hour response: how to package outbound KDE evidence fast

Shipping KDE capture is one of the most common “24-hour record response” needs. When a regulator or customer asks “who received this lot,” your answer must be fast and defensible.

A strong outbound KDE evidence package typically includes:

• shipment summary (ship date/time, ship-to, carrier, order ID),
• lot list and quantities shipped,
• SSCC/case IDs where used,
• attached BOL and/or ASN,
• manifest details (what was on the load),
• exceptions (short picks, substitutions) captured with reasons and approvals,
• status confirmation that shipped lots were released at ship time.

If you can produce this within hours, forward trace becomes routine. If you can’t, every trace request becomes a scramble.

14) KPIs: measuring shipping KDE completeness and drift

You can’t improve what you don’t measure. Useful shipping KDE KPIs include:

High exception frequency isn’t always bad—it may reflect reality. The risk is exceptions that are undocumented, unauthorized, or inconsistent. Those are traceability failures.

15) Audit posture: what auditors pressure-test about shipping records

Auditors pressure-test shipping KDE capture by asking for a forward trace. They often pick a finished lot and ask:

• which customers received it,
• which shipments carried it and when,
• how much was shipped,
• what product remains on hand,
• how you know the record is complete and not reconstructed.

They may also ask you to demonstrate that holds prevent shipping: attempt to ship a held lot (in a controlled way) and prove the system blocks it. If the block doesn’t exist, shipping KDE capture is not credible because the system can ship product outside the governed traceability rules.

16) Copy/paste readiness scorecard

Use this as a blunt internal test. If you can’t answer cleanly, fix the workflow—not the wording.

17) Failure patterns: how shipping KDE capture gets faked

• Order-only shipping records. Shipments recorded by SKU without lot identity; forward trace becomes broad.
• Typed lot numbers. Lots typed from memory; transcription errors and backfill risk rise.
• ASN/BOL not linked to identities. Documents exist but don’t prove which lots were loaded.
• Mixed pallet blindness. Pallets contain multiple lots, but only one lot is recorded.
• Exceptions handled verbally. Substitutions and splits happen without structured capture.
• Hold leakage. Status says hold, dock still ships; the worst kind of control failure.
• After-the-fact reconstruction. KDEs filled in later to “make the trace work.” Auditors can tell.

The fix is always the same: scan-driven ship confirm, strong validation, structured exceptions, and hard gates that prevent ineligible shipping.

18) How this maps to V5 by SG Systems Global

V5 supports Shipping KDE Capture by making shipping a governed, scan-driven event tied to lot genealogy and shipment documents. In practice, V5 can:

• capture lot-linked ship confirm using SSCC/case scans and validation rules,
• generate outbound manifests and link them to BOL/ASN objects,
• enforce hold/release gating so ineligible lots cannot be shipped,
• capture structured exceptions (substitutions, short picks, split shipments) with approvals,
• produce rapid forward trace outputs (“who received this lot”) and support one-up/one-down trace packages,
• export event-based data for exchange standards such as EPCIS where needed.

These controls align naturally with V5 WMS (shipping execution and movement control), V5 MES (lot genealogy and production linkage), and V5 QMS (holds, deviations, and governed exceptions). For integration into ERP and carrier systems, V5 Connect API provides the integration spine.

19) Extended FAQ

Q1. Is shipping KDE capture only required for FSMA 204 foods?
FSMA 204 is a major driver, but many customer programs and GFSI audits also expect robust outbound lot linkage. Even outside FSMA 204 categories, outbound lot linkage is what makes recalls precise and defensible.

Q2. What’s the fastest way to improve shipping KDE capture?
Make ship confirm scan-driven. If you still type lot numbers, you will always have errors and backfill risk. SSCC-based shipping is often the highest leverage upgrade for palletized operations.

Q3. What breaks shipping KDE capture the most?
Mixed pallets and last-minute substitutions. If you don’t maintain case/pallet identity and govern exceptions, your forward trace becomes broad and unreliable.

Q4. How do we handle partial shipments?
Treat each shipment as its own KDE event: capture identity, quantities, and documents for each partial. Don’t merge partials into one record later, because that creates ambiguity.

Q5. How do we prove the system is real?
Run a mock recall forward trace: pick a finished lot and produce the “who received it” package fast—shipments, customers, quantities, and the linked BOL/ASN/manifest. If it takes manual detective work, your KDE capture is not mature.

Related Reading (keep it practical)
Shipping KDE capture becomes durable when paired with strong identity at case/pallet level (GS1-128 and SSCC), validated event capture (EPCIS), and enforceable containment (hold/release with shipment blocking). Then prove it through recall drills and fast forward-trace packages that support 24-hour record response expectations.