Introduction
RFID fixed asset tracking gives Finance and Audit a fast, timestamped record of which tags were read, where and when the reads occurred, and who performed them. However, a read provides evidence, not a decision. Each exception still requires a recheck, a reviewer’s written rationale, an approved register action, and confirmation of the downstream update before the team can close it.
For teams new to the technology, RFID-based tracking explains how an identity travels with the asset on a tag, how radio confirms it without handling or scanning, and what each observation actually proves and where its limits are.
This guide is for finance controllers, fixed-asset accountants, and auditors who receive RFID results rather than run the readers. The focus here is narrower: turning read exceptions into reviewed, approved, and traceable register actions.
In this guide, you will learn:
- How to scope RFID fixed asset tracking by fixing the register extract, unit mapping, locations, sweep plan, roles, and changes before verification.
- What an RFID read proves, why unread tags remain exceptions, and how rechecks distinguish genuine asset issues from tag, coverage, or data problems.
- How to manage an exception dossier through rechecks, reviewer rationale, approvals, downstream updates, and confirmed closure using an RFID fixed asset tracking system.
- How to reuse RFID evidence by carrying open exceptions, recurring no-reads, reviewer decisions, and verification records into the next audit cycle.
How do you set the scope for RFID fixed asset tracking in an audit?
Scope RFID fixed asset tracking for an audit by fixing three baselines before the first read. They define the register extract used for comparison, the physical units represented by each register line, and the locations covered by the sweeps. Without that baseline, nobody can tell later whether an exception came from the asset, the tag, or a register that changed during the count.
Take a dated extract of the fixed asset register for the entity and period, and keep it unchanged for the count. List additions, transfers, and disposals posted during the count separately so you can match them against reads instead of editing the baseline. Record who produced the extract and the population it covers.
Units matter as much as lines. One register line can represent many physical items, such as a project capitalised as a single asset, and one item can carry more than one tag. Before the count, link each tagged unit to its FAR line so that every read resolves to one unit and one line. Items outside RFID scope need a stated alternative method.
Scope record to fix before the first read
| Item | What to record | Why it matters |
|---|---|---|
| Register extract | Entity, period, extract date, who produced it, asset count | Gives every exception a fixed comparison point |
| Unit mapping | Tag IDs per register line; lines with several units; untagged items; tags of lines retired or disposed in the period | Stops a read being counted against the wrong line |
| Location list | Sites, buildings, rooms or zones in the register’s own terms | Lets a read location be compared with the recorded one |
| Sweep plan | Zones, reader or device, and the method for items that cannot be tagged | Shows coverage, so an unread tag can be judged |
| Roles | Who reads, rechecks, reviews, approves and posts | Keeps custody, recording and approval apart |
| Changes during the count | Postings made after the extract date | Separates timing differences from real exceptions |
Roles need the same care as data. Separate asset custody, exception approval, and record updates so one person does not control the entire process.
For RFID results, the person responsible for an asset should not approve an exception involving that asset. Where possible, the person approving the change should also be separate from the person who records it.
In AssetCues RFID asset tracking, a handheld sweep compares reads with the expected list for a location and flags missing, surplus, and moved assets. That tally is where the exception work below begins, not where it ends.
What does an RFID read prove, and what does it not?
An RFID read proves that a tag identifier was within range of a reader, as recorded at a location, at a recorded time. Software then infers the asset from the link between tag and record. A read does not prove that the tag remains attached to the asset, that the asset is in use or in good condition, or who owns it.
Understanding how RFID tags for asset tracking are matched to the asset surface, mounted, and tested against real assets before rollout helps explain why some tags go unread and what that actually means.
The most important consequence is that an unread tag is an exception, not proof that the asset is missing. A tag may go unread because it is damaged, shielded by metal, outside the sweep path, or attached to an asset that moved without a recorded transfer. However, only some of these causes mean the asset is missing. Treat “not read” as an exception that requires a recheck to determine the cause.
The same caution applies to ghost assets, the items still recorded in the register that no longer physically exist. RFID identifies candidates quickly because it lists every tagged line that remains unread after a complete sweep. It cannot confirm that an asset is a ghost. Only investigation can do that.
RFID observations and what each can support
Observation | What it supports | What it cannot show | First check |
|---|---|---|---|
| Read at the recorded location | The tag was within range of the reader in that zone at that time | That the tag is on the right asset; condition | Visual check on a sample of high-value reads |
| Read at another location | The tag was somewhere else | Whether the move was approved | Transfer request or custodian confirmation |
| Not read at the recorded location | Nothing was detected on this sweep | That the asset is missing | Targeted recheck with a different method |
| Read, but not in the register extract | A tag in scope has no matching line | Whether it is an asset, an expense item or another entity’s property | Tag history and purchase record |
| Read, but recorded as retired | The tag is still on site | Whether the disposal happened | Disposal record and inspection |
| One tag on two records, or two tags on one asset | A data conflict exists | Which record is correct | Asset master review |
Was the sweep complete enough to call a tag unread?
A tag can only be called unread if the sweep could have read it. Before an unread tag becomes an exception, confirm three things from the sweep log:
- The zone was swept: It appears in the log against the planned device and operator.
- The device was working there: A reference tag fixed in the zone, or other tagged assets nearby, were read on the same pass.
- The method suited the asset: Items in metal cabinets, racks or sealed rooms had the search the sweep plan specified.
If any of the three fails, the right action is to sweep the zone again, not to raise a not-read exception. That keeps the dossier for genuine questions about assets rather than gaps in coverage.
Read-zone problems belong before the audit, not inside it. Coverage, stray reads, and missed tags are covered in the RFID asset tracking implementation guide. An audit should rely only on zones and methods that have passed those tests.
Worked example: An exception-to-FAR dossier
An exception-to-FAR dossier is one record per exception that holds the raw observation, the recheck, the reviewer’s rationale, the approved action, and the downstream status. An auditor can follow any register change back to the read that started it, and Finance can see which exceptions are still open and why.
Build each entry in the same order, so that no state can be skipped:
- Copy the raw observation from the sweep unchanged: tag ID, register line, expected and observed location, time, device, and operator.
- Recheck with a different method or person, and record both the method and the result.
- Ask the reviewer to state the evidence considered, the conclusion, and the policy relied on.
- Record the proposed action, and obtain approval from someone other than the reviewer who has no custody of the asset.
- Send the update downstream, or record why none is needed.
- Attach the posting reference or acknowledgement and close the entry; otherwise leave it open with an owner and a review date.
The five cases below are illustrative. They are not customer data or results; they show the level of detail each entry should hold. Days are counted from the sweep, and the assets were chosen to cover the main exception types.
Raw observations from the sweep on day 1
| Case | Register says | Sweep observed | Exception raised |
|---|---|---|---|
| A. Projector | Head office, room 4.2 | Not read in room 4.2 | Not read |
| B. Portable generator | Plant A, yard | Read at Plant B, workshop | Read at another location |
| C. Network switch | No matching line | Tag read in Plant A server room; tag ID not in the extract | Unmatched tag |
| D. Forklift | Disposed, posted before the extract | Read at Plant A, yard | Read, but recorded as retired |
| E. Laboratory analyser | Plant A, lab 2 | Not read in lab 2 | Not read |
Recheck and reviewer evidence
Each recheck used a different method from the sweep, and each reviewer wrote down the evidence considered and the reason for the conclusion. Where a geotagged photo was used, it shows where the phone was when the photo was taken. It supports the observation, but it does not track the asset.
| Case | Recheck | Result | Reviewer and rationale |
|---|---|---|---|
| A | Day 2: second operator, targeted handheld search, visual check | Found inside a steel cabinet in room 4.2; tag read only with the door open | Facilities lead: asset present; metal shielding caused the exception; no register change |
| B | Day 2: second operator’s read at the Plant B workshop, plus custodian statement | Moved to Plant B for a project; no transfer request raised | Plant A controller: move confirmed; transfer to be approved after the fact under the entity’s policy |
| C | Day 3: tag history and purchase records | Tagged during a network project; one of eight units capitalised as a single project line | Fixed-asset accountant: unit belongs to an existing line; no new asset |
| D | Day 2: disposal file, sale agreement and site inspection | Sale completed; buyer collection delayed; forklift still on site | Fixed-asset accountant: control passed to the buyer on the sale date, so the disposal posting stands; forklift held for the buyer; removal pending |
| E | Days 2 and 5: two operators, barcode fallback, room search | Not found; custodian has left; no transfer or disposal record | Fixed-asset accountant: evidence does not support a conclusion; investigation proposed |
Approved mapping or correction and downstream status
The approved action is the decision; the downstream status shows whether that decision reached every system holding the record. Treat acknowledgements, retries and rejected updates as requirements to confirm with your own integration, not as behaviour to assume.
Approved action and downstream status
| Case | Approved action and approver | Downstream update | State |
|---|---|---|---|
| A | No register change; sweep plan amended so the cabinet is opened on future sweeps (fixed-asset accountant) | Not required; sweep plan updated on day 2 | Closed |
| B | Location changed to Plant B (finance controller) | Sent to the ERP on day 4; posting reference received on day 5 | Closed |
| C | Unit mapped to the existing project line (fixed-asset accountant’s manager) | Mapping updated in the tracking system; no ERP posting needed | Closed |
| D | No register change; disposal owner to confirm collection (finance controller) | Waiting for collection evidence | On hold: physical removal pending |
| E | Register unchanged while the investigation runs (finance controller) | None until the investigation concludes | On hold: under investigation, review on day 30 |
Case A was a genuine exception: the sweep plan did not list the cabinet, so the coverage check passed, and the fix went into the plan.
Case D shows why approval and closure are separate. The register is right about the disposal, but the physical position is not, so the case stays open; had control not passed, the disposal posting itself would be the error.
Case E is the unresolved case every real dossier contains. The evidence supports neither a write-off nor a correction yet, so the register is left alone and the item is reported with its age and owner.
Who decides recognition, write-off or retirement?
Finance decides, under the applicable accounting framework and the entity’s own policy. RFID evidence informs that decision but never makes it. IAS 16 recognises an item when future economic benefits are probable, and its cost can be measured reliably. It derecognises an item on disposal or when no future economic benefits are expected. Neither test is a rigid result.
IAS 16 does not apply to every entity. Different markets may follow other accounting frameworks, while local policies set their own thresholds, approvals, and record-keeping requirements. Have a qualified Finance reviewer assess any recognition, retirement, or impairment decision, and record the framework and policy used.
An open exception does not postpone the accounting judgement. If a reporting date falls while an item like case E is under investigation, Finance still decides for that period whether the evidence supports keeping it in the register. That decision is recorded in the dossier too.
Two shortcuts are especially risky. One is adding an asset automatically because an unknown tag was read; case C would then have duplicated a unit already capitalised. The other is retiring an asset automatically because it was not read; case A would have removed a projector that was in the room. Neither should happen solely because a count differs.
What verification evidence can inform, and what Finance decides
| Question | Verification evidence can inform | Finance decides |
|---|---|---|
| Does the asset exist? | Read history, recheck method and result, photo | Whether existence is established for the period |
| Should an unmatched item be recorded? | Tag history, location, first read | Whether it is a new asset, part of an existing line, an expense item or someone else’s property |
| Should an unread asset be written off? | Number and method of rechecks, last read, custodian response | Whether to write off, keep investigating or report the item as unresolved |
| Is the asset impaired? | Condition notes and photos taken at the recheck | Whether an impairment review is needed, and its outcome |
| Is a disposal complete? | Reads after the disposal date | Whether the disposal record or the physical position needs correcting |
When is an RFID exception closed?
Close an RFID exception only after the approved action reaches every system that holds the record, and you confirm the update. Completing the count, rechecking the item, and approving the action are earlier states. Reporting them as resolved hides open work and lets the same exception reappear at the next verification.
Exception states from read to closure
| State | Entered when | Evidence needed to move on | Owner |
|---|---|---|---|
| Raised | The sweep records an exception | A recheck completed with a different method | Verification lead |
| Rechecked | The recheck has a result | Reviewer rationale and a proposed action | Reviewer |
| Reviewed | A proposed action is recorded | Approval by someone without custody of the asset | Approver |
| Approved | The action is approved | Update sent; or, for an action that changes nothing, recorded as not required | Register owner |
| On hold | The approved action is to hold or investigate; the register is unchanged | An investigation conclusion and a new proposed action (returns to Reviewed) | Investigation owner, with a review date |
| Sent | The update has gone downstream | Acknowledgement and a posting reference | Register owner and integration owner |
| Rejected | The receiving system rejects the update | A corrected update re-sent (returns to Sent) | Register owner and integration owner |
| Closed | The update is confirmed, or none was needed | Kept as history for the next verification | Register owner |
What should the control owner see before sign-off?
A sweep can be complete while many of its exceptions are still open, and a single progress figure hides that difference from the people who sign off the register. Report these instead:
- Open exceptions by state and owner, with the age of each.
- Items past their review date, and who has been asked to act.
- Approved register changes closed without a posting reference; the expected number is none.
- Approvals given by the asset’s custodian or by the person who posted the change; again, none.
- Rejected downstream updates and the owner now responsible for each.
- Count completion and exception resolution, shown as two separate figures.
How do you reuse RFID evidence at the next verification?
Reuse RFID evidence by carrying open exceptions, recurring no-reads, and reviewer decisions into the next scope. A verification that starts from a clean sheet repeats investigation work and loses the history an auditor will ask about. The dossier is the bridge between one count and the next.
Start with the open items. Cases D and E belong in the next scope by name, with their last state, owner, and age. Then look for patterns. A location where tags repeatedly go unread usually points to tag type, placement, or sweep method, not to repeated losses, and the fix belongs in the next sweep plan.
The evidence pack for each verification should let a reader rebuild the result without asking anyone. Keep these items together:
- Scope record: The register extract, unit mapping, sweep plan, and assigned roles.
- Raw sweep exports: Kept read-only as exported, with reads, not-reads, and unmatched tags by location; the dossier refers to them rather than replacing them.
- Exception dossier: One entry per exception, from observation to downstream status.
- Decisions: Reviewer rationales and approvals, each with a name and date.
- Open items and sign-off: Every exception not yet closed, with its state, age, and owner, and the control owner’s sign-off stating what remains open.
There is no universal frequency for RFID verification. Set it based on your policy, asset risk, materiality, and audit requirements. Different asset classes may also need different verification cycles. Use the completed dossier to review results, identify corrective actions, and improve the verification process.
Best practices for Finance-led RFID verification
- Agree the evidence pack with the auditor before the count, so nothing has to be reconstructed afterwards.
- Fix the recheck method for each exception type in advance, so rechecks are not improvised under time pressure.
- Sample the found results too: a visual check on some high-value reads confirms the tag is still on the right asset.
- Set a review date for every open exception instead of a single closure deadline that forces weak conclusions.
- Keep a version reference for the register extract in the evidence pack, so the baseline cannot drift.
- Retire replaced tags with a reason so earlier reads still trace to the same asset.
Key Takeaways
- A read shows a tag was detected; it does not decide existence, recognition, or retirement.
- An unread tag is an exception to recheck with a different method, not proof of loss.
- Each exception needs a recheck, a written rationale, an approval at the right level, and a downstream status.
- Approval is not closure; close only when the update is confirmed or recorded as not required.
- Carry open items, recurring no-reads, and decisions into the next verification.
Conclusion: Treat every read as evidence for a decision
RFID fixed asset tracking changes the speed of a count more than the nature of the decisions that follow it. Reads arrive faster and with better timestamps, but Finance still has to recheck, judge, approve, and confirm. A dossier for every exception, with closure tied to the downstream update, is what turns a fast sweep into evidence an auditor can rely on.
Frequently asked questions about RFID fixed asset tracking
Q1: Should every fixed asset have an RFID tag?
Ans: No. RFID suits high-value, mobile, hard-to-reach, or frequently verified assets, where reading without line of sight saves time. Low-value or easy-to-reach assets often work better with barcode or QR labels, or with custody controls alone. A mixed approach still produces one dossier because the exception method remains the same, regardless of how the asset is identified.
Q2: Does RFID verification need an ERP integration?
Ans: No. The register owner can export approved changes and post them, provided they record the posting reference against each exception. An integration reduces rekeying but adds its own failure points, and each needs an owner. A manual posting is acceptable evidence when the reference ties it to the approved action.
CA Falgun Shah
