
Neither EU FMD nor US DSCSA writes parent-child aggregation into law as a hard requirement. Yet the two regimes pull in opposite directions on it, and an exporter serving both markets has to decide how much to build.
Parent-child aggregation is the digital link between the serial number on each medicine pack, the case that holds it, and the pallet that holds the cases, so scanning one outer label identifies every unit inside. GS1 defines it as a hierarchical relationship between a containing unit and the units contained, with the parent identified by its own serial code.
India is the largest provider of generic medicines globally and sends around half its pharmaceutical exports to tightly regulated markets in North America and Europe, on India Brand Equity Foundation figures. That makes aggregation, the one serialisation layer an exporter fully controls, the variable that decides whether shipments clear both regimes cleanly.
Neither regime makes parent-child aggregation a legal requirement, yet DSCSA’s partner-to-partner electronic tracing makes it a practical must for the American market, while EU FMD leaves aggregated codes explicitly optional against a central repository. Exporters most often fall short by serialising packs cleanly and under-building the aggregation layer, which draws American rejection or slow European handling.
What parent-child aggregation actually is

Parent-child aggregation creates a hierarchical relationship between a containing unit, the parent, and the units inside it, the children. On a pharma line the parent is a case or a pallet and the children are the saleable packs, each carrying its own serial number. GS1 identifies the parent with a Serial Shipping Container Code and each child with a GTIN plus serial, backed by lot and expiry.
The payoff is a mechanism called inference. A receiving wholesaler verifies only the highest-level code and treats the packs inside as present and genuine, rather than opening the case and scanning every unit.
Open a case and the inference breaks, so the aggregation data has to update to match. A hierarchy that no longer describes physical reality is worse than no hierarchy, because someone downstream is relying on it.
How the two regimes differ

The headline difference is that neither one forces you to aggregate, and they arrive at that position for opposite reasons.
EU FMD treats an aggregated code as an optional convenience a wholesaler may scan instead of every pack. DSCSA never names aggregation in its statute, yet turns it into a commercial necessity through package-level electronic tracing, because partners rely on inference to move serialised data at scale.
| Dimension | EU FMD | DSCSA (United States) |
|---|---|---|
| Governing rule | Delegated Regulation (EU) 2016/161, from 9 February 2019 | DSCSA enhanced system, section 582(g), from 27 November 2023 |
| Pack-level identifier | Product code, randomised serial (max 20 characters), batch, expiry, plus a conditional national reimbursement number | Standardised numerical identifier (NDC plus serial up to 20 characters), lot, expiry, in a 2D data matrix |
| Case-level identifier | Not separately mandated; aggregated codes optional | Product identifier required on each homogeneous case (single NDC, single lot) |
| Aggregation status | Explicitly optional, left to the wholesaler (recital 20) | Not named in statute; expected in practice through inference |
| Tracing model | Verify and decommission each pack against a central European repository at the point of supply | Partners exchange electronic, interoperable package-level transaction data |
| Second safety feature | Anti-tampering device required alongside the identifier | No tamper-device requirement in the identifier rule |
Timing sharpens the contrast. The EU safety-feature system has run since 9 February 2019. On the American side, the staggered grace periods for manufacturers, wholesalers and larger dispensers expired across 2025, so those partners now operate under the full enhanced system, with only small dispensers exempt until 27 November 2027. Both markets are live today.
What EU FMD requires you to serialise
Each prescription pack carries a unique identifier made of five data elements. Under Article 4 of Delegated Regulation 2016/161, that means a product code, a randomised serial number of up to twenty characters, the batch number, the expiry date, and a national reimbursement number where the destination country asks for one.
A second safety feature rides alongside it: an anti-tampering device showing whether anyone opened the pack.
The EU runs an end-to-end verification model rather than a partner-to-partner data exchange. Under Article 25, the person supplying medicine to the public verifies the safety features and decommissions the unique identifier against a central European repository. Because that check happens pack by pack against a shared database, aggregation never becomes a legal need, and recital 20 says so directly.
That makes aggregation a genuine choice if you ship only into the EU. European wholesalers verify each pack against the central database, so full case-and-pallet aggregation adds cost you may not recover from European handling alone, and a lighter build can be enough.
What DSCSA requires for the United States
Serialisation reaches the case as well as the pack. Under the Drug Supply Chain Security Act, each package and each homogeneous case carries a product identifier holding a standardised numerical identifier, the lot number and the expiry date, encoded in a 2D data matrix. That identifier combines the National Drug Code with a serial of up to twenty characters, unlike the EU product code. A homogeneous case is a sealed case holding a single National Drug Code from a single lot.
The American model works by moving data between partners rather than through a central database. From 27 November 2023, trading partners must provide and receive package-level transaction information and statements in a secure, electronic, interoperable form, the requirement the FDA calls the enhanced system under section 582(g).
Aggregation never appears as a named rule in that text. But the case identifier and the package-level exchange together make it the natural next layer, so an American buyer expects inference-ready data on arrival.
Build one aggregation layer for both markets
Connect unit, case, and pallet serialisation with operational data exchange.
Building one aggregation layer both markets accept

