JNXRFID · Know-how Series · Data Integrity KH‑002
When the RFID Count Disagrees With Your ERP, Which One Is the Truth?
A physical count says forty-one. The system of record says thirty-eight. Three items, no obvious explanation, and a meeting where everybody assumes somebody else is wrong. This article gives an order of operations that resolves it without assigning blame, and explains why neither system is automatically the authority.
13 min read · Applies to operational deployments · Data reconciliation and ownership · First edition, October 2026
When the physical RFID count disagrees with our ERP or WMS stock records, which database do we trust as the ultimate source of truth?
The reason this question stalls is that it treats the two systems as competing versions of one fact. They are not. They are two different kinds of claim, and each is authoritative for a different question. The RFID layer is a timed observation of what was physically present. The ERP is the business interpretation of what should be there. Neither one is measuring both things.
Two different kinds of truth
Separating the claim types is the whole resolution. Once you can name which question you are asking, the disagreement becomes answerable.
| Question being asked | Authoritative source | Why |
|---|---|---|
| What is physically in this location right now? | The RFID observation | The ERP is not measuring anything. It is a record of an intention, entered earlier. |
| What should be in this location? | The ERP or WMS | The definition of correct stock levels lives in the business system, not in a reader. |
| What changed, when, and who was present? | The RFID event history | It is the only layer that records the transition, with a time and a custody context. |
| Did a discrepancy actually occur, and when? | The audit trail | This is the record you must never overwrite, or the discrepancy becomes invisible. |
The reconciliation order
When a discrepancy appears, the instinct is to check the count again. That usually does not help, because it re-observes the same problem. Work in this order instead, stopping when the cause becomes visible.
- Confirm the tag was read at all. Start from a raw tag event rather than the aggregate count. If no event exists for an item, this is a read problem, and it belongs to engineering. If events exist, the item was present at some point and this becomes a data problem.
- Decide which side moved. An item missing from the RFID side but present in the ERP suggests a missed read, an unencoded tag, or an item outside the zone. An item present in the RFID side but absent from the ERP suggests an unrecorded issue, a movement, or a mis-encoded tag. These are different investigations with different owners.
- Group the failures. Do not handle three failures as three cases. Group them by material, by location, by shift, by item type. Genuine read failures almost always cluster, because the cause is a property of the environment or the asset rather than of the individual tag.
- Check the encoding, not just the read. A tag that reads perfectly but was encoded with the wrong item reference will create a permanent, invisible discrepancy. This is the class of error that survives every re-count, and it originates upstream in labelling.
- Only then adjust data. Correct the record through the normal transaction path, so the change is attributable and the history is preserved.
Noise before signal: stop flooding the backend
A related failure produces the same symptom from the opposite direction. A tag sitting inside a read zone is read continuously, many times a second. If every one of those reads becomes an event, the backend receives a large volume of information that contains almost nothing, and genuine transitions disappear into the noise.
The correct architecture is to filter at the edge:
- Report state changes rather than individual reads.
- Aggregate events within a defined window so that one physical action produces one record.
- Publish what changed, not what was observed.
This matters more where containment is intentional. In a cabinet or tool crib, the meaningful record is a door session — who opened it, what was taken, what returned — not a stream of tag identities arriving at fifty per second.
Planning for a coverage ceiling below 100 percent
Somewhere between the pilot and go-live, a question always appears: what happens if coverage tops out at ninety-five percent instead of a hundred?
The honest answer is that passive UHF RFID in a reflective, moving, high-density environment will not reach a hundred percent on every asset, every time, and planning around that assumption is more expensive than planning for it. What matters is deciding the exception process before go-live.
| Decide this | Before go-live |
|---|---|
| Which items require complete coverage | Safety-critical and regulated items get a different standard from consumables. |
| What the manual exception step is | A second reader, a handheld scan, or a confirmation prompt. Choose one and write it down. |
| How often reconciliation runs | Short reconciliation cycles stop small discrepancies from becoming structural. |
| Who owns an unresolved discrepancy | A named role, not a department. |
| What read rate triggers escalation | A monitored metric with a threshold, reviewed on a schedule. |
The credibility argument
A coverage ceiling that was explicitly planned for is an operational reality that operations teams manage every day. The same ceiling discovered during an audit reads as an installation failure, and it will be attributed to the supplier even if the design was reasonable. This is a documentation problem more than a technical one, and it costs nothing to solve early.
Who owns it after the project ends
The last of the critical questions is the one most often left unanswered: once the integration team leaves, who owns maintenance, firmware updates, and the inspection of cables and connectors?
Without a named operational owner, systems drift quietly. Antennas get moved during a racking change. A firmware update changes a default setting. A cable run is shortened by someone who did not know the attenuation had been calculated. Nothing breaks loudly; the read rate simply declines until a discrepancy investigation uncovers a change made two years earlier with no record.
A workable handover names an owner with authority over four specific things:
- Firmware and reader configuration versions.
- Antenna positions and orientations.
- Transmit power and zone settings.
- The scheduled re-validation of read zones and the tag specification.
What to ask before you accept a system
The questions that matter are about process rather than hardware, and they are easy to ask early and awkward to ask late.
- How is a discrepancy between the count and the ERP record supposed to be investigated?
- What read rate do you commit to, on what surface, in what orientation, with what tag count in the zone?
- What is the manual exception procedure if an item is not read?
- Which events are filtered before they reach our systems?
- Who owns configuration and maintenance after go-live, and where is that recorded?
A supplier with a clear answer to these has run deployments before. If you want to test the answers on your own assets before committing, the evaluation unit exists for that purpose, and RFID smart cabinets are worth a look where custody and auditability matter more than raw read range.
From reconciliation to acceptance
Write the reconciliation rules before go-live
A count that disagrees with the ERP is not a hardware fault until the process has been ruled out. The acceptance questions in this article are the same questions that decide whether the system can be run by the team that inherits it.
- Agree which side is authoritative for presence and which for intent, in writing.
- Define the exception procedure before the first missed read, not after it.
- Test the read point, the encoding and the cabinet session on your own stock before acceptance.