RFID projects don’t fail because tags “can’t be read.” They fail because the data plan is messy. You get duplicate IDs, “unknown tag” noise at dock doors, and a WMS/ERP that can’t match reads to real items. So let’s talk about the three IDs people mix up all the time—EPC, UID, and Serial Numbers—and how to plan them like you actually want clean operations.
Along the way, I’ll map this to the product families we build at CXJ Smartcard (factory-direct OEM/ODM, from antenna to finished goods, with encoding/personalization and ISO-led QC).
Think of RFID like a warehouse conversation:
Here’s a quick table you can steal for your spec doc:
| Data field | Where you’ll see it | What it’s best for | Typical “oops” | Source |
|---|---|---|---|---|
| EPC | UHF EPC memory (most common), sometimes HF mapping | Fast bulk reads, inventory, logistics, retail | Re-using EPCs across batches → ghost inventory | GS1 EPC concepts + shop-floor best practice |
| UID / Chip UID | Chip UID / TID (depends on chip family) | Anti-counterfeit checks, “tag identity,” encoding station control | Assuming UID = EPC (not always) | Chip/reader behavior (common RFID practice) |
| Serial Number | Inside EPC scheme or your backend | Uniqueness per item | Serial means 3 different things across teams | GS1 / ISO practice + DoD-style definitions |
If you want a supplier that can encode and personalize (UID/EPC mapping, NDEF for NFC, CSV mapping, verification), build that into the PO from day one. We do this every week, so it’s not “extra work,” it’s just normal manufacturing workflow.
Here’s my opinionated take: don’t invent your own ID format unless you enjoy rework.
When you stick to GS1 EPC or ISO/IEC structures, you get:
If you go “free-style” (ASCII dumps, SKU+date+random), it can work for a pilot. Then you scale, and it start breaking in weird places—especially when partners bring their own readers and middleware.
Most teams end up using 96-bit EPC because it’s widely supported and fast. Cool. But 96-bit schemes often come with constraints (for example: numeric-only serial rules in certain setups), and the rules around leading zeros can wreck your matching logic.
A simple rule that saves pain: write your serial policy like a contract.
| Serial policy choice | Example | What can go wrong | Practical fix |
|---|---|---|---|
| Allow leading zeros | 000034 | Some systems treat it as “34” and dedupe it | Decide one format; pad only in UI, not in ID |
| Mix letters + digits | A12B9 | Your EPC scheme may reject it | Keep EPC serial numeric; store fancy serial in DB |
| Reset serial each month | 000001 every Jan | Duplicate EPC across time = chaos | Use global uniqueness, not calendar uniqueness |
In real ops, duplicates don’t show up immediately. They show up during cycle count at 2am, when everything is moving fast and nobody wanna debug encoding rules.
People say “serial number” and mean totally different stuff. So define it in your document, like this:
| Term you should use | Meaning | Who cares most |
|---|---|---|
| Product Serial Number | Manufacturer’s product serial (printed/engraved) | Warranty, service, after-sales |
| EPC Serial (within scheme) | The unique portion inside EPC | WMS/ERP, inventory, retail compliance |
| Chip UID / TID | Silicon identity (often factory-set) | Security, authentication, encoding control |
If you don’t define these three, your team will “merge” them by accident. Then somebody locks tags, and congrats… you just locked the wrong truth into thousands of units. It happens more than you think.
A clean encoding workflow looks like this:
This is where product choice matters, because different form factors live in different realities.
Here’s the super practical view:
| Memory area | What teams store there | When it makes sense | Shop-floor note |
|---|---|---|---|
| EPC memory | EPC ID | Almost always (UHF logistics/retail/laundry) | Keep it short and standard |
| TID / UID | Chip identity | Anti-fraud, encoding station control | Great for “which tag am I writing?” |
| User memory | Extra fields (batch, asset class, flags) | Only if your readers are configured to read it | Don’t hide critical data here by accident |
Now, let’s tie this to real CXJ product categories.
These are usually HF/NFC (13.56 MHz) and used for access control, attendance, membership, and tap-to-phone flows. Our RFID Cards support printing plus chip encoding/UID programming for system integration.
Our NFC Tags cover labels/stickers/inlays/on-metal options and common NTAG chips for phone-friendly use.
Our RFID Keyfobs often need durable materials and can include laser UID engraving + serial numbering + encoding keys, because people treat them rough, like daily keys.
Useful internal links (keep your buyers moving):
If you’re doing logistics, retail, or asset tracking, you’re probably in UHF land. Our RFID Sticker Labels support LF/HF/UHF chips, PVC/Paper/PET materials, and full customization (size, adhesive, encoding, printing).
Our RFID/NFC Inlay lineup supports HF/UHF inlays for converting and automated production flows (roll/sheet formats).
Internal links:
Laundry is where encoding mistakes get punished fast. Tags get washed, sorted, and scanned in bulk, so duplicates become “missing linen” or bad billing.
Internal links:
Different surfaces, different pain:
Internal links:
Here’s the punchline: Don’t cram everything into the tag. Use EPC as your fast key, store rich data in your system, and use UID/TID when you need stronger identity checks.
A couple real-ish scenarios (short, but true enough):
If you want smoother rollout, bake these into your RFQ:
At CXJ Smartcard, we support OEM/ODM from antenna to finished tag, plus encoding/personalization, fast sampling, flexible MOQ, global shipping, and ISO-based QC with outgoing inspection.
You pilot quick, then you scale without changing the rules mid-flight. That’s the goal. And yeah, sometimes your first spec will have tiny mistakes—no shame—but fix it before mass production, not after.
If you want, paste your current ID format (even messy one), and I’ll rewrite it into a clean EPC/UID/serial policy doc you can hand to your integrator and factory.