Build to the stricter reader, which is the American trading partner, and the EU’s optional use is covered by the same work. Four things have to happen on the packing line.
- A unit-level serial on every saleable pack. Aggregation links serials rather than replacing them, so each pack needs its own before it can join a hierarchy.
- The parent-child hierarchy captured at packing. Record which pack serials sit inside which case, and which cases sit on which pallet, as the line seals each case rather than reconstructing it afterwards.
- Honest disaggregation events. Opening a case breaks the physical hierarchy, so the record updates every time. Inference should never rest on a hierarchy that no longer exists.
- A feed into the electronic exchange. The American model moves package-level transaction data between partners, so the hierarchy has to reach the systems that generate your transaction data, not sit in a separate database.
We built Acviss Origin for this layer, running unit, case and pallet serialisation with parent-child aggregation, connecting to ERP and line hardware through standard connectors and a REST API, and continuing to operate on the plant floor without an internet connection. It also manages recalls against the same serialised records, so a withdrawal does not break the hierarchy a buyer infers from.
Aggregation software supports compliance work rather than delivering it. No platform can promise a compliance outcome on its own, and your regulatory affairs team still owns the submission.
FAQ
What aggregation accuracy do American trading partners expect?
Higher than most lines achieve on their first attempt, and there is no published legal threshold because aggregation is not a legal requirement. What matters commercially is what your customer’s receiving system does with a mismatch: a case where the inferred contents do not match the physical contents typically triggers a manual count of the whole shipment, which is expensive for them and reputationally costly for you. Ask each customer what their exception process is before your first shipment rather than after it.
Who updates the aggregation record after a case is opened downstream?
Whoever opened it, which means the responsibility leaves your building along with the case. Your obligation is to ship a hierarchy that is accurate at dispatch and to make the disaggregation data easy for a partner to update. Where a distributor repacks or breaks cases routinely, expect inference to be less useful to them and confirm what data they actually want, because building a hierarchy nobody downstream maintains is wasted work.
Does contract manufacturing change who owns the serialisation obligation?
It changes who does the work but not who carries the obligation, which stays with the marketing authorisation holder or the party whose name is on the product. For a contract manufacturer, the practical questions are who generates the serial numbers, who holds the master data, and who transmits the aggregation data onward. Settle those three in the manufacturing agreement, because a serialisation dispute discovered at a customs hold is the worst place to have it.
Do you need aggregation for markets outside the EU and US?
Requirements vary and several markets have their own serialisation regimes with their own reporting formats, so treat each destination separately rather than assuming a US-grade build satisfies everyone. The useful generalisation is that the underlying data, meaning unit serials and a maintained hierarchy, transfers between regimes even when the reporting format does not. Build the data properly once and expect to write new export formats per market.
What do you do when the physical case does not match the aggregation record?
Treat it as an exception with a defined procedure, not as something to correct quietly. The record should be updated to reflect what is physically in the case, the discrepancy should be logged with the reason, and the shipment should not leave until both agree. Most aggregation failures in the field trace back to lines that allowed a mismatch to pass because fixing it would have stopped production.
Prepare export-ready pharmaceutical aggregation
Map your packaging hierarchy, integration requirements, and exception workflows with Acviss.


