A UHF RFID reader may return a value such as 3066C4409047E140075BCD15 while the asset or item table contains a GTIN, a serial number or an enterprise asset code. Both values can be correct representations at different layers. Matching them requires the application to know which memory field was read, which encoding scheme applies and which business key the database expects.
This guide uses a GS1 standards example and editorial exception branches. It is not an AIDC GO device test, a customer deployment or an allocated identifier for AIDC GO. The RFID mobile-computer category, RFID sled category and Integration Support are starting points for a documented reader, SDK and application review.
Identify the field and representation before decoding
First ask which memory bank and byte range produced the value. Some interfaces return only the EPC binary payload as hexadecimal characters. Others expose protocol-control words, CRC, bank address, length, antenna, timestamp or separate TID and User-memory values. A string from TID is not decoded as an EPC merely because it is hexadecimal.
The UHF RFID memory-bank guide explains why EPC, TID and User memory have different roles. Record the reader model, firmware and SDK version, inventory or access operation, bank, offset, returned bit or byte length, and formatting rule. Preserve the original output before removing separators or changing case.
Hexadecimal is a compact display of bits, not a promise that each byte is an ASCII character. Interpreting 30 as the text character 0, or decoding the entire EPC as arbitrary text, bypasses the encoding scheme. Determine the scheme from the complete binary pattern and the applicable standard or project specification.
Walk one standards example from hex to the business fields
GS1's EPC Tag Data Standard, Release 2.3, Ratified October 2025, Appendix E.3 provides an SGTIN-96 example. Its EPC binary encoding in hexadecimal is 3066C4409047E140075BCD15. The same example represents the EPC Tag URI urn:epc:tag:sgtin-96:3.95060001343.05.123456789 and the GS1 element string (01)09506000134352(21)123456789.
The fields are not recovered by cutting every EPC at one fixed character position. For SGTIN-96, the header selects the scheme, the filter describes an application context rather than the item identity, and the partition determines how many bits and decimal digits belong to the GS1 Company Prefix and Indicator/Item Reference. The serial occupies its defined field. Translation must preserve the scheme's padding and field constraints.
| Representation stage | Standards example | Application decision |
|---|---|---|
| Reader EPC payload, hex | 3066C4409047E140075BCD15 |
Confirm this is the complete 96-bit EPC payload, not another bank or an EPC-bank wrapper |
| EPC Tag URI | urn:epc:tag:sgtin-96:3.95060001343.05.123456789 |
Retain tag-encoding fields such as filter when the interface contract needs them |
| EPC Pure Identity URI | urn:epc:id:sgtin:95060001343.05.123456789 |
Use the identity representation when it is the agreed database key |
| GS1 element string | (01)09506000134352(21)123456789 |
Keep GTIN and serial as separate structured fields when the business application expects them |
The EPC Tag Data Translation Standard, Release 2.2, Ratified February 2025, defines machine-readable rules for validating and translating between binary, tag-encoding, pure-identity, element-string and GS1 Digital Link representations. It also preserves significant leading zeroes according to the scheme. A production application should use a tested standards-conformant implementation or equivalent verified logic rather than a substring formula copied from one sample.
Keep the product class and serialized item together
In the example, AI 01 carries GTIN 09506000134352, which identifies the trade-item class. AI 21 carries serial 123456789, which distinguishes the serialized instance under the scheme. Matching only the GTIN can find a product class but cannot prove which individual tagged item was observed.
The database contract might use the EPC Pure Identity URI as one key, or it might use a structured pair of GTIN and serial. Either can work when assignment and uniqueness rules are explicit. Do not drop the serial to force a product-level match and then claim that the application identified the same physical item. Conversely, a serial string without its scheme and product context may not be globally meaningful.
The tag-commissioning guide covers allocation, write, readback and authoritative binding. This guide starts at a later interface boundary: a value has been read and must be translated into the same identity representation used by the business record.
Distinguish a GS1 EPC from a project-defined code
A 24-character hexadecimal string is 96 bits, but length alone does not prove SGTIN-96. Other EPC schemes and enterprise-defined bit layouts can have fixed lengths, and an unsupported or malformed header can make a string fail the selected decoder. A custom EPC can be valid for a closed project without being translatable as a GS1 SGTIN.
For a GS1 EPC, validate the recognized header, total length, partition, field ranges and scheme-specific serial constraints. For a project-defined encoding, keep its versioned bit layout, assignment authority, examples and migration rule. Never run a custom value through an SGTIN parser only because the output looks hexadecimal.
Normalize only what the contract permits. Upper- and lower-case hexadecimal can represent the same bits, and visual separators may be removed for comparison, but leading zeroes and the complete fixed-width payload must be preserved. Do not pad an unexpected short read until the interface documentation proves that only display padding is missing.
Use three different exception branches
Start with the preserved raw value and declared source field. If the character set or length is invalid for the interface contract, return a format error and retain the received data. If the bytes are well formed but no supported encoding scheme matches, return an unsupported-scheme result rather than guessing ASCII or SGTIN. If translation succeeds but the canonical identity has no active database row, return a record-not-found result.
Those branches lead to different owners. Interface formatting goes to the device or SDK configuration. Scheme support goes to the encoding and translation component. A valid decoded identity with no record goes to commissioning, master data or task scope. One generic “RFID failed” message hides the evidence needed to fix the right layer.
A successful decode and database match is not tag authentication. It establishes only that the observed bits translated to a known identifier under the chosen rule. Any authenticity, access-control or anti-cloning requirement needs a separate tag, cryptographic and application design. The NFC UID mapping guide addresses a different HF/NFC identifier path and must not be used as a UHF EPC decoder.
Require a round-trip test and an auditable mapping
For the standards example, decode 3066C4409047E140075BCD15 to the selected canonical representation, then encode that representation back under the same SGTIN-96 parameters. The normalized result must return to 3066C4409047E140075BCD15. Also compare the GTIN and serial fields independently with (01)09506000134352(21)123456789. A round trip checks consistency, but matching errors in decoding and encoding can still reproduce the original bits. Independently verify the decoded fields against a trusted reference.
Acceptance should include a correct SGTIN, a bad-length string, an unsupported header or scheme, a valid identity absent from the database, and two serialized items that share the same GTIN but have different serials. Record reader output, bank and length, decoded scheme, canonical key, match result and application action. Do not replace the raw read with the decoded value; keep both for diagnosis.
Ask suppliers for the exact reader and SDK output definition, supported memory operations, available symbology or scheme metadata, translation-library version, error reporting and sample records. Use RFID Inventory & Asset Tracking to place the identifier inside the wider workflow, and Contact AIDC GO to discuss a documented configuration. No built-in GS1 EPC parser, scheme coverage or authentication function is implied for an AIDC GO model without approved evidence.