If you are the VP who has to sign the PO, you have already heard the pitch as a food-safety story. Put that aside for a moment, because it is not why this pays for itself. Case-level RFID pays for itself at the back door — in receiving labor and inventory accuracy — long before a single recall is ever run. Recall-readiness is real, and it is the floor underneath the investment. But if the only ROI line you can write is "faster traceback," you will lose the budget meeting, and you will deserve to, because that is not where the money is.
Here is how the cost actually breaks down, where the return actually shows up, and the one line item that never makes it into the RFID vendor's quote.
What are the real cost buckets in a QSR RFID rollout?
There are four, and they behave completely differently on your P&L. Confusing them is how these projects get mispriced.
- Tags — a per-case consumable. A RAIN RFID inlay goes on (or into) the corrugate for every case that moves. This is the one cost that scales linearly with volume forever. The single biggest lever on it is who applies the tag: if your supplier pre-tags the corrugate at their plant — encoded and verified before it ships — you pay for the tag inside the case cost and you never touch a label applicator. If you tag at your own DC, you have bought a labeling operation. Pre-tagged at source is the structurally cheaper model, and it is the one the public case studies describe.
- Readers and antennas — capex, mostly at the DC. Handhelds for associates, fixed portal readers at dock doors. This is a one-time-ish capital line that depreciates. It is real money, but it is bounded — you are outfitting doors and people, not every case.
- Deployment and read software — opex, usually a subscription. The middleware that turns a raw read into a usable inventory count, manages the readers, and runs the day-to-day floor workflow. This is where most vendors make their margin, and it is a recurring line.
- Integration and the record layer — the line that is missing from the quote. More on this below, because it is the one that decides whether you got an inventory tool or an asset.
A blunt honesty note, because the number-shopping starts here: the public record for the marquee QSR programs carries no per-case dollar figure, no total program cost, and no published payback period. Anyone quoting you "Chipotle spent $X" or "the tag costs Y cents at McDonald's scale" is making it up — none of that is public. What is public, and what you can actually underwrite against, is the shape of the return.
Where does the ROI actually show up — receiving, inventory, or recall?
Receiving and inventory first. In that order. Recall is the floor, not the lead.
The strongest public data point is McDonald's China with Cainiao — the "One Box, One Code" program, one RFID digital ID per package — which reported a +30% improvement in receiving and inventory efficiency at production scale (China Daily, Nov 28, 2024). Read that carefully: it is an efficiency number, not a compliance number. It is proof that a Fortune-tier QSR will fund this at scale when the return lands in operations — and that the return lands in the two places you already have KPIs for. (One scoping caveat so nobody oversells it to you: that +30% figure is McDonald's China, with Alibaba's logistics arm. It is the cleanest public proof of the efficiency thesis; it is not a claim about any US program.)
The mechanism is not mysterious. A case with a tag on it:
- Receives itself. A portal read at the dock replaces a human scanning barcodes case by case, or worse, counting pallets and trusting the ASN. Receiving labor per truck drops, and the receiving record stops depending on whether a tired associate scanned every unit.
- Counts itself. Cycle counts and on-hand accuracy stop being a periodic manual project. Inventory shrink and the phantom-stock problem — the store system says you have it, the walk-in says you don't — is exactly what item-level reads attack.
- Shows its date. When the encode carries production/pack data, first-expiry-first-out stops being a hope and becomes enforceable.
The recall math is genuinely valuable — the difference between a full recall and a narrow lot-level withdrawal is worth more than the entire rollout the one time you need it — but it is a tail event. You cannot build the business case on the tail. You build it on receiving and inventory, and you let recall-readiness be the risk reduction that makes the CFO comfortable rather than the revenue line that makes them skeptical.
Does the tag encode quality change the ROI?
More than the tag price does, and this is the part that gets under-weighted. A tag that reads 88% of the time is not 88% of the value — it is a manual exception process bolted onto every receiving, which means you kept the labor you were trying to remove.
The public benchmark here is the Golden State Foods RAIN RFID case study — case-level, pre-tagged corrugate at a protein plant, GS1 TDS 2 encoding, with a reported 100% encode success (GS1 US case study). That number is the whole ballgame for the ROI model: encode-at-source, verified, at 100% is what lets you actually remove the human from receiving instead of adding a QC step. Tag pennies are a rounding error next to a read rate that forces exceptions. Underwrite the encode program, not the tag unit cost.
The line item missing from every RFID quote
Here is the one that decides whether you bought a tool or an asset. Every quote you will get prices buckets 1–3: tags, readers, software. **None of them prices the durable, standards-conformant event record — the place the reads land and stay.** And that omission is not an accident; it is the vendor's business model. If your reads live in the reader vendor's cloud, your visibility is a subscription you can be evicted from, and the "record" you would hand an auditor is one you don't actually control.
The reads are the easy 90% of the spend and the disposable part of the value. The record — one canonical EPCIS 2.0 event per receiving, keyed to the GS1 identifier already in the tag, append-only, and yours — is the cheap part of the spend and the durable part of the value. It is what turns "we scanned 40,000 cases last quarter" into "here is where lot 7742 went, in minutes." A rollout that funds the readers and skips the record layer arrives in production able to count inventory and unable to answer the one question the whole program was justified on.
That record layer is exactly what we build, in the open, against GS1's own EPCIS 2.0 and CBV 2.0 — and the policy is that writing an event down never costs money and is never metered — stated ahead of published terms. The hosted record layer is a named entry in the open P0 ledger — a build task with an owner, not soft copy. The economics of the reads, meanwhile, stand on their own: the receiving-and-inventory return justifies the RFID spend whether or not any deadline ever hardens.
The one-page version for the budget meeting
- Cost: a per-case tag consumable (cheapest when pre-encoded at the supplier's plant), bounded reader capex at your DCs and doors, a recurring deployment-software subscription, and — the line nobody quotes — the record layer.
- Return, in order: receiving labor, then inventory accuracy, then recall-readiness as the floor. Lead with the first two. Public shape of the return: +30% receiving/inventory efficiency (McDonald's China/Cainiao), 100% encode success at source (Golden State Foods).
- The trap: funding buckets 1–3 and skipping bucket 4. You end up with an inventory count and no answer.
If you have a rollout already in flight — tags going on corrugate, handhelds landing reads with nowhere durable to keep them — the conversation worth having is about the record layer under it, not another reader bake-off.
→ Put me on the seat list — your capture workspace is provisioned from the list, in order; one email when your seat is ready. Choose "Distributor" — the receive-hold-ship-on side of the handoff, the dock where your scan already lands.
This is the economic-buyer companion to the pillar, where the reads land and why the record is the asset.
<!-- ═══════════════════════════════════════════════════════════════════════════ ARTICLE P2-b TARGET SLUG: