Introduction
A SAP asset retirement is the one lifecycle posting in SAP fixed asset management you cannot quietly reverse on the floor: once the record is derecognized, the books say the asset is gone. The discipline that keeps that statement true is evidence before posting: proof the disposal was approved, proof the asset physically left, and only then the accounting instruction.
This guide classifies the disposal event, maps SAPтАЩs retirement routes from the official sources, and builds the control the SERP never covers: approval, physical checkout, and SAP posting as three statuses that close separately.
In this guide, you will learn:
- What distinguishes SAP asset retirement, scrapping, sale, partial disposal, and missing-asset investigations, and how the event determines the appropriate accounting route.
- How to establish disposal approval, condition evidence, and physical checkout before issuing the SAP retirement instruction.
- How to manage approval, physical checkout, and SAP posting as separate statuses, with assigned owners, evidence references, and ageing rules for unresolved cases.
- How to reconcile retirement postings with disposal evidence, verify register updates, handle parent and component disposals, and preserve a complete audit trail.
Retirement, scrapping and sale: which event occurred?
Asset retirement covers different outcomes depending on what happened to the asset. A sale involves disposing of the asset for revenue. Asset scrapping in SAP means retiring an asset without sale proceeds because it was destroyed, dismantled, or discarded. If verification shows an asset is missing, it should not be classified as sold or scrapped until an investigation establishes what happened.
Classify before routing: the event decides the SAP route, the evidence required and who approves. Treating тАШmissingтАЩ as тАШscrappedтАЩ is how theft hides inside disposal the control failure this guide exists to prevent.
SAP retirement routes by event and edition
SAP supports every legitimate disposal route; the control question is which event you can evidence, not which transaction exists.
Event | SAP route | Revenue? | Evidence that must exist first |
|---|---|---|---|
| Scrapping / physical destruction | Retirement without revenue (scrapping) | No | Disposal approval, condition/photo proof, confirmed physical removal |
| Sale to a customer | Integrated or non-integrated retirement with revenue; SAP calculates gain/loss | Yes | Approval, sale documents, dispatch/handover proof |
| Partial disposal (some units/part of value) | Partial retirement on the applicable route | Either | Unit-level identity of the retired portion (tags/serials) |
| Not found at verification | NO route yet; investigation first | тАФ | Search record, custodian statement, approved investigation outcome |
Route mechanics value dates, period control, gain/loss calculation, integrated versus non-integrated postings are covered properly in the official lesson, which this guide defers to rather than paraphrasing. Procedures are edition- and release-specific; label yours before following any walkthrough.
Full versus partial retirement; with versus without revenue
Asset retirement depends on two factors: whether the entire asset or only part of it is retired, and whether the disposal generates revenue. Partial retirement is especially challenging because the retired portion must be identifiable. Without unit level tagging, teams may have to estimate the value of the portion being retired, increasing the risk of inaccurate asset records. See how unit-level identity in SAP asset master data supports accurate asset records.
Evidence and approvals before an accounting instruction
The pre-posting pack is the same shape for every route: an approved disposal request (approver per your matrix, by value, type and location); condition and photo evidence of the asset as found; checkout proof that it physically left through the approved channel; and the sale or scrap documentation the route requires.
The not-found case gets the opposite treatment: it opens an investigation with an owner, evidence, and a reason code (the asset may simply have moved without a recorded asset transfer in SAP), and only a documented, Finance-approved outcome can become a retirement decision. Derecognition itself follows your applicable policy and standards under IAS 16, on disposal or when no future economic benefits are expected, never automatically from a count result.
Separate approval, physical checkout and SAP posting statuses
A disposal case carries three statuses, and each closes on its own evidence. Treating any one as proof of the others is how registers end up with approved-but-present assets, or gone-but-still-depreciating ones.
Approved тЙа gone тЙа derecognized тАФ three statuses, three proofs, closed in order.
Status | Closes when | Evidence | Owner | Permitted next action |
|---|---|---|---|---|
| 1. Disposal approval | Approver(s) per matrix sign the request | Approved request with reason and condition proof | Approver per matrix | Initiate checkout; nothing may leave before this |
| 2. Physical checkout | Asset confirmed out through the approved channel | Gate/checkout record, scrap or dispatch proof, date | Site/security | Issue the accounting instruction |
| 3. SAP posting | SAP acknowledges the retirement posting | Posting reference and acknowledgement | Finance | Close the case; file the pack |
Worked stuck-case A: approved, awaiting checkout: A scrapping request is approved on the 4th; the machine still sits by the loading bay on the 20th. Status 1 closed, status 2 open and ageing; the permitted action is chasing the physical removal, and the register correctly still shows the asset. Posting now would be the error.
Worked stuck-case B: gone, awaiting ERP acknowledgement: A sold asset left site on the 10th with full checkout proof; no retirement posting exists on the 31st. Statuses 1тАУ2 closed; status 3 open: the asset is depreciating after departure, and the permitted action is Finance executing the posting from the filed evidence.
In an AssetCues deployment, these are the native mechanics: retirement runs through configured approvals with condition evidence, the productтАЩs retirement state changes at physical-disposal approval (or at initiation where no such approval is configured), checkout is tracked separately and can remain pending, and the ERP update instruction follows the approved, evidenced case with outbound timing confirmed per integration. SAPтАЩs posting and the accounting decision behind it stay with Finance.
Parent, child and replaced-component decisions
Component structures complicate disposals in two directions. Retiring a child (a subnumber or tracked component) is a partial event against the parent structure: the retired component needs its own identity and evidence, while the parent continues.
Replacing a component triggers the companion accounting question: under component accounting, the replaced partтАЩs carrying amount is derecognized when the new part is recognised a policy-governed decision for Finance, distinct from the physical swap itself. Eligibility rules for which structures support which partial routes are configuration- and policy-specific; validate them with your FI-AA team before standardising the workflow.
Reconcile completion and preserve the audit trail
Close the case by checking the three statuses against each other and the register: the postingтАЩs value date matches the evidenced disposal, the asset no longer appears in active asset lists and stops being counted in verification scopes, and the pack request, approvals, condition proof, checkout record, and posting reference are filed against the case.
That filed pack is what turns next yearтАЩs audit question from reconstruction into retrieval. Disposals are the lifecycleтАЩs final test of the whole control chain.
Key takeaways
- SAP supports retirements with or without revenue. Full and partial scrapping count as retirement without revenue.
- Asset value dates and period controls affect retirement calculations. Posting dates must reflect evidence, not convenience.
- Approval, physical checkout, and SAP posting are separate milestones. Workflow status alone does not prove all three occurred.
- A missing asset requires investigation, not retirement. IAS 16 paragraph 67 permits derecognition upon disposal or when benefits are no longer expected.
- A disposal is complete when all three statuses close. Store approval, checkout proof, and posting references against the case.
Conclusion
Effective SAP asset retirement requires more than an approved request; teams must confirm physical removal and complete the SAP posting with supporting evidence. Asset scrapping in SAP follows the same controls, keeping disposal approval, physical checkout, and accounting records aligned. Treating missing assets as scrap without investigation can lead to inaccurate records and weaken audit controls.
SAP Asset Retirement FAQs
Q1. Does approval mean the asset has left the premises?
Ans: No. Approval authorises the disposal; checkout proves departure. The two are separate statuses with separate evidence, and the gap between them approved assets still on site is exactly what the three-status log makes visible.
Q2. What is the difference between asset retirement and scrapping in SAP?
Ans: Retirement is the accounting process of removing an asset from the register, with or without revenue. Scrapping is the without-revenue case: the asset is physically destroyed or discarded rather than sold. SAP supports both routes, full or partial.
Q3. Can a missing asset be scrapped in SAP?
Ans: Not directly. A not-found result opens an investigation the asset may be moved, loaned or mislabelled. Only a documented, Finance-approved investigation outcome becomes a retirement decision, and the derecognition follows your applicable policy, not the count result.
Q4. What is a partial retirement in SAP?
Ans: Retiring part of an asset, some of its units, or part of its value while the record continues. It is controlled only when the retired portion has its own identity (tags, serials, or a component subnumber), so the evidence names exactly what left.
Q5. When does depreciation stop for a retired asset?
Ans: The retirement posting, with its value date and period control, governs the accounting effect which is why posting late (or early) against the evidenced disposal date distorts depreciation. Your FI-AA configuration and policy determine the specifics per route.
Q6. What evidence should exist before a retirement posting?
Ans: An approved disposal request, condition/photo proof of the asset, checkout or dispatch confirmation that it physically left, the sale or scrap documentation the route requires, and, after posting, the SAP reference filed against the case.
CA Sunny Shah
