Continuous asset verification is the practice of confirming that a capitalized asset exists, sits where the record says, and remains in working condition, as an ongoing function rather than a once-a-year project. It produces the physical input that a fixed asset subledger depends on and cannot generate for itself.
Every company with a material fixed asset base already runs asset verification. It runs once a year, as a project, with a start date and a team pulled off other work. That is the job. The open question is how often it runs.
The cost of running it annually is measurable. Kroll Advisory, which runs more than 8,000 fixed asset engagements a year across 36 countries, reports that 10 to 30 percent of assets on the average fixed asset register are ghost assets, and that up to 65 percent of asset records contain errors, missing data, or outdated information. Those records were accurate on the day of the last count.
For CFOs, controllers, fixed asset managers, and internal audit teams, the useful question is not whether the register drifts. It is whether verification stays a project that decays for eleven months, or becomes a function running against work the business already does.
Continuous asset verification is a standing function that confirms physical existence, location, and condition against the fixed asset record, delivering evidence rather than a count total.
The function exists because two systems describe the same equipment and only one of them can see it. The fixed asset subledger is the financial system of record. It tracks acquisition cost, depreciation method, useful life, and net book value, and feeds those figures to the balance sheet. Within that scope it is excellent.
It does one thing by design that is easy to miss. It records what it is told. The subledger will accept a correction originating on the floor. It will not go and find one. That is correct architecture, and it is why verification is a separate job rather than a feature request.
The vendors document this themselves, and their wording is worth reading closely. Oracle Assets includes a Physical Inventory feature, and Oracle states that to use it you must first take physical inventory of your assets, describing that as a process in which a company takes inventory by manually looking at all assets to ensure they exist as recorded, are in the appropriate locations, and consist of the recorded number of units. SAP documents a physical inventory that the director of the organization orders, carried out by a commission that posts any differences into Asset Accounting afterwards. Microsoft says that to verify recorded assets exist and sit in the correct location, you should reconcile physical inventory, with the verification data entered or imported.
Every major platform therefore has a reconciliation path. What none supplies is the field evidence that path consumes. SAP's ABAVN and ABAON retirement transactions also operate on whole assets, so component-level retirement still needs a manual journal entry.
Consider a $180,000 stamping press. In year four the drive motor fails and maintenance replaces it for $40,000. The work order closes cleanly. No journal entry reaches the subledger, so the original motor keeps depreciating as part of the press for another six years, and the new motor never enters the register. Both records are internally consistent. Neither describes the machine on the floor.
The register drifts for structural reasons rather than careless ones. Four causes account for most of it.
|
|
Annual physical count |
Continuous verification |
|
Frequency of input |
Once per year |
Ongoing, tied to field activity |
|
Currency of the record |
Accurate on count day, aging thereafter |
Reflects the most recent verified field event |
|
Evidence retained per asset |
A count result |
Condition, location, and documentation per event |
|
Audit support |
Point in time, reconstructed after the fact |
Continuous trail, available on request |
|
Effort profile |
Concentrated into a short annual window |
Distributed across work already happening |
Neither column is wrong. The annual count was the only practical mechanism for most of the time fixed asset accounting has existed, and it still produces a clean attestation on the day it runs. The question is what the record is worth on the other 364 days. None of these causes is carelessness. They are what happens when continuous change is checked on a discontinuous schedule.
The return on a verified register does not land in one place. The same input feeds several records usually maintained separately.
"Ghost assets aren't the problem. The annual audit cycle is. Ghost assets are just what happens when you only look once a year."
Tim Harris, CEO, SoloTruth
Only the first two of those categories have defensible published figures attached. Property tax and insurance overpayment are real and widely acknowledged, and no reliable public benchmark exists for either. Any number offered for them should be built from a company's own register rather than borrowed from someone else's.
The return scales with how much of the balance sheet sits in physical assets and how often those assets move.
A verification layer earns its place by feeding systems a company already runs. Look for six capabilities.
Six practices separate a verification programme that holds from one that decays after the first quarter.
Four assumptions come up consistently in conversations with finance and audit teams.
Reality: the subledger is accurate about every transaction it was given. Accuracy about the physical estate depends on whether physical changes were reported into it, and the platforms do not connect maintenance and logistics activity to the financial asset record automatically.
Reality: the practical designs attach verification to movement that already occurs. A driver, technician, or supervisor already passes the equipment. Capturing evidence at that moment costs seconds rather than a headcount line.
Reality: this is the most substantive objection to continuous verification and it deserves a direct answer. An unresolved discrepancy carries risk whether or not it is written down. What a governed record changes is that the discrepancy has an owner, a date, and a resolution path. Where fixed asset existence and disposition are material to the statements, an undocumented verification process makes management's internal control assertion under SOX 404 harder to support (17 CFR 240.13a-15(f)). Exception aging is a control problem with a known solution. Not knowing is not.
Reality: a verification layer sits above the ERP and writes into it. The system of record does not change. What changes is the quality and frequency of what reaches it.
A standing function confirming an asset exists, sits where the record says, and works, delivering evidence rather than a count total. It supplies the physical input a subledger depends on and cannot produce itself.
Most companies run it as an annual project. As a function it happens continuously, tied to work already occurring in the facility, so the record never drifts far from reality.
Physical changes happen continuously and reach the register only when somebody reports them through a separate process. Between counts, moves, disposals, and component replacements accumulate with no corresponding accounting entry.
No universal requirement exists. Accuracy is a function of the interval, so verification tied to ongoing field activity produces a more current record than any fixed annual or quarterly cycle.
Tracking answers where an asset was last seen. Verification establishes that it exists, what condition it is in, and produces evidence a third party can review. Financial reporting depends on the second.
It changes what the count does. Rather than discovering discrepancies, it confirms a register continuous evidence has already kept close. Most organizations keep the count and find it cheaper to run.
ARM is the software category that verifies the existence, location, and condition of physical assets and reconciles that data with ERP and compliance systems, replacing episodic audits with continuous evidence.
Through a governed workflow. Field evidence is captured, discrepancies flagged, a person with authority approves the correction, and the change posts to the subledger with its evidence attached.
Asset verification is not a new function anyone needs to justify. It is already funded, already staffed for a few weeks a year, and already producing an input everything downstream depends on. The decision is not whether to do the job. It is whether it runs once as a project, or continuously as a function riding on movement already happening in the building.
This is the function SoloTruth Asset Relationship Management (ARM) was built to run. ARM verifies the existence, location, and condition of physical assets using inspections, location signals, and document intelligence, then reconciles that verified data into the ERP through a human-in-the-loop control layer. The system of record does not change. What changes is how often it hears the truth. Our model typically shows payback in under six months.
Book a 30-minute strategy call at calendly.com/tim-harris-solotruth/30min to talk through what running verification as a function would look like against your own asset base.
Last Updated: August 2026