Asset Physical Verification — A Practical Guide for Finance Teams
Published: April 10, 2026
Physical verification of fixed assets is a statutory requirement under the Companies Act 2013 and a practical necessity for any organisation that wants accurate financial statements. Yet in most organisations, the process remains manual — a team walks through buildings with a printed Excel list, ticking off items they can see and marking question marks next to items they cannot find. The list goes back to the accounts department, someone reconciles it against the asset register, discrepancies are noted in a memo, and the memo is filed.
The problems with this approach are well documented: it is slow, it is error-prone, it produces no audit trail, and by the time discrepancies are investigated, the verification data is already stale. This article explains how structured verification works when it is supported by a system — from QR tagging through campaign management to discrepancy resolution.
1. The Problem — Why Spreadsheet-Based Verification Fails
Manual verification typically involves printing the asset register, assigning sections of it to different staff members, and asking them to physically locate each asset. The issues compound at every step:
- No unique identifier on the asset: Without a physical tag, the verifier has to match the asset by description — "wooden desk, 4-drawer" — which is ambiguous when a floor has thirty similar desks.
- No real-time tracking: The finance team has no visibility into verification progress until the printed sheets come back, which may take days or weeks.
- No audit trail: There is no record of when the verification happened, who did it, or whether the verifier actually visited the location. A tick mark on a printout is not evidence.
- Discrepancies are lost: When the printed list comes back with handwritten notes — "not found", "moved to 3rd floor", "damaged" — these notes often fail to translate into corrective action. There is no systematic way to track resolution.
- Assets get missed entirely: Items that were purchased after the register was printed, or items that moved between locations, are invisible to the verification team.
For organisations with hundreds or thousands of assets across multiple locations, the manual approach does not scale. Year-end verification becomes a dreaded exercise that consumes weeks and produces questionable results.
2. How Structured Verification Works
A structured approach breaks the verification process into distinct, trackable phases:
- Tag the assets: Every asset gets a unique physical identifier — a QR code tag — that links it to its record in the asset register.
- Create a campaign: Define the scope (which assets, which locations, which departments), assign verifiers, and set a deadline.
- Scan and record: Verifiers use a mobile device to scan each asset's tag. The scan records the asset identity, timestamp, verifier, and location.
- Reconcile: Compare scanned assets against the campaign scope. Identify unverified assets, location mismatches, and condition discrepancies.
- Resolve discrepancies: Investigate missing assets, update locations for moved assets, raise write-off requisitions for assets that cannot be found.
Each phase produces structured data that feeds into the next. The result is a verification exercise that is auditable, repeatable, and produces actionable information rather than a stack of annotated printouts.
Assets that entered the register through a governed procurement chain — requisition, purchase order, goods receipt — already carry complete records: classification, cost, vendor, department, and location. This makes verification systematic rather than investigative. The verifier scans the tag and confirms the asset matches its record — rather than trying to identify an unlabelled item from a description.
3. QR Tagging — The Foundation of Physical Verification
Effective verification begins with the ability to uniquely identify each physical asset. QR tags serve this purpose.
3.1 Tag Generation
Tags are generated in bulk — typically through a CSV or Excel upload that maps each asset to its tag. The system assigns a deterministic tag identifier in the format TAG-{sequence}-{asset_id}, ensuring global uniqueness. A global sequence counter, locked during generation, prevents duplicate tag numbers even when multiple batches are generated simultaneously.
3.2 Tag-to-Asset Binding
Each generated tag is permanently bound to a specific asset record. The tag ID becomes an alternate identifier for the asset — alongside the asset's system ID and any legacy identifiers it may carry (old barcode numbers, manual register numbers, department-specific codes).
3.3 Scan Resolution — Three Tiers
When a tag is scanned, the system resolves the scanned value through a three-tier lookup:
| Tier | Resolution Type | What It Means |
|---|---|---|
| 1 | Canonical (P1) | The scanned value matches the system-generated tag ID exactly. This is the expected result for properly tagged assets. |
| 2 | Shadow | The scanned value matches an alternate identifier stored against the asset (e.g., an old barcode number). The asset is identified, but the tag is not the canonical one. |
| 3 | Legacy | The scanned value matches a legacy tag field. The asset is identified through historical data. This covers assets that were tagged under a previous system. |
This three-tier approach is important for organisations transitioning from an older tagging system. Assets do not need to be re-tagged immediately — the system can resolve old tags while new canonical tags are rolled out gradually.
3.4 Condition Reporting — With or Without a Scan
Condition is reported through one of two endpoints. POST /tags/scan records condition as part of a tag scan and auto-resolves the asset reference through the three-tier lookup above (P1 canonical → shadow → legacy). POST /tags/condition-report records condition directly against the asset without requiring a scan event — useful for annual custodian reviews where the asset reference is already known and a physical scan is not the workflow. Both endpoints feed the same audit log, and where a scanned value is captured a SHA-256 hash of the input is stored alongside the asset reference for tamper evidence.
4. Verification Campaigns
A verification campaign is a structured exercise with defined scope, assignments, and deadlines.
4.1 Creating a Campaign
The finance or admin team defines the campaign parameters:
- Scope: Which assets are included — by location, department, classification, or a custom selection.
- Verifiers: Who is responsible for verifying which assets. Assignments can be by location (Floor 2 assigned to Person A), by department, or by individual asset list.
- Timeline: Start date and deadline for completion.
- Type: Full verification (all assets in scope) or sample verification (a random or targeted subset).
4.2 Tracking Progress
As verifiers scan assets, the campaign dashboard updates in real time — showing the percentage verified, unverified count, and any discrepancies flagged. The finance team can identify bottlenecks (a verifier who has not started, a location with a high unverified count) and intervene before the deadline passes.
4.3 Flagging Discrepancies
During scanning, the verifier can flag issues beyond simple presence or absence:
- Location mismatch: The asset is found, but not where the register says it should be.
- Condition change: The asset is found but is damaged, non-functional, or in a different operational state than recorded.
- Tag missing or damaged: The physical tag is absent or unreadable, requiring re-tagging.
- Duplicate found: Two physical assets appear to map to the same register entry — indicating a data quality issue.
4.4 Closing the Campaign
When the deadline arrives or all assets are accounted for, the campaign is closed. The system generates a verification summary — assets verified, assets missing, discrepancies by category — that serves as documentation for auditors and management.
5. Operational Status Tracking
Verification is not just about confirming that an asset exists. It is also about confirming its operational status. Each asset carries a status that reflects its current condition:
| Status | Meaning |
|---|---|
| Active / In-Use | The asset is deployed and operational. |
| Idle | The asset exists and is functional but is not currently deployed. It may be in storage or awaiting assignment. |
| Under Repair | The asset has been sent for maintenance or repair. It is expected to return to active status. |
| Missing | The asset could not be located during verification. Investigation is required. |
| Retired / Written Off | The asset has been formally removed from active use through a write-off or disposal requisition. |
During verification, the verifier confirms or updates the operational status. This creates a point-in-time record of each asset's condition — data that feeds into insurance valuations, depreciation reviews, and capital planning.
6. Audit Trail — Every Scan Is Logged
Every scan event creates an immutable audit record containing:
- Scanned value: What the scanner read (the raw QR content), hashed with SHA-256 for tamper detection.
- Resolved identity: Which asset the scan resolved to, and through which resolution tier (canonical, shadow, or legacy).
- Verifier: The authenticated user who performed the scan.
- Timestamp: When the scan occurred, recorded to the second.
- Governance signal: A classification of the scan event — SCAN_CANONICAL (expected), SCAN_SHADOW_TAG (alternate identifier used), SCAN_LEGACY_TAG (old system tag used).
This audit trail is not editable. Scan records cannot be modified or deleted after creation. For statutory auditors reviewing the physical verification process, this provides documentary evidence that each asset was physically located, when it was verified, and by whom.
The audit trail transforms physical verification from a subjective exercise ("we checked everything") into an evidence-based process. Each assertion — "this asset was at this location on this date" — is backed by a timestamped, authenticated scan record.
7. Practical Considerations
7.1 When to Run Verification
Most organisations run physical verification at year-end, driven by the statutory audit requirement. However, limiting verification to once a year means that discrepancies are discovered too late to investigate effectively. A more practical approach combines:
- Full year-end verification: Comprehensive, all-assets verification before the books close. This satisfies the statutory requirement and produces the formal verification report.
- Mid-year sample verification: A targeted check of a subset — perhaps high-value assets, recently acquired assets, or assets in locations with historically high discrepancy rates.
- Ad-hoc verification: Triggered by events — a department relocation, an insurance claim, a change of custodian, or a report of missing items.
7.2 Linking to Depreciation and Insurance
Verification data has direct implications for two financial processes:
- Depreciation: An asset that is verified as missing or non-functional may need to be impaired or written off, which changes the depreciation schedule. An asset found in a different condition than recorded may need its useful life reassessed.
- Insurance: Insurance coverage should reflect the current state and location of assets. Verification data provides the evidence base for updating insurance declarations — confirming which assets exist, where they are, and their approximate condition.
7.3 Transitioning from Manual Processes
For organisations currently using Excel-based verification, the transition to a structured system does not need to happen all at once. A practical path is:
- Import the current asset register into the system.
- Generate and apply QR tags in phases — starting with high-value assets or a single location.
- Run the first campaign as a pilot — one department or one building.
- Expand to full-organisation coverage in subsequent cycles.
The first cycle will inevitably surface data quality issues — assets in the register that do not exist physically, physical assets that are not in the register, location data that is outdated. This is expected. The value of the structured approach is that these issues are surfaced systematically rather than discovered accidentally.
8. Frequently Asked Questions
What is physical asset verification?
Physical asset verification is the process of inspecting each asset listed in the fixed asset register at its actual physical location to confirm the asset exists, is in working condition, and is in the possession of the assigned custodian. Under CARO 2020 Clause 3(i)(b), the statutory auditor must comment on whether the company conducted physical asset verification at reasonable intervals and whether discrepancies were properly dealt with in the books of account. Most organisations run quarterly or annual verification campaigns using QR scanning on a smartphone to create dated, tamper-evident evidence. Without physical asset verification, the fixed asset register is just a ledger entry with no connection to physical reality — a common root cause of qualified audit opinions and CARO 2020 findings.
How is fixed asset physical verification conducted?
Fixed asset physical verification is typically conducted as a scoped campaign: the administrator identifies the asset population to verify (by classification, location, department, or custodian), assigns verifiers, gives each verifier a scoped list of assets with their expected locations, and the verifier physically visits each asset and scans its QR tag using a smartphone browser. Each scan records the asset's canonical identity, GPS coordinates (if enabled), timestamp, verifier ID, and operational condition. Assets that are not scanned by the campaign close date are automatically flagged as discrepancies for follow-up investigation. Structured fixed asset physical verification — where every scan is logged immutably and every discrepancy is investigated — is what auditors look for when they test CARO 2020 Clause 3(i)(b) compliance.
What does CARO 2020 require for asset physical verification?
CARO 2020 Clause 3(i)(b) requires the statutory auditor to comment on three things about asset physical verification: (1) whether the company has physically verified its property, plant and equipment at reasonable intervals; (2) whether any material discrepancies were identified during verification; and (3) whether any identified discrepancies were properly dealt with in the books of account. The term "reasonable intervals" is not defined in the Companies Act — the board-approved verification policy must state the frequency (typically annual for high-value or mobile assets, and a rotational three-year cycle for lower-value fixed-location assets). Missing the verification entirely, or doing it without documented evidence of what was checked and by whom, typically results in a qualified audit opinion under CARO Clause 3(i)(b). For the full compliance framing, see the CARO + IFC guide.
How is QR tagging different from barcode tagging?
Traditional barcodes store a single string — typically an asset number — and require a dedicated barcode scanner. QR codes store richer data, can encode the asset's canonical tag identifier, and are scannable using any smartphone camera or a lightweight PWA. QR codes also survive partial damage better than barcodes. From a governance perspective, the key difference is that a QR-based system can link to a structured tag identity with three resolution tiers — canonical, shadow, and legacy — which means even assets with old barcode labels can be resolved through the same scan workflow.
Can verification be done with a phone?
Yes. A Progressive Web App (PWA) runs in the phone's browser — no app store installation required. The verifier opens the PWA, authenticates, and scans QR tags using the phone's camera. Each scan records the asset identity, timestamp, and the verifier's user ID. The scanned data syncs to the central system when the device is online. This approach eliminates the need for dedicated scanning hardware.
What happens when an asset is not found during verification?
Assets assigned to a verification campaign that are not scanned by the campaign close date are flagged as unverified. The system distinguishes between "not scanned" (verifier did not attempt) and "not found" (verifier explicitly marked the asset as missing). Missing assets are flagged with a discrepancy status and can trigger follow-up actions — a re-verification assignment, an investigation, or ultimately a write-off requisition if the asset cannot be located.
How does verification link to the fixed asset register?
Each scan resolves to a specific asset record in the fixed asset register. When a canonical tag is scanned, the system matches it to the asset's tag identifier and updates the asset's last-verified date and operational status. This creates a direct link between the physical verification event and the financial record. Discrepancies — missing assets, location mismatches, condition changes — are recorded against the asset register entry, which means the finance team can see verification status alongside book value, depreciation, and insurance coverage. For a lighter-weight alternative between annual verification cycles, see custodian self-declaration.
Is there an audit trail for each scan?
Yes. Every scan event is logged with the scanned value, the resolved asset identity, the verifier's user ID, the timestamp, and a governance signal indicating the resolution tier (canonical match, shadow tag match, or legacy tag match). The scanned value is hashed for tamper detection. This audit trail is immutable — scan records cannot be edited or deleted after creation. Auditors can review the full scan history for any asset or any verification campaign.