How Do Unique Identifiers Work in Passport Software?

A unique identifier in software systems is the persistent key that links a physical battery, its data carrier and its passport record, and that allows the same battery to be recognised across operator, supplier, repairer, recycler and authority systems. Article 77 requires a unique identifier for the battery passport, and Article 78 requires that the identifier be uploaded to the registry. The identifier is therefore a legal key as well as a software key, and its formation, allocation and resolution must be designed as a compliance control, not as a database convenience.

Identifier failure is a system failure, not a labelling failure. A duplicate identifier merges two batteries into one record. A reused identifier after a battery is replaced creates a false history. An identifier that cannot be resolved breaks the carrier link and the registry link at once. Software design should therefore treat identifier allocation as a gated, audited process, with uniqueness checks, allocation records and resolution tests, rather than as an automatic field generated at record creation without control.

What makes an identifier unique?

An identifier is unique when it is allocated once, to one individual battery, and never allocated again to a different battery, within the identifier system used for passports. Uniqueness requires a defined identifier format, a defined allocation authority or process, and a uniqueness check at allocation time. A serial number that is unique within one factory but duplicated across factories, or a number that is reused after a production run, is not unique in the passport system, even when it is unique in a local system. The uniqueness scope is the passport system, not the local database.

Uniqueness should be tested by attempting to allocate a duplicate identifier in a test system, and by querying the identifier system for collisions across the full allocation history. A test that checks only the current record set misses historical duplicates that remain in the registry or in authority files. The allocation record should preserve every identifier ever allocated, including identifiers for batteries that were scrapped, recalled or never placed on the market, so that reuse can be detected.

How is an identifier formed?

An identifier is formed under the identifier rules that apply to digital product passports, including the harmonised standard for unique identifiers and the product group rules for batteries. Formation covers the identifier syntax, the operator and product components, the check character or validation where provided, and the encoding in the data carrier. A well formed identifier that follows the syntax but uses an incorrect operator component will resolve to the wrong operator, while a poorly formed identifier may not resolve at all. Formation, operator component and carrier encoding must all be correct for the identifier to work.

Worked check: a batch of identifiers is generated with a correct format but an outdated operator component after a corporate change. The identifiers resolve to the former operator record, and the current operator cannot update the passports. The correction requires reissuing identifiers or updating the operator linkage through the registry process, with the original identifiers preserved in the audit trail. A formation check at allocation time, against the current operator identity, would have prevented the batch error.

How is an identifier allocated and recorded?

Identifier allocation should be a controlled step in the manufacturing or placing workflow, with the allocation event recorded against the battery model, production date, manufacturing site and operator. Allocation should occur once per individual battery, at a defined point in the workflow, and the allocation record should be immutable for the identifier itself, with changes recorded as linked events rather than overwrites. A workflow that allows identifier allocation at several points, by several roles, without a single allocation control will produce duplicates and gaps.

Allocation records should be reconciled against production records and placing records, with a report listing identifiers allocated, batteries produced and batteries placed, and any mismatch investigated. A reconciliation that lists only allocated identifiers, without production and placing counts, cannot detect an identifier allocated to a battery that was never produced, or a battery produced without an identifier. The three counts should agree, or the difference should be explained and filed.

How does identifier resolution work?

Identifier resolution is the process by which a data carrier scan or a registry query returns the passport record for the battery, through the operator system that holds the record. Resolution requires that the carrier encodes the identifier correctly, that the identifier resolves to the correct operator system, that the operator system is available, and that access rights are applied to the returned data. A failure at any step breaks resolution, and the software should report which step failed, so that the correction is applied to the correct system.

Resolution should be tested from outside the operator system, using a standard scanning device and a standard registry query, with the result recorded. A test carried out only inside the operator system, using internal links, does not prove that an external actor can resolve the identifier. The external test should be repeated after a hosting change, a domain change or an identifier format change, because each change can break a link in the resolution chain.

What happens when an identifier is compromised or misprinted?

When an identifier is misprinted, duplicated or otherwise compromised, the affected batteries should be identified, the identifier history should be preserved, and the correction should follow the registry and passport updating process, with a new identifier allocated only where the rules provide for it and with linkage to the original identifier. A misprinted carrier should be replaced with a carrier linked to the same identifier, where the identifier itself is correct. A duplicate identifier should be treated as an identity incident, with the affected batteries quarantined from placing until the duplication is resolved.

Incident handling should be recorded as an identifier incident file, with the identifiers affected, the cause, the correction and the verification test. A file that records only the correction, without the cause, cannot prevent recurrence. A file that records the cause and the process change that follows can prevent the next incident. Identifier incidents should be reviewed as system incidents, not as individual printing errors, because the cause is usually a process gap rather than a single mistake.

How are identifiers managed across life stages?

Identifiers across life stages must preserve linkage from the original battery to the resulting battery after preparation for reuse, repurposing or remanufacturing, with the new identifier linked to the original where the Regulation requires it. The original identifier should not be reused for the resulting battery, and the resulting battery should not be given an identifier that hides the original history. As checked on 28 October 2026, the detailed linkage rules depend in part on acts under Article 77, so identifier management across life stages should carry a review date. This guide gives general educational information only and is not individual legal advice. A reader with a specific battery or market decision should check the current Regulation text and any applicable delegated act, as checked on 28 October 2026, before acting.

This guide gives general educational information only and is not individual legal advice. A reader with a specific battery or market decision should check the current Regulation text and any applicable delegated act, as checked on 28 October 2026, before acting. Identifier allocation is a gated control, and resolution should be tested from outside the operator system.