AN INDEPENDENT KNOWLEDGE PUBLICATION Our editorial approach ↗
BatteryPassport.digital Search guides /
Menu & topics
QR codes & identifiers

QR code failure and fallback: what to do when a battery code will not scan

A failed scan has a fallback route through manual identifier entry and documentation, and the fallback must reach the same record as the scan.

GUIDE / QR CODES & IDENTIFIERSIDENTITY → INFORMATION → EVIDENCE

A QR code can fail. The code can be damaged, worn, covered, misprinted, or printed with a payload that no longer resolves. The scanner can fail, the network can fail, or the resolver can fail. Failure is not an exception to be handled informally. It is a predictable event in the life of a battery, and the record system needs a fallback route that reaches the same record, through a different path, without creating a duplicate record or a second identity.

A fallback that reaches a different record, or that allows a reader to proceed without identity verification, is worse than no fallback, because it creates a false sense of access.

What are the common failure modes?

Failure modes fall into four groups. Physical failure means the symbol is damaged, abraded, faded, covered or detached. Payload failure means the symbol decodes but the address is wrong, expired, or points to an unexpected domain. Resolution failure means the address is correct but the identifier is unknown, the resolver is unavailable, or the record has moved without a redirect. Access failure means the record is reached but the reader cannot view the tier needed, because authentication fails, the grant has expired, or the tier boundary is misapplied. Each group has a different owner and a different remedy. Physical failure is owned by printing, labelling and operation records. Payload failure is owned by the identifier and resolver system. Resolution failure is owned by the record system. Access failure is owned by access control. A failure report that does not name the group cannot be assigned, and an unassigned failure is not fixed.

What is the first fallback step?

The first fallback step is to try the scan again under better conditions: clean the code surface where safe to do so, improve lighting, change angle and distance, and try a second scanner. Many failures are transient, caused by glare, reflection, low light or a scanner that needs a steadier hold. The second scanner test distinguishes code failure from scanner failure. If the code reads on a second scanner, the first scanner or the conditions were at fault, and the code itself is sound. If the code fails on two scanners under good conditions, the code or the payload is at fault, and the next fallback step is needed. The attempt record should note the scanners tried, the conditions, and the outcome, so that a later reader does not repeat a failed attempt without knowing it was already tried.

What is the manual fallback route?

The manual fallback route uses the identifier as marked on the battery, on packaging, or in accompanying documentation, entered by hand into the record system or resolver. Manual entry requires the full identifier, entered exactly, with check characters where the identifier format provides for them. The system should validate the entered identifier and should show the model and manufacturer for confirmation before displaying the record, so that a typing error that produces a valid but wrong identifier is caught by the reader. Manual entry is slower than scanning and more error prone, and the entry should be checked against the marking a second time before reliance. Where the identifier itself is damaged or illegible, manual entry from documentation is the next route, and the documentation reference should be recorded. Where no identifier can be recovered, the battery cannot be linked to a record, and that fact must be stated rather than bridged by assumption.

How is a failed code replaced?

A failed code on a battery in use is replaced by a new carrier bearing the same identifier, applied in a position that meets the placement rules, with the replacement recorded in the unit history or the operation record. The replacement must be checked by scanning after application, to confirm that it resolves to the correct record. A replacement carrier bearing a new identifier, without linkage, splits the history and must not be used. A replacement label applied over the old code must not obscure other required marking, and must use a substrate and adhesive suited to the battery surface and the operating conditions. Replacement is an operation on the battery, and the operation record should state the date, the actor type, the reason for replacement, and the scan check result. A code replaced without a record is a code whose history is invisible to the next reader.

What does the failure table summarise?

Failure groupDiagnostic testFallbackOwner
PhysicalSecond scanner, better light, clean surfaceManual identifier entry, replacement carrierLabelling and operations
PayloadInspect decoded address, check domainManual entry, resolver checkIdentifier system
ResolutionCheck identifier known, resolver statusManual entry, resolver support routeRecord system
AccessCheck tier, grant and authenticationAccess support route, do not bypassAccess control

What must a fallback never do?

A fallback must never bypass access control, never create a duplicate record, never assign a new identifier without linkage, and never allow a reader to proceed on an assumed identity. A reader who cannot establish identity through scan or manual entry should treat the battery as unidentified for record purposes, and should rely on inspection, testing and documentation rather than on a record that cannot be linked. This guide gives general educational information only and does not give legal advice for a particular battery, code or system.

Sources & further reading

Source links point to primary materials and further reading, including commercial implementation resources where cited. This introductory guide does not replace the legislation.