A case GTIN identifies a defined trade-item class. An SSCC identifies an individual logistic unit established for transport or storage. The two identifiers answer different questions, even when the goods and packaging look identical.
In a GS1 logistics workflow, two separately handled units containing the same case type need different SSCCs. Repeating the case GTIN on both units does not identify them individually. Nor does scanning an SSCC, by itself, reveal everything packed inside.
The GS1 System Architecture, version 12.0.0 (October 2024) explicitly distinguishes a trade-item class identified by a GTIN from a physical logistic unit identified by an SSCC. Its Identify, Capture and Share model also separates identification from the information associated with an identifier.
A case type can repeat across different logistic units
Consider a wholly hypothetical candle gift-box order.
TypeT is a defined, orderable case type containing six empty candle presentation boxes. Assume that TypeT has an appropriately assigned case-level GTIN. TypeT is a fictional name, not a GS1 identifier.
The packing operation creates two separate transport units:
-
UnitU1 contains four cases of TypeT.
-
UnitU2 also contains four cases of TypeT.
Both units contain the same trade-item class in the same quantity. The individual TypeT cases may legitimately carry the same case-level GTIN.
But UnitU1 and UnitU2 are different physical logistic units. Under an applicable GS1 logistic-label workflow, each needs its own unique SSCC.
If someone prints the same TypeT GTIN as the only identifying barcode for both transport units, reading that barcode cannot distinguish UnitU1 from UnitU2. The result identifies the case type, not which particular logistics unit was handled.
This does not make the repeated GTIN incorrect. GTIN reuse across physical examples of the same defined trade-item class is normal. The error is expecting that class identifier to perform the SSCC’s individual-unit role.
There is a further distinction: GS1 can identify a particular trade-item instance through a GTIN combined with a serial number. That compound trade-item identifier is still conceptually different from an SSCC identifying a logistic unit.
One physical case can have two identification roles
An outer case is not automatically either a trade item or a logistic unit exclusively.
A defined case may be ordered and invoiced as a trade item. The same physical case may also be the individual unit managed during transport. When both roles apply, its GTIN and SSCC identify different aspects of that physical object.
The GS1 Logistic Label Guideline, release 1.3 (ratified July 2019) explains that cartons and outer cases can carry GTIN barcodes without being GS1 Logistic Labels. A GS1 Logistic Label, by contrast, requires an SSCC.
The distinction matters when reviewing artwork. An existing case GTIN barcode is not evidence that the case has also received a unique logistic-unit identity.
It does not follow that every parcel, decorative gift box or courier shipping carton must receive an SSCC. The requirement described here belongs to the applicable GS1 logistic-identification process, not to all packaging in commerce.
An SSCC identifies the unit without describing its complete contents
A unique identifier is a key to information, not necessarily a container for all that information.
In the hypothetical example, the trade-item data associated with TypeT defines the case class. That shared definition may be used whenever TypeT appears.
The information about UnitU1 and UnitU2 has a different scope. It concerns two particular physical loads.
The packing information would associate the SSCC identifying UnitU1 with its four TypeT cases, and separately associate UnitU2’s different SSCC with its four TypeT cases. The two associations can describe identical quantities without becoming the same unit record.
This is the practical distinction between the three GS1 functions:
Identify provides the relevant class or unit key. Capture enables a system to read that key and any other data correctly encoded in the carrier. Share makes associated business information available through an agreed information system or exchange.
A GS1 barcode can carry permitted information beyond its identification key. But reading an SSCC does not create missing packing information, infer an unrecorded component revision or establish that a shipment record is accurate.
For the receiving partner to associate a physical unit with its declared contents, the necessary data must already have been captured and made available. Depending on the agreed workflow, this may involve trade-item master data, a despatch advice or another linked business-information system.
The GS1 System Architecture distinguishes master data, transaction data and visibility data. It also identifies content descriptions as examples of information that can be associated with an SSCC.
That association is the information boundary. The physical identifier enables a relationship to be found; the corresponding data and working integration must supply the meaning.
Homogeneous and mixed units need different content-information treatment
The GS1 Logistic Label Guideline makes a further distinction that prevents a case GTIN from being used indiscriminately on every transport label.
In the original hypothetical example, UnitU1 is homogeneous: it contains only TypeT cases. It is assumed not to be a separately traded item itself.
For this type of logistic unit, the guideline allows the contents to be described using Application Identifier (02) for the GTIN of the contained trade item, together with AI (37) for the count. The logistics label still requires the unit’s SSCC under AI (00).
Thus, the label can communicate both a unique logistic-unit identity and relevant information about its homogeneous contents. The contents GTIN does not replace the SSCC.
Now consider a different hypothetical packing plan.
UnitU2 contains TypeT cases together with TypeV cases, where TypeV represents another fictional trade-item class. Assume this mixed logistic unit is not itself a trade item.
This is a heterogeneous unit. Section 4 of the guideline advises that GTIN and related trade-item information should not be included on the GS1 Logistic Label for such a unit. Instead, it strongly encourages electronic information exchange linked to the SSCC.
The SSCC identifies UnitU2, while the linked contents information distinguishes its TypeT and TypeV cases and their actual quantities.
Printing only TypeT’s GTIN as though it described the whole mixed unit would misrepresent the situation. A scan of UnitU2’s SSCC alone would not reconstruct its mixed-case breakdown.
There is also a separate scenario in which the logistic unit is itself a trade item. The guideline permits AI (01) to specify that trade item’s GTIN. It explicitly prohibits using AI (01) GTIN and AI (02) CONTENT together on the same logistic label.
These are distinctions about what the identifiers and data fields mean, not a complete label-design specification. The applicable current GS1 General Specifications and trading-partner requirements still govern implementation.
Keep case artwork, logistic-unit identity and shared contents data separate
Before adapting a repeated case-label design for an actual shipping process, establish what that design already identifies.
If the printed GTIN belongs to the defined case trade item, it identifies that case class. It cannot be treated as a substitute for assigning individual SSCCs where the GS1 logistics workflow requires them.
The physical logistic units must be separately identifiable, and each unit’s actual contents must be associated with its identity using the agreed packing and information-sharing process. The receiving party also needs a way to use that association. A readable barcode does not demonstrate that those steps happened.
This is different from recording which component artwork revision or lot was packed in a carton. Packrivo’s carton-to-component-version manifest addresses those internal physical-content references. Its master-carton label reconciliation guide addresses discrepancies between printed label information and packed units.
Those records can support a broader logistics workflow, but neither converts a GTIN into an SSCC or establishes an electronic exchange with a receiving partner.
For a small jewellery, candle or gift brand, the useful decision is not simply which barcode image to copy onto another carton. It is whether the packaging is being identified as a defined trade item, an individual logistic unit or both—and how the information about each physical unit will be made available after its identity is captured.
Packrivo can help coordinate the relevant packaging, artwork and sourcing questions. Actual GS1 identifier allocation, label implementation and trading-partner acceptance remain separate responsibilities.
Source scope: The publicly accessible GS1 System Architecture version 12.0.0 (October 2024) and GS1 Logistic Label Guideline release 1.3 (July 2019) were reviewed on 10 October 2026. All named units and case types are fictional. No identifiers were allocated, barcodes tested, actual goods tracked or electronic transactions performed.
A split needs child-unit records as well as reconciled case counts
Extend TypeT with a fictional split event. PARENT30 contains four TypeT cases; each TypeT case contains six empty presentation boxes under the original trade-item premise. The proposed split creates CHILD_A30 with two cases and CHILD_B30 with two cases. Each child therefore holds twelve empty boxes, and the pair reconciles to four cases and twenty-four boxes.
Scroll horizontally if columns extend beyond the view.
| Hypothetical configuration | Named object | Relationship | Input or next scope |
|---|---|---|---|
| SPLIT30 | TYPET_EMPTY_BOXES | assumed input | 6 boxes/case |
| PARENT30 | TYPET | assumed input | 4 cases/unit |
| PARENT30 | EMPTY_BOXES | calculated from | PARENT_CASES*TYPE_CONTENT; 24 boxes/unit |
| CHILD_A30 | TYPET | assumed input | 2 cases/unit |
| CHILD_A30 | EMPTY_BOXES | calculated from | CHILD_A30_CASES*TYPE_CONTENT; 12 boxes/unit |
| CHILD_A30 | CHILD_A30 | requires | OWN_APPROPRIATE_PHYSICAL_UNIT_IDENTITY_ASSIGNMENT_PENDING |
| CHILD_A30 | CHILD_A30 | requires | OWN_LINKED_ACTUAL_CONTENTS_RECORD |
| CHILD_B30 | TYPET | assumed input | 2 cases/unit |
| CHILD_B30 | EMPTY_BOXES | calculated from | CHILD_B30_CASES*TYPE_CONTENT; 12 boxes/unit |
| CHILD_B30 | CHILD_B30 | requires | OWN_APPROPRIATE_PHYSICAL_UNIT_IDENTITY_ASSIGNMENT_PENDING |
| CHILD_B30 | CHILD_B30 | requires | OWN_LINKED_ACTUAL_CONTENTS_RECORD |
| SPLIT30 | RECONCILED_CASES | calculated from | CHILD_A30_CASES+CHILD_B30_CASES; 4 cases |
| SPLIT30 | RECONCILED_EMPTY_BOXES | calculated from | CHILD_A30_BOXES+CHILD_B30_BOXES; 24 boxes |
| SPLIT30 | TYPET_CLASS | remains | SAME_BY_PREMISE |
| SPLIT30 | PARENT_UNIT_ID | not copied as | BOTH_CHILD_UNIQUE_UNIT_IDENTITIES |
| SPLIT30 | BALANCED_COUNT | does not prove | ACTUAL_PACK_SCAN_OR_RECEIVER_DATA_AVAILABILITY |
| SOURCE30 | GENSPEC26_JAN2026 | not equivalent to | 27JAN_LAST_MODIFIED_OR_ALL_GSCN_REVIEW |
The TypeT class does not change merely because its cases move into different physical groupings. The unit records do change. Within the applicable GS1 logistics workflow, do not copy one parent-unit identifier onto both children and expect the receiver to distinguish them. The responsible identifier owner must establish the appropriate child identities and contents associations under the actual current rules; this worksheet allocates no SSCC or GTIN.
Keep the parent history, split event and each child’s contents relationship visible instead of overwriting the parent with the latest total. A balanced 2 + 2 count does not prove that the receiving partner obtained either child record, that a label scans, or that the physical packing matches it. Data availability and actual capture remain separate from arithmetic.
One physical carton can have both trade-item and logistic-unit roles. This split example does not remove that possibility or impose SSCCs on every courier carton. The reviewed General Specifications archive lists 26.0.0 published January 2026; 27 January is a directory last-modified field, not a verified publication or effective date. The full large PDF and all dynamic GSCN notices were not reviewed, so no absence of later changes is claimed.
Download the GS1 logistic unit split parent child contents identity record (.csv). It includes the original table fields and scenarios alongside the added relationships. HYPOTHETICAL rows are editorial examples or required review scopes, not actual records. Actual quantity, configuration, component and file identities, materials, process, specification, copy, method, condition, observation, owner, decision, evidence and dates are blank. ACTUAL_BLANK is a separate empty starting row; enter permitted project evidence before using an actual record. A blank means unknown.
Use the Shipping-Carton IDs Need the Packaging Versions Inside Them for its separate question.
Additional official reference: GS1 General Specifications archive, GS1 standards directory and last-modified fields, GS1 approved-change notices entry. The archive lists a January 2026 publication month; 27 January directory modification is a different field. All GSCN notices and the full General Specifications PDF were not reviewed.
Source scope checked 17 October 2026: GS1 Architecture 12.0.0 published 18 October 2024 and Logistic Label 1.3 July 2019 support class/unit and identify/capture/share distinctions. General Specifications 26.0.0 is January 2026; directory 27 January last-modified is different. Full General Specifications and all GSCNs were not read. No real allocation, label implementation, scan or data exchange was approved. The added configurations and calculations are hypothetical, with actual evidence and decisions pending.
Discuss this packaging specification with Packrivo. We coordinate independent suppliers. MOQ: 500 pieces per product/design; illustrative quantities are not production offers. Confirm materials, samples, price and timing for your project.