Transparency and Project Zero: Serialized Labels at a Prep Center

By Bernardo Campelo, Forbes Business Council E-Commerce Leader, Amazon SPN Certified provider, Amazon SP-API authorized partner, and Founder of PrepVia.

A brand owner called in July with a container already packed for FBA. Every carton carried the correct FNSKU, printed in one batch and applied by his factory without a single mismatch. He had just enrolled in Amazon Transparency to stop a counterfeiter from selling next to his listing, and he wanted to know how quickly we could add the new code before the container left the dock. The answer was not fast. His container held 6,400 units, and Transparency does not print one code and repeat it 6,400 times. It requires a different code on every unit.

That distinction sounds small until you are standing at a prep bench trying to apply it. An FNSKU is one barcode design, generated once for a seller and a SKU, printed on a roll, and stuck on unit after unit without anyone checking which label came off the printer first. A Transparency code, or a Project Zero serialized code, is a different barcode on every unit, and the prep station has to know exactly which code belongs on which unit, in order, with no repeats and no gaps. That is not a labeling job anymore. It is a tracking job that ends with a label.

Most of what gets written about Transparency and Project Zero covers why a brand should enroll. Almost nothing covers what changes on the receiving dock once it does. This article covers that operational side: what a serialized code is next to an FNSKU, why it breaks batch labeling, how a code gets tied to a unit, what it does to cost and error rate, what happens to an unused code or a returned unit, and whether the code belongs at the factory or the prep center.

FNSKU Repeats the Same Code. Transparency and Project Zero Never Do.

An FNSKU is generated once for a seller and a SKU. Every unit of that SKU shipped by that seller carries the identical code. The code exists to identify which seller owns a listing, not to identify one physical unit apart from a thousand others just like it, which is why FNSKU labeling has always been a batch operation: print identical labels, apply them, spot check a sample, and move the pallet along. We cover the mechanics of that code, and how it differs from a manufacturer barcode, in our guide to FNSKU versus UPC versus manufacturer barcode, and in our guide to the manufacturer barcode rule that now limits who can skip FNSKU at all.

Transparency works on a different unit of measurement entirely. Instead of verifying a SKU, it verifies a physical unit. Every unit enrolled in Transparency gets its own unique code, whether Amazon generates it or the brand registers its own pre-existing serials into the program, and Amazon scans that specific code at the fulfillment center before the unit carrying it ships to a customer. A counterfeit unit without a valid code does not ship. That is the entire mechanism, and it depends on no two units ever sharing a code.

Project Zero adds a layer that gets confused with Transparency more often than it should. At its core it is a listing enforcement program: automated scanning for infringing listings, plus a self-service tool that lets an enrolled brand remove a counterfeit listing directly instead of waiting on an Amazon investigation. Neither tool touches a physical unit, but Project Zero also includes an optional third tool, product serialization, which works the same way Transparency does. A brand can enroll and never serialize a single unit, using only the listing tools, or add serialization and end up managing the same per unit code problem a Transparency enrollment creates. We covered the broader Brand Registry program both sit under in our complete guide to Amazon Brand Registry, but that guide stops short of what happens once a brand applies the codes at scale. That is the gap this article fills.

Why One Unique Code Per Unit Breaks a Batch Labeling Line

A standard FNSKU run is forgiving by design. The label does not change from the first unit to the last, so if a technician grabs the wrong label from a different roll, the fix is a reprint, nothing more. Quality control means confirming the correct code is on the correct product, checking placement and scannability on a sample, and moving forward. The line runs at full batch speed because every label in the stack is identical.

A serialized run removes that forgiveness completely. Every label is a different image tied to a specific position in a code list, and the unit that receives label number 4,821 has to be the same unit the system records as having received code 4,821, not 4,820 or 4,822. If an operator applies labels out of sequence, a printer skips a code because of a jam, or two units swap positions coming off the line, the record no longer matches reality. On an FNSKU run that slip is invisible and harmless. On a serialized run it is a defect only caught by scanning the applied code against the expected code, unit by unit, not by checking a sample afterward.

That single requirement, a scan to verify instead of a visual check to confirm, is what actually breaks batch labeling. It replaces a station that can run at full print speed with one that can only run as fast as one code can be printed, applied, scanned, and logged before the next one starts. A facility publishing a labeling throughput number for standard FNSKU work, ours included at 13,200 labels per hour, is publishing a number that assumes identical labels moving through a batch process. A serialized run on the same equipment will not hit that number, since the verification step happens once per unit rather than once per batch. Anyone quoting a flat per unit rate for serialized labeling that matches a standard FNSKU rate has probably not run one yet. For the labeling side of this problem, see our FBA labeling service page, which covers what a standard run involves before serialization gets added on top.

How a Code Moves From Amazon's System to the Physical Unit

Before a single label gets printed, the code has to exist somewhere as data. A brand enrolls a SKU in Transparency, or adds serialization inside a Project Zero enrollment, and Amazon issues a batch of unique codes sized to the expected run, or the brand registers its own compliant serials if it already uses them elsewhere. Either way, the codes exist as a list before they exist as labels. Someone then converts that list into physical labels, in the same order units move through production or the prep station, and records which code landed on which unit as it happens.

This association step has no real equivalent under FNSKU. An FNSKU label carries no information about which unit it is on beyond the SKU itself, so there is nothing to associate beyond confirming the right code is on the right product family. A Transparency or Project Zero code carries information about one specific unit, and if that association breaks between the code list and the physical carton, the brand has no reliable way to reconstruct it later. We cover related inbound tracking mechanics in our guide to tracking an FBA inbound shipment.

FNSKU, Transparency, and Project Zero Side by Side

The table below lines up the three mechanisms on the four questions that determine how much work they add to a prep operation: who generates the code, where it gets applied, what it costs relative to standard labeling, and what happens when a unit shows up without one.

Read the last row carefully, because it is the difference most brand owners miss. A missing FNSKU gets caught early, at receiving, where a prep center or Amazon can still fix it. A missing or invalid Transparency or Project Zero code gets caught later, at the outbound scan, closer to the customer. A mistake at receiving costs a relabel. A mistake at outbound costs a held unit and a delayed order.

What Serialization Does to Cost Per Unit and Error Rate

Cost per unit stacks in three layers once serialization enters the picture. The first layer is the per-code fee. Amazon does not publish an official price list for Transparency codes, and sellers using the program report a fee in the range of one to five cents per unit, on top of whatever the label application already costs. The second layer is labor: a standard FNSKU application is visual, apply, confirm placement, move on. A serialized application adds a scan to verify the exact code against the exact unit, once per unit rather than once per batch, which is also why throughput drops. The third layer is reconciliation, and brands consistently underbudget it: someone has to manage the code list, confirm every issued code either shipped or was reported as unused, and produce that record on request.

The error rate under serialization has no real parallel under FNSKU, because FNSKU mistakes are almost always cosmetic and reversible. Serialized errors are neither. A duplicate code, two units carrying the same code because of a printer misfeed or an operator pulling two labels at once, is not fixable with a reprint, since the code itself now exists twice in a system built around the assumption that it exists once. A code to carton mismatch, the right code logged against the wrong carton, breaks the traceability the program exists to provide. A skipped serial can trigger Amazon to hold an entire shipment while it investigates why an issued code never shipped. None of this shows up in a standard FNSKU spot check. See our piece on FNSKU mis-scans and print quality, and our guide to FBA shipment creation errors, for how these errors cascade.

Leftover Codes and Returned Units: The Reconciliation Nobody Budgets For

Amazon issues a batch of codes sized to an expected production run, and runs rarely land on the exact number planned. If a run comes up short, the brand holds codes that were issued but never applied. Those leftover codes cannot sit unused, and they cannot roll onto a later, unrelated run either. A code with no matching shipped unit, or a code reused across two batches, is exactly the pattern Transparency and Project Zero serialization are built to flag as suspicious. The correct handling is reporting unused codes as void inside the brand's own dashboard, closing the loop before the next run starts.

Returned units create the same problem from the other direction. Once a code ships on a unit, it is treated as consumed as a matter of record, regardless of what happens to the unit afterward. A customer return, a warehouse write off, a damaged unit pulled from a shipment, none of it frees the original code, not even for a direct replacement from the same run. A returned unit headed back into sellable inventory generally needs a fresh code and a fresh look at its condition, rather than restocking under the code it already carried. This compounds how a misgraded return already complicates inventory, covered in our guide to the FBA returns loop and misgraded reinspection, and it compounds the dispute process in our guide to reimbursement for lost inbound shipments, since a brand disputing a missing unit now also has to account for the code it carried.

Factory or Prep Center: Where Should the Code Actually Go On

The decision comes down to where the individual retail unit gets finished, since the code has to go on the unit itself, not the outer case. If a factory already finishes retail packaging as part of production, adding code application there is usually cheapest, since it folds into work already happening. It also satisfies the requirement that every unit sold anywhere carries the code in one pass, which matters for a brand selling through more than one channel.

The tradeoff is visibility. A code applied at an overseas factory cannot be verified until the shipment has already crossed an ocean, and a duplicate or mismatched batch found after transit is far more expensive to fix than one caught before a container leaves the origin port. A prep center closer to Amazon receiving offers the opposite tradeoff: it adds a labor cost the factory avoids, but it gives a brand one more checkpoint to reconcile a code list against actual units before the shipment enters Amazon's system, exactly the moment a duplicate or missing code is cheapest to fix. Brands running multiple SKUs through variable batch sizes, or working with a factory not equipped to manage a code list, tend to run a verification pass at the prep center even when the codes were applied earlier.

Whichever side of that decision a brand lands on, the question to ask a prep partner is specific. Has the facility applied a serialized code before, on a real production run rather than a pilot? What error rate will it commit to in writing before a shipment is routed through it? How does it document unused and retired codes so the brand has a record if a dispute asks for one? PrepVia is Amazon SPN Certified, labels FNSKU units at 13,200 labels per hour with 99.9 percent accuracy, and runs a 24 to 36 hour prep window, and we have not published serialized code data of our own, since that is a different operational question than standard FNSKU labeling. Ask any partner, ours included, before committing a run to it. See our FBA labeling service page for unit level labeling, and our page for brand owners for how we work with brand accounts.

Frequently Asked Questions

What is the difference between an FNSKU and a Transparency code?

An FNSKU is one barcode generated once for a seller and a SKU, and every unit of that SKU carries the identical code. A Transparency code is different on every physical unit, assigned individually and scanned by Amazon before that unit ships to a customer. The FNSKU identifies which seller owns a listing. The Transparency code verifies which unit is authentic.

Does Project Zero require product serialization?

No. Project Zero includes three tools: automated scanning for infringing listings, a self-service tool that lets an enrolled brand remove a counterfeit listing directly, and an optional serialization tool that works the same way Transparency does. A brand can enroll and use only the listing level tools without serializing a single unit.

Can a factory apply Transparency codes, or does it have to happen at a prep center?

A factory can apply the codes, and in most cases that is where it happens, since the code has to be on every unit a brand sells anywhere, not only units bound for Amazon. A prep center can also apply codes on unfinished units, or run a verification pass on codes already applied, giving a brand one more checkpoint before the shipment reaches Amazon.

What happens to Transparency codes that are never used?

A code Amazon issues but that never ships on a unit needs to be reported as unused inside the brand's dashboard. Leaving it unreported, or applying it later to an unrelated unit, creates a mismatch between the registry and what actually shipped, the exact pattern Amazon's detection systems are built to flag.

Does a returned unit keep its original Transparency code?

The code stays tied to that unit as a matter of record, treated as consumed once it ships, regardless of whether the unit is later returned, damaged, or written off. It cannot transfer to a different unit, including a direct replacement from the same run.

How much does Transparency add to the cost of prep?

Amazon does not publish an official price list for Transparency codes, and sellers using the program report a per-code fee in the range of one to five cents per unit, on top of the physical application cost. The bigger increase usually comes from labor, since each unit needs a scan to verify step a standard FNSKU run does not require.

What happens if a unit reaches Amazon without its serialized code?

A unit missing its FNSKU is typically held or relabeled at receiving, often for an unplanned prep fee. A unit enrolled in Transparency or Project Zero serialization without a valid code is caught further downstream, since the verification scan happens before it ships to a customer rather than when it first arrives.

Final Take

The brand owner who called in July was not wrong to expect a fast answer. He had already done the hard part, enrolling in Transparency and getting his codes issued, and assumed the last step was just another label. It is not. A serialized code turns labeling into a tracking discipline, and that discipline has to be designed into a production run before the first code gets printed, not bolted on at the dock while a container waits.

None of this makes Transparency or Project Zero serialization a mistake to enroll in. Counterfeit protection at the unit level is worth the cost for a brand losing sales to a hijacker or a fake listing. What it is not, is a checkbox added to an existing FNSKU workflow for a few extra cents a unit. It is a different process, with its own error modes, its own reconciliation requirements, and its own decision about where the code belongs.

If you are weighing Transparency or Project Zero serialization for a catalog, settle the factory versus prep center question before you enroll the first SKU, not after the codes are issued. Model the per-code fee and the added labor into your landed cost per unit from the start, and ask any partner handling the physical application how they document a code from the moment it is issued to the moment it ships or gets formally retired. A prep center that cannot answer that in detail has not done this work yet, and a container waiting at a dock is the wrong place to find out.