Case study

Fixed-asset audits across 3 sites — Zebra RFD40 + .NET backend

A company auditing fixed assets across three sites replaced a clipboard-and-barcode process with a Zebra RFD40 Bluetooth sled paired to a TC21, feeding an ASP.NET Core API that reconciles reads against the asset register.

A company with fixed assets spread across three sites — IT equipment, furniture, machinery, each tagged with an RFID label at acquisition — ran annual asset audits with a barcode scanner and a printed asset register, checking items off by hand and flagging anything present-but-unlisted or listed-but-missing at the end. It worked, in the sense that it eventually produced a report, but it took a team of two roughly a week per site and the reconciliation itself — cross-referencing what was scanned against three years of register updates — was done in Excel after the fact.

The brief was to keep the register in SQL Server where it already lived, add RFID bulk-read capability using hardware the client was already evaluating, and move the reconciliation logic out of Excel and into something that ran automatically as reads came in.

The problem

The client had already purchased a Zebra RFD40 Bluetooth sled paired with TC21 handhelds for the barcode side of their operation, so the hardware decision was made before the project started — the job was making the RFD40's UHF RFID capability usable from the TC21's Android app and getting bulk reads into a reconciliation pipeline, not selecting hardware.

The harder problem was reconciliation logic that had lived in a person's head and an Excel workbook: "unlisted" wasn't just "scanned but not in the register" — it also had to distinguish an asset that had been formally disposed of but not yet deleted from the register (expected to be absent) from one that was simply missing (a real audit finding). That distinction existed only as tribal knowledge among the two people who'd always done the audit.

Hardware used

Architecture

The TC21 app pairs with the RFD40 over Bluetooth using Zebra's SDK and streams bulk reads as an inspector walks a site. Reads are batched locally and POSTed to an ASP.NET Core API in chunks rather than tag-by-tag, both to reduce network chatter on sites with patchy wifi and because the reconciliation logic is genuinely a batch operation — it needs the full site's read set to compare against the register meaningfully.

Copy[TC21 + RFD40 sled] --BT pairing, bulk read-->
        |
        v
 [Local batch buffer, per-site session]
        |
        | HTTPS POST, chunked
        v
 [ASP.NET Core reconciliation API]
        |
        v
 [SQL Server: asset register]
        |
        +--> Present + listed        -> OK
        +--> Present + not listed    -> flag: unlisted
        +--> Listed + not present    -> check disposal_status
                                          disposed -> expected absent
                                          active   -> flag: missing

The reconciliation step runs server-side against the existing register schema (no schema changes were made — the client didn't want to touch a system with three years of history for this project). The key addition was reading a disposal_status field that already existed in the register but had never been used in the audit workflow, and using it to separate "expected absent" from "missing" automatically instead of a human eyeballing the difference from memory.

What was tricky

Bluetooth pairing reliability between the sled and the handheld was the unglamorous problem that ate the most time. In a single site with only a few sleds, an occasional dropped connection is an annoyance. Across three sites with more units in rotation and inspectors handing devices to each other between shifts, stale pairing state became a recurring support call — a sled paired to one TC21 wouldn't cleanly hand off to a different unit without a manual unpair step that inspectors didn't reliably do. The fix was having the app actively detect a stale connection on launch (rather than trusting the OS Bluetooth state) and force a clean re-pair automatically, instead of surfacing an error and asking the inspector to fix it.

The disposal-status reconciliation was conceptually simple once specified, but getting that specification right took several rounds with the client's ops team, because the "obvious" rule — disposed assets should just be deleted from the register — turned out to be wrong for their finance reporting requirements, which needed disposed assets retained with a status flag rather than removed.

Result

A site audit that took a two-person team roughly a week now takes about a day and a half, with the reconciliation report generated automatically rather than built in Excel after the fact. Across the first full audit cycle at all three sites, the disposal-status distinction eliminated what had been, in the client's own estimate, the majority of false "missing asset" flags in prior years — items that were correctly disposed of but still showed up as audit exceptions under the old process.