Reconciling a CMDB against physical inventory means comparing its records with a hands-on count of every device, including spares, powered-down systems, and anything in a crate. Automated discovery finds only equipment that is powered on and reachable over the network, so a CMDB built from discovery alone misses many of the assets that matter.
The equipment that is invisible is disproportionately the equipment that matters. Spares on a shelf. Systems powered down pending decommissioning. Air-gapped hosts. Devices on an isolated management network the scanner cannot reach. Anything in a crate. A CMDB built entirely from discovery describes the operating estate, not the asset estate, and the gap between the two is where losses live.
What Discrepancies Does Reconciliation Find?
Reconciliation compares a record set against a physical count, and the discrepancies fall into two categories that need different responses.
Ghost records are entries in the CMDB with no corresponding physical device. They accumulate from decommissioned equipment that was never retired in the system, from duplicate discovery of the same host under two identifiers, and from planned purchases entered before they arrived and then cancelled. Ghosts inflate the apparent estate, and they inflate the support and license spend calculated from it.
Unrecorded assets are physical devices with no CMDB entry. They come from equipment deployed outside the procurement process, from acquisitions whose estates were never fully absorbed, from lab and test hardware that was never meant to be permanent, and from anything received during a period when the receiving process was not followed. Unrecorded assets are the more serious finding, because an asset nobody knows about is an asset nobody is patching, and a data-bearing device nobody knows about cannot be sanitized to NIST SP 800-88 at end of life.
A third category sits between them: records that exist and are wrong. The device is real, the entry is real, and the location, owner, or configuration no longer describes it. These are the hardest to find, because nothing about the count reveals them.
Why Is a Physical Count Necessary?
The only way to find unrecorded assets is to look at the equipment. Discovery cannot find what it cannot reach, and a reconciliation run entirely between two databases is comparing one set of assumptions against another.
A physical count means walking the floor, scanning tags, and recording what is actually present — including what is in storage rooms, on spares shelves, in staging areas, and in offices. It is tedious and it is the part that produces the findings.
Scanning against properly specified asset tags makes this fast. Without tags it becomes serial-number transcription, which is slow and error-prone and is one of the strongest arguments for a tagging program in the first place.
Count by location and close each location out before moving on. A count that wanders produces a list of devices without a reliable statement of where they were found, and location is half the value of the exercise.
Capture what is not in the record as you go, rather than reconciling afterward. The person standing in front of an untagged device is the person best positioned to answer what it is.
Why Is a Relocation the Best Time to Reconcile?
Every piece of equipment gets handled, moved, and accounted for during a relocation. That is a complete physical inventory happening for other reasons, and it is far cheaper to attach a reconciliation to it than to run one separately.
The inventory built for the move is the count. Reconciling it against the CMDB before the equipment leaves produces a clean baseline, and it does so at the one moment when someone can walk over and look at the device in question.
It also surfaces the equipment nobody claims. Every migration finds systems that are powered on, have no documented owner, and cannot be confidently switched off. Discovering these during planning leaves time to trace them. Discovering them on move night means they get moved, because nobody will take the risk of leaving them behind, and the estate carries them for another decade.
How Do You Keep the CMDB Accurate Afterward?
Fix how assets enter and leave the estate, not just the data. A reconciliation that corrects records without changing how assets enter and leave the estate will need to be repeated in eighteen months with the same findings.
Assets should be recorded at receipt, before deployment, which is the starting point of the CIS asset inventory control and of NIST's IT asset management guide (SP 1800-5). Decommissioning should require a CMDB status change as a completion step, ideally tied to the disposal certificate so that retirement in the record and physical disposal cannot diverge. The tail of that process connects directly to end-of-life disposal, where an accurate record is what makes a certificate of destruction meaningful.
Ownership per record is what keeps data current between reconciliations. A record owned by a team is a record owned by nobody, and it will be as stale next year as it is today.
Reconcile on a cycle rather than on an incident. Annual full counts are common; quarterly sampling of high-value and data-bearing assets catches drift earlier at a fraction of the effort.
Measure the Gap, Not the Effort
The useful metric is the size of the discrepancy between record and reality, tracked over time.
Count ghost records and unrecorded assets separately, because they indicate different process failures — ghosts point at retirement, unrecorded assets point at receiving. Track them as a percentage of the total estate so the numbers stay comparable as the estate changes.
Then track whether they close. A reconciliation that produces four hundred findings and a follow-up that produces the same four hundred means the exercise is generating data nobody is acting on, which is a more expensive condition than not having run it at all.