Fixed Assets - Impairment is where ERP discipline either begins or breaks.
Asset Impairment Testing and Write-Down looks operational from far away. In a real finance team, it is a chain of assertions: the right actor started the work, the required records existed, the control policy was applied, the state change was preserved, and the outcome can be explained later without rebuilding the transaction from emails and spreadsheets.
The expected business outcome is specific: Impaired assets reflected at correct carrying amount on balance sheet; P&L shows impairment loss in period of recognition; subsequent depreciation based on post-impairment carrying amount.
The control flow a finance team actually needs.
Step 1
Impairment Both IAS 36 And US GAAP With...
Step 2
Impairment Loss Posts To A Dedicated...
Step 3
Carrying Amount After Impairment Never...
Step 4
Depreciation Recalculated From...
Step 5
Impairment Reversal Supported Under...
The ERP surface involved.
Module
Fixed Assets - Impairment
Actors
Controller, External Auditor, Fixed Asset Accountant, ERP System
Tier
Tier 2
Finance area
Fixed Assets & Lease Management
Region lens
US and UK finance teams
Publication date
June 17, 2026
Impairment supports both IAS 36 (recoverable amount = max of FVLCS and VIU) and US GAAP (ASC 360 two-step: recoverability test then fair value write-down) with standard selectable per entity; impairment loss posts to a dedicated impairment expense GL account separate from depreciation; carrying amount after impairment must never be negative; depreciation recalculated from impairment date over revised remaining useful life; impairment reversal supported under IFRS (not US GAAP) with system enforcing reversal cap at original carrying amount; impairment history by asset retained for audit; impairment triggers require approval workflow.
US and UK teams have different compliance hooks, but the same control problem.
US teams usually care about clean evidence for audit support, vendor records, payment controls, tax reporting, and management review. UK teams usually care about VAT-ready records, approval evidence, digital-record discipline, and traceable postings. The country-specific details differ, but the operating pattern is the same: the ERP needs controlled records, explicit ownership, defensible state changes, and evidence that survives beyond the person who completed the task.
The control matrix.
| Control area | Requirement | Acceptance proof |
|---|---|---|
| Control 1 | Impairment supports both IAS 36 (recoverable amount = max of FVLCS and VIU) and US GAAP (ASC 360 two-step: recoverability test then fair value write-down) with standard selectable per entity | Given an active asset and a recoverable amount entered by the controller that is less than the asset's carrying amount |
| Control 2 | impairment loss posts to a dedicated impairment expense GL account separate from depreciation | when the impairment is posted (after approval workflow |
| Control 3 | carrying amount after impairment must never be negative | then the system calculates impairment loss (carrying amount minus recoverable amount), debits impairment loss expense, credits accumulated impairment, reduces the asset's carrying amount to the recoverable amount, and recalculates future depreciation on the impaired carrying amount from the impairment date |
| Control 4 | depreciation recalculated from impairment date over revised remaining useful life | negative) when carrying amount after impairment would be negative then the system rejects with 422 IMPAIRMENT_CANNOT_REDUCE_BELOW_ZERO. |
| Control 5 | impairment reversal supported under IFRS (not US GAAP) with system enforcing reversal cap at original carrying amount | Impaired assets reflected at correct carrying amount on balance sheet; P&L shows impairment loss in period of recognition; subsequent depreciation based on post-impairment carrying amount. |
| Control 6 | impairment history by asset retained for audit | Impaired assets reflected at correct carrying amount on balance sheet; P&L shows impairment loss in period of recognition; subsequent depreciation based on post-impairment carrying amount. |
Audit evidence is a chain, not a folder.
| Evidence layer | What should be preserved |
|---|---|
| Business event | An external event (market decline, technology obsolescence, regulatory change) triggers an impairment review. The controller enters the asset's estimated recoverable amount (higher of fair value less costs to sell and value in use). If the recoverable amount is less than the asset's carrying amount (cost minus accumulated depreciation), the system calculates the impairment loss. The accountant records the impairment: the system reduces the asset's carrying amount by the impairment loss, debits impairment loss expense, and credits accumulated impairment. The reduced carrying amount becomes the new depreciable base; useful life may also be revised. Subsequent depreciation recalculates based on the impaired carrying amount. |
| Control rules | Impairment supports both IAS 36 (recoverable amount = max of FVLCS and VIU) and US GAAP (ASC 360 two-step: recoverability test then fair value write-down) with standard selectable per entity; impairment loss posts to a dedicated impairment expense GL account separate from depreciation; carrying amount after impairment must never be negative; depreciation recalculated from impairment date over revised remaining useful life; impairment reversal supported under IFRS (not US GAAP) with system enforcing reversal cap at original carrying amount; impairment history by asset retained for audit; impairment triggers require approval workflow. |
| Acceptance proof | Given an active asset and a recoverable amount entered by the controller that is less than the asset's carrying amount; when the impairment is posted (after approval workflow); then the system calculates impairment loss (carrying amount minus recoverable amount), debits impairment loss expense, credits accumulated impairment, reduces the asset's carrying amount to the recoverable amount, and recalculates future depreciation on the impaired carrying amount from the impairment date; (negative) when carrying amount after impairment would be negative then the system rejects with 422 IMPAIRMENT_CANNOT_REDUCE_BELOW_ZERO. |
| Data record | |
| System event | |
| Lifecycle state | |
The useful version of this workflow is not only fast. It is inspectable. A controller, auditor, or operator should be able to move from source event to system record to state transition to final business outcome without guessing.
Implementation contracts.
Reference data model
`asset_impairments` { id: string, external_id: string, asset_id: string, impairment_date: date, recoverable_amount_minor: int64, carrying_amount_at_impairment_minor: int64, impairment_loss_minor: int64, currency_code: char(3), standard: enum(IAS_36,ASC_360), impairment_je_id: string, approved_by: string, status: enum(PENDING_APPROVAL,POSTED) }; `asset_impairment_reversals` linked to `asset_impairments`; (reference, product may differ).API and events
`POST /v1/fixed-assets/{id}/impairments` { impairment_date, recoverable_amount_minor, currency_code, standard, external_id } -> 201 { id, status: PENDING_APPROVAL, impairment_loss_minor }; `POST /v1/asset-impairments/{id}/approve` -> 200 { status: POSTED, impairment_je_id }; `GET /v1/fixed-assets/{id}/impairment-history`; emits `fixed_asset.impaired` event; idempotent via `external_id`.State transitions
`PENDING_APPROVAL -> POSTED`; IFRS entities allow reversal via `asset_impairment_reversals` (capped at original carrying amount minus subsequent depreciation); US GAAP blocks reversal with 422 IMPAIRMENT_REVERSAL_NOT_PERMITTED_GAAP; guard: approval required before posting.Common implementation traps.
Treating the workflow as data entry
If the ERP only stores the final record, the team loses the decision trail that explains how the record became valid.
Hiding exception logic
Exceptions need owners, reason codes, and time stamps. A vague pending state is not a control.
Posting without recovery design
Retries, duplicate submissions, and partial failures must be explicit so the system does not create inconsistent records.
Skipping evidence design
A workflow that cannot produce evidence on demand will eventually push finance teams back into manual screenshots and spreadsheets.
Where Rivane fits.
Rivane is built for finance workflows where automation must stay tied to source documents, approvals, state transitions, ledger impact, reporting, and audit evidence. Use this guide as a checklist for evaluating whether an ERP workflow is merely digitized or actually controlled.
References and source basis.
These sources provide the standards, regulatory, or government context around the flow. They are included so the guide is useful to finance operators, auditors, and implementation teams, not only buyers reading software copy.