Two SAP modules describe the same physical machine and were never built to reconcile each other automatically. Plant Maintenance (PM) knows what is physically installed; Asset Accounting (FI-AA) knows what is capitalized and depreciating. When a technician replaces a major component, PM records the work — and FI-AA keeps depreciating the part that was just scrapped. Nothing in standard SAP forces those two truths back together at the component level, so the register fills with ghost components: capitalized parts that no longer physically exist.
This is the “SAP component accounting gap.” It is not a bug and not unique to one company — it is the default behavior of two modules that share master data but not the transactional lifecycle of a component. Left alone, it produces a fixed-asset register that is simultaneously overstated (retired parts still capitalized) and understated (replacement parts expensed instead of capitalized) — and almost always stale.
Two modules, two versions of the truth
PM and FI-AA can be linked at the master-data level (an asset master can reference an equipment record), but that link is descriptive, not transactional. A work order closing in PM does not post a derecognition in FI-AA.
| Dimension | SAP PM (Plant Maintenance) | SAP FI-AA (Asset Accounting) |
|---|---|---|
| Owns | Physical reality — what is installed, where, condition | The financial record — capitalized cost, depreciation, NBV |
| Core objects | Equipment master, functional locations, BOMs, work orders | Asset master records, sub-numbers, depreciation areas |
| Key transactions | IE01 equipment · IW31 work order | AS01 create · ABZON acquire · ABAVN/ABAON retire |
| A component swap is… | a completed work order (operational event) | …nothing, unless someone manually posts a partial retirement + addition |
| Granularity | Component-level (the motor is its own equipment record) | Usually whole-machine (one asset master = the whole line) |
That last row is the crux. PM is often modeled at the component level; FI-AA, in most real deployments, is modeled at the whole-machine level. So even when maintenance precisely tracks “Motor A out, Motor B in,” there is no corresponding sub-asset in FI-AA with its own carrying amount to retire. The accounting has nowhere to put the event.
Where the gap opens: the component replacement
Follow a single, ordinary maintenance event — replacing a significant part of a capital asset:
- PM side: a work order is raised, the old part removed and scrapped, the new part installed, the order confirmed and closed. Operationally, perfect.
- The replacement part is usually issued from MRO inventory to a cost center, hitting the P&L as maintenance expense — even when it is significant enough that IAS 16 says it should be capitalized. Result: PP&E understated.
- The removed part is never derecognized, because there is no component-level carrying amount in FI-AA to remove and no automated trigger from the closed work order. Result: PP&E and accumulated depreciation overstated, and the company keeps booking depreciation on a part that is gone.
SAP can post a partial retirement — ABAVN (scrapping) and ABAON (sale) both accept a retirement by amount, percentage, or quantity. The problem is not capability; it is that this is a manual Asset Accounting posting that nobody triggers from a closed work order, and that requires knowing the carrying amount of the replaced part — which a whole-machine asset master cannot give you. So in practice it almost never happens, and the subledger drifts further from reality with every maintenance cycle.
What IAS 16 actually requires
§43 — each part of an item of PP&E with a cost significant to the whole must be depreciated separately (the component approach). §13 — when you replace a part, you recognize the new part’s cost in the asset’s carrying amount and derecognize the carrying amount of the replaced part. §70 — you derecognize the replaced part even if it was never depreciated separately; if its original cost is unknown, use the cost of the replacement as a proxy. A major component replacement is a recognition-plus-derecognition event, not a maintenance expense. ASC 360 / US GAAP is less prescriptive on componentization, but the existence assertion and impairment testing apply just the same.
Five signs you have the gap
None of these require an SAP audit to spot — a controller and a maintenance planner in the same room can confirm them in an afternoon.
- PM work-order completion does not trigger any posting in FI-AA — no bridge between maintenance confirmation and asset derecognition.
- Asset masters are modeled at the whole-machine level — no component sub-numbers with their own carrying amounts to retire.
- Retirements only ever run through whole-asset disposal; partial, by-value retirements for replaced components are effectively never posted.
- Capitalized maintenance is settled onto the asset but the part it replaced is left on the books.
- The subledger has not been reconciled to a physical, component-level inventory since the last whole-asset count — if ever.
If three or more are true, you are almost certainly carrying ghost components — and the longer it has run, the larger the correction.
What it actually costs you
| Exposure | How the gap creates it |
|---|---|
| Overstated PP&E | Replaced components stay capitalized; gross asset and accumulated depreciation both inflated. |
| Phantom depreciation | You keep expensing depreciation on parts that no longer exist — misstating the P&L every period. |
| Existence-assertion failure | You cannot prove a capitalized component physically exists — a hit to the existence assertion under ASC 360 and a candidate SOX 404 ICFR deficiency. |
| Tax leakage | Missed partial-disposition / general-asset-account dispositions under the tangible-property regs mean unclaimed loss deductions on retired components. |
| Insurance over-payment | Insured values built on an inflated register mean premiums paid on assets you no longer own. |
| Impairment blind spots | Component-level impairment can’t be tested on assets the books don’t model at the component level. |
Why automation alone won’t save a register that has already drifted
The instinct — and the pitch from SAP-bolt-on software vendors — is to automate the bridge: have work-order completion fire a derecognition workflow so PM and FI-AA stay in lockstep going forward. That is genuinely worth doing. But it is necessary, not sufficient.
If your subledger is already wrong — years of un-derecognized components, expensed capital parts, whole-machine masters — then automating the workflow simply preserves the existing error and starts posting on top of a false baseline. You cannot reconcile to a number you don’t trust. Before the loop can be closed automatically, someone has to establish what is actually installed, right now, at the component level. That is a physical-verification problem, and no amount of in-SAP automation produces it.
The order of operations that works
1. Establish ground truth — a component-level physical verification of the assets that matter (RFID / barcode tagging of significant parts, mapped to functional locations). 2. Reconcile three ways — physical reality ↔ PM equipment master ↔ FI-AA subledger. 3. Book the catch-up — derecognize the ghost components, capitalize the parts that were wrongly expensed, correct depreciation. 4. Sustain — only now wire work-order completion to the AA treatment so the register stays right.
Closing the loop — physical-first and system-agnostic
This is where an independent, vendor-neutral partner matters more than another module. CPCON does not sell you an SAP add-on and walk away; we establish the physical, component-level baseline your subledger has been missing, reconcile it across maintenance and accounting, and stand up the ongoing process — whether your stack is SAP (PM + FI-AA), Oracle EAM, IBM Maximo, or a mixed environment. The verification is the product; the system is just where the corrected truth gets posted.
It is the same discipline behind our work on EAM–ERP reconciliation, IAS 16 componentization, and ghost-asset detection — applied to the one event that quietly breaks the most registers: the component swap.
