Pharmaceutical Serialization Software: What Happens When the Pallet in the Dock Does Not Match the EPCIS File?

Why serialization breaks twice: once at the line and once at the dock

A pallet is staged at a dock on a Friday afternoon. The advance shipment notice went out with the EPCIS file that says this pallet contains twelve cases, each containing forty eight serialised units. During night shift a case was opened because a unit was pulled for a stability sample, then resealed. Nobody sent an unpack and repack event. The customer's receiving system reconciles what it scanned against what you sent, finds a hierarchy that does not match, and quarantines the delivery. Your commercial team hears about it Monday. Your serialization lead spends the day proving which unit left the case and when.

The systems in play are usually a packaging line with printers, vision cameras, and a line level controller, a site level serialization application, an enterprise repository, and a partner exchange service. TraceLink, Systech, Antares Vision rfxcel, SAP Advanced Track and Trace, and Movilitas all operate in this space and they are genuinely capable. TraceLink in particular has a network advantage that is real and should not be dismissed, because the hardest part of trading partner exchange is that the other party has to be connected too.

What drives manufacturers, repackagers, and wholesalers to build is narrower than replacing all of that. It is that the exception paths, which are where every actual problem happens, follow your packaging operations rather than a product's assumptions, and that the reconciliation between physical hierarchy and reported hierarchy is the thing that stops shipments. Across serialization projects we have delivered, the recurring pattern is that commissioning works fine and aggregation is where the labour goes. Sites lose one to three shifts a month to hierarchy exceptions, and every one of them is a shipment at risk.

Problem 1: aggregation is physical, and your data is optimistic

Commissioning a serial number to a unit is easy. Recording that the unit went into a specific case, and that the case went onto a specific pallet, requires the physical act and the data event to stay married through every subsequent handling. They do not. A case is dropped and rebuilt. A unit is rejected by vision after the case was already aggregated. A pallet is broken down for a partial shipment. Someone samples a unit for quality.

Line systems handle the happy path well and the exception path with whatever the integrator configured three years ago. That configuration is frequently a supervisor override that fixes the line and leaves the repository believing something untrue. The mismatch is not discovered until a partner reconciles it.

What a custom build does: treat aggregation as an event stream that can be corrected only by further events, never by editing state. Unpack, repack, decommission, and sample events are first class and available to the operator at the point of handling, on a scanner, in the seconds when they actually happen. The system computes current hierarchy from the event history, so a reconciliation query against a physical scan is instant and the difference is explainable. Building the exception paths first, rather than last, is the single design decision that separates a serialization system that works from one that produces holds.

Problem 2: every trading partner reads EPCIS differently

GS1 EPCIS is a standard, and standards in this industry are implemented with local dialects. One wholesaler expects specific business step and disposition values. Another requires particular extension fields. One wants files over AS2, another over SFTP, another over a REST interface with their own authentication. Master data alignment is its own problem, because your product identifier, your location identifiers, and their expectations of both have to agree before a single event is accepted.

What a custom build does: separate the internal event model from the partner profile entirely. Events are stored once in a canonical form. Each partner has a profile defining the transformation, the transport, the required fields, the acknowledgement handling, and the retry behaviour. Onboarding a new partner becomes a configuration and test exercise rather than a code change, which matters because you will onboard partners for as long as you are in business. Every outbound file is retained exactly as sent, alongside the acknowledgement or rejection, because the first question in any dispute is what you actually sent and when.

Problem 3: the exception is the job

Reworked product. A case damaged in the warehouse. Product returned by a customer and eligible for resale. A destroyed batch. A serial number range that was commissioned and never used because the line stopped. Samples pulled for quality and stability. Each of these changes the status of specific serial numbers and each has a correct set of events and a wrong set that will cause a partner rejection later.

Under the enhanced requirements of the Drug Supply Chain Security Act, transaction information has to travel electronically at package level and trading partners must be able to respond to verification and investigation requests. That is a fundamentally different posture from the lot level world it replaced, because the questions asked are about individual packages rather than shipments.

What a custom build does: give every exception a named workflow with the correct events built in, exposed to the people who actually encounter it. A warehouse operator scanning a damaged case should have a decommission path that takes ten seconds and produces correct data, because the alternative is that they set it aside and tell someone on Monday. Serial number status is queryable at any moment, with the full event history and the operator who performed each step. When a partner sends an investigation request about one package, you answer it the same day from the system rather than from a warehouse manager's memory.

Problem 4: one product, several markets, several endpoints

A product sold in the United States, the European Union, and other regulated markets carries different obligations at the same time. The EU Falsified Medicines Directive requires the unique identifier to be uploaded to the European hub and national systems and decommissioned at dispensing, with tamper evident packaging alongside. Other markets run their own national systems with their own code formats and their own reporting expectations, and some require codes to be requested from a state system before printing rather than generated by you.

What a custom build does: model market obligation as configuration attached to product and destination, so the packaging order knows what it must do before it runs rather than after. Serial number sourcing differs by market, so the number pool abstraction has to support both internally generated ranges and externally issued codes without special casing the line. Reporting adapters per market are versioned, because these systems change their interfaces and you need to run the old and new in parallel during a transition.

Problem 5: verification requests arrive on someone else's clock

When a wholesaler receives a saleable return, they need to verify the product identifier before that unit can go back into commerce. When a partner suspects an illegitimate product, an investigation follows with obligations for both sides. These are inbound requests with response expectations, and they land regardless of whether your serialization lead is at their desk.

What a custom build does: expose a verification service that answers automatically from your repository, logs every request with its requester and response, and alerts a human only when the answer is anything other than a clean confirmation. Repeated verification attempts against the same identifier from unexpected sources are exactly the signal these systems exist to surface, and a build should treat that pattern as an alert rather than a line in a log file nobody reads.

What this costs and how long it takes

Across the 2,000 plus projects Digital Heroes has delivered, this is the shape for serialization platforms. A first release covering serial number pool management, line integration for commissioning and aggregation with exception paths, canonical event storage, and one partner exchange profile runs $100,000 to $220,000 and ships in 16 to 22 weeks. A full platform adding multiple market reporting adapters, a partner profile library, warehouse exception handling on scanners, verification response services, returns processing, and full audit history runs $300,000 to $750,000 phased over 10 to 20 months.

• Number of packaging lines and their vintage. A modern line with a documented interface is days of integration. A line with a proprietary controller and an integrator who has moved on is weeks.
• Number of trading partners and how many insist on their own dialect. Each profile is real work including a test cycle with the partner, whose availability you do not control.
• Number of regulated markets, since each national system is effectively a separate integration project with its own certification.
• Whether contract manufacturers are in scope. A CMO producing on your behalf must send you events in a format you can accept, and getting five CMOs aligned is a programme rather than a feature.
• Validation, because this is a GxP system whose records support product release and regulatory reporting.

Build versus buy, and when buying is right

Buy if you are a single site with one or two lines and a small number of partners. TraceLink, rfxcel, and Systech will get you exchanging data faster than a build, and the network connectivity they bring is worth paying for. Buy if your problem is genuinely connectivity rather than operations, because rebuilding a partner network from scratch is not a sensible use of capital.

Build when two or more of these are true. Your exception volume is high enough that hierarchy mismatches regularly hold shipments, and the packaged system's exception paths do not match how your warehouse actually works. You operate across several markets and are maintaining parallel systems that disagree. You are a repackager or wholesaler whose business model creates aggregation events that manufacturer oriented products handle badly. You need serialization data joined to your own batch, quality, and logistics data for analysis that a hosted repository will not give you. Or your per transaction pricing has grown to the point where the arithmetic of ownership has changed, which happens more often than vendors like to discuss. A hybrid is frequently correct: keep a commercial service for partner connectivity, build the site and enterprise layer where your operations live.

How to choose a developer for serialization software

Ask them to model a repack before you sign anything. A developer who has done this describes unpack and repack as events over an append only stream with current hierarchy computed from history. A developer who proposes updating a parent identifier on a child record has built an inventory app and will produce the exact mismatches that stop your shipments.

Ask how a partner profile is added. If onboarding a new wholesaler requires a code release, you have bought a permanent consulting engagement.

Ask what line level integration they have actually done, naming the printer, the vision system, and the controller. Serialization fails at the line more often than anywhere else, and floor experience is not transferable from web work.

Ask who owns the code and get it in writing before kickoff. You should own the repository, the infrastructure accounts, and the right to hire anyone else to continue the work. At Digital Heroes the client owns the code from the first commit. Serialization records support regulatory reporting and must remain retrievable for years, which is longer than most vendor relationships last.