Most companies can tell you what a customer is, or a product. Ask them what counts as an asset and you get two answers, depending on who you ask. Finance points at the fixed-asset register: anything capitalized above the cost threshold, depreciated on a schedule, sitting on the balance sheet. Maintenance points at the EAM system: anything with a work order against it, a service history, a failure mode. They are describing the same physical machines, and the two lists barely overlap.
That gap is the whole problem. Asset master data falls in the seam between finance and operations, so each side governs its own slice and nobody governs the asset itself. I have seen a plant carry equipment on its books that was scrapped two years earlier, while a pump finance wrote off in 2019 ran three shifts a day with a full maintenance file. Both records were internally consistent. Neither described what was actually on the floor.
Two systems, two definitions of an asset
Finance capitalizes by cost and groups for depreciation. A whole production line can land in the register as one asset, one row, one schedule. Maintenance breaks that same line into the units it actually services: thirty motors, pumps, and conveyors, each with its own tag and history. The ERP equipment master sits somewhere in between, modeling functional locations. Insurance groups differently again, by replacement value and peril. None of these were built to share a list, so each grew its own and each drifted.
That works fine until something has to join across them. And plenty of things have to:
Each of those needs to point at one physical asset. When the register, the EAM, the ERP, and the insurance schedule hold four codes for the same machine, that pointer has nowhere reliable to land, and every consumer either builds its own mapping or trusts one system and looks away from the rest.
Where it actually breaks
Four failures cover most of what goes wrong in this domain. Each reads like an operations or a finance mistake when it surfaces. Each was a data problem sitting in the seam for years first.
The ghost asset
A machine is scrapped in 2023. The work order to decommission it closes, the EAM marks it gone, and the steel leaves on a truck. Finance never hears about any of that, so the asset keeps depreciating on the books and keeps showing up on the insurance schedule. It surfaces two years later during a physical audit, gets written off in a lump, and the numbers get restated.
The zombie asset
A pump is fully depreciated in 2019 and drops off the finance radar. It also runs three shifts a day, has an open maintenance contract, and failed twice last quarter. To the balance sheet it does not exist. To operations it is a known risk. Nobody owns the gap between those two facts.
The transfer that never propagated
A line is moved from one plant to another over a weekend. Maintenance updates the location on Monday because the engineers need it. Finance keeps booking depreciation to the old cost center and the old site for a full year, so the tax allowances and the insurance both follow the wrong address until someone notices at year-end.
The granularity gap
Finance reports €1.2M of capitalized value against “Line 3.” A motor on that line fails and maintenance spends €40k repairing it. Nobody can tie that spend back to the capitalized asset, because Line 3 is one row to finance and forty tags to maintenance. Reliability and finance never get to share a number.
One list of assets, more than one way to count them
The instinct, once a team decides to fix this, is to build the one true asset hierarchy. There is no such thing. Finance rolls assets up by asset class and legal entity. Maintenance rolls the same assets up by site, system, and equipment. Tax groups them into allowance pools that match neither. Same physical machines, three different trees, and the granularity gap above is what happens when two of those trees pretend to be one.
The workable shape is the same one that works for locations: one flat, governed list of assets with stable identifiers, plus a separate parent reference for each rollup a consumer needs. MDS users built these as derived hierarchies over domain attributes, and whatever replaces MDS needs the same separation: the list of assets is master data, the rollups are views over it.
What to actually govern
Like the employee domain, the model itself is small. One entity, a handful of attributes, a couple of reference lists. The discipline is in deciding what the governed record holds and what stays in the source systems:
One identifier per physical asset
Not the fixed-asset register line, which gets renumbered with every ERP migration. Not the EAM tag, which often encodes a location that changes the moment the asset moves. A neutral key that survives transfers, re-tags, and system swaps.
Asset class and lifecycle status with effective dates
Planned, in service, idle, under disposal, disposed. The disposal date is the one that matters: it has to reach finance, tax, and insurance when the asset actually leaves, not when the auditor finds the gap.
Location as a reference, not a string
Point the asset at your governed location list rather than typing a site name. When a plant closes or a machine moves, the asset follows the location change instead of drifting out of sync the way the transfer story above does.
A cross-reference for every system code
The FA register line, the EAM tag, the ERP equipment number, the insurance schedule line. All of them map to one governed record, so finance and maintenance can finally join on the same asset.
Decide the granularity contract, and write it down
Agree what counts as one master asset versus a component finance never sees. There is no universally right answer here, only the answer finance and maintenance both signed off on. This is the hard step, and skipping it is why most asset programs stall.
The asset class and location come straight from your governed reference data, and the system codes are a textbook cross-reference table. The only genuinely hard part is the granularity contract, and no tool decides that for you. The argument over whether the register or the EAM is right is really an argument about which system is the source for which attribute. The value comes from finance, the condition comes from maintenance, and the governed record is where the two agree on what they are describing.
Assets rarely make a good first domain. The granularity question makes them slower to agree on than locations or reference lists. But once the easy domains are governed, assets are usually where the multi-domain program finally pays for the ghost-asset writedowns that used to show up every audit.
Common questions
What is asset master data?
The governed list of your physical assets: equipment, machinery, vehicles, infrastructure. Each record carries a stable ID, an asset class, a lifecycle status, a location, and the cross-references that link it to the fixed-asset register, the maintenance system, and the ERP. It sits above all three rather than inside any one of them.
Isn’t the fixed-asset register the system of record?
For value, yes. For the physical asset, no. The register knows what a machine cost and how it depreciates. It has no idea whether the machine still runs, where it moved, or what work order closed last week. Those live in the EAM, and a governed asset entity reconciles the two.
Fixed asset versus maintainable asset, what is the difference?
Finance capitalizes by cost and groups for depreciation, so one fixed asset can be a whole line. Maintenance tracks the units it services, so the same line is dozens of maintainable assets. Same metal, different granularity. Reconciling them is the central problem of this domain.
Where do asset hierarchies belong?
In parent attributes on a flat list, not in one deep tree. Finance rolls assets up by class and legal entity; maintenance rolls them up by site and system. Give each rollup its own parent and let reporting build the trees it needs.
One asset list, governed
In Primentra, assets are a hierarchical entity: the sample model ships with branches, areas, and zones you can repurpose as site, system, and equipment. Domain attributes point at your location and asset-class lists, an approval step sits in front of every change, and every edit lands in the audit trail. Finance, maintenance, and insurance read the governed list through integration views or the REST API. It runs on your SQL Server, deploys in a day, and costs €7,500 per year flat. The 60-day trial includes everything.