RFID Integration with ERP: Architecture and Pitfalls

RFID promises a lot: count a whole pallet without unwrapping it, track assets without scanning them one by one, see stock moving through a dock door automatically. Some of that is real. Some of it depends heavily on physics and integration design.

This post covers how RFID connects to an ERP and the pitfalls we see most often.

The pieces

Tags

Most warehouse and retail RFID uses passive UHF tags following the EPC Gen2 standard. They have no battery. The reader's signal powers them. Each tag stores an EPC (Electronic Product Code), often encoded as an SGTIN that combines the product's GTIN with a serial number.

Tag choice matters more than people expect:

• Standard inlays and labels for cartons and apparel
• On-metal tags for metal assets and racking
• Rugged or high-temperature tags for returnable containers and harsh environments

Readers and antennas

• Fixed readers at dock doors, conveyors or portals
• Handheld readers for counting and searching
• Overhead or ceiling arrays for zone-level visibility in larger deployments

Most enterprise readers support LLRP (Low Level Reader Protocol) or vendor APIs, and many can push events over MQTT or HTTP.

Middleware

This is the part people skip, and shouldn't. A reader at a dock door might report the same tag dozens of times per second. Middleware:

• Filters duplicate reads
• Smooths out flickering reads at the edge of the field
• Turns raw reads into business events: "tag X passed dock door 2 inbound at 10:42"
• Decodes EPCs into product and serial
• Buffers events if the ERP is unavailable

What the ERP should receive

The ERP shouldn't see raw reads. It should see business events linked to documents:

• "These 48 EPCs were received against PO 1234 at dock 2"
• "Pallet SSCC 00123... left through dock 5 for delivery 5678"
• "Cycle count in zone A found these 612 EPCs"

The ERP then compares expected vs actual and posts receipts, deliveries or count adjustments, ideally with a human approving the differences.

Data model decisions

• Item-level or case-level? Item-level tagging gives the most visibility and costs the most. Case or pallet level is often enough for distribution.
• Serial tracking in the ERP. If every item has a unique EPC, the ERP needs to track serials. That's a big jump in data volume. Make sure your ERP and its database are sized for it.
• Tag commissioning. Who writes and applies tags? Suppliers, your receiving team, or production?

Pitfalls we see

1. Metal and liquids. Both interfere with UHF. Pilot with your real products.
2. Stray reads. A reader at dock 1 picks up tags on a pallet waiting near dock 2. Antenna placement, power tuning and shielding solve most of this.
3. Expecting 100%. Design processes for 99.x% read rates, with an exception flow for missed tags.
4. No exception handling. When the count doesn't match the ASN, who decides what happens?
5. Pushing raw reads into the ERP. It floods the database and the logs. Filter first.

Start with a pilot

Choose one process (inbound receiving at one dock, or cycle counting one zone), one product family and one reader type. Measure read rates and time saved over a few weeks. Then decide whether to scale.

For Odoo-specific architecture, see RFID integration with Odoo. Not sure RFID is right at all? Read RFID vs barcode first.