How fixed-asset accounting is usually set up in finance and ERP systems

In most ERP systems, fixed-asset accounting runs as a subledger beside the general ledger. Each asset gets a master record holding its cost, class and depreciation rules. Purchases, projects and disposals feed that register, a scheduled run posts depreciation, and the subledger is reconciled to the ledger each period.

Where the asset register sits

The asset module is almost always separate from the general ledger. It keeps detail at the level of individual items or groups, and it posts summarised entries to control accounts for cost, accumulated depreciation and depreciation expense. Users should not post to those control accounts directly. When manual journals are allowed to hit them, the register and the ledger drift apart and someone spends the close hunting for the gap.

Policy lives partly in documents and partly in configuration. The capitalisation threshold, useful lives by class and the depreciation method are usually set as defaults on each asset class. That means a policy change is also a system change, and it often only affects new assets unless someone deliberately recalculates old ones.

The asset master record

Every asset carries a master record. Typical fields include a description, asset class, acquisition date, in-service date, cost centre, location, custodian, serial or tag number, and the depreciation settings for each book. Many organisations also hold a link to the supplier invoice or the project that created the asset.

The class drives most of the behaviour. Pick the wrong one and the asset will depreciate over the wrong life and post to the wrong accounts. Master data quality is where most downstream problems start.

How assets enter the register

Additions arrive by a few routes. A purchase order coded to an asset account can create the record automatically when goods are received or the invoice is matched. Larger items are often built up in a construction in progress account, collecting costs from several invoices and internal labour, then settled into one or more finished assets once they go into use. Leased assets may be created from a separate lease module. Software and internally developed tools follow their own capitalisation rules, and those rules tend to be argued about.

Retirements work in reverse. The asset is marked as sold, scrapped or lost, its cost and accumulated depreciation are removed, and any gain or loss posts against proceeds. Disposals are the transaction most often forgotten, because nobody in finance sees a forklift leave the yard.

Changes during an asset's life

After capitalisation, the record keeps moving. Transfers between cost centres, sites or legal entities are recorded as transfer transactions so history is preserved. Enhancements that extend life or capacity are added to cost. Revaluations and impairments adjust carrying value where accounting rules permit or require it.

Repairs and routine maintenance are expensed. The judgement between a repair and an enhancement is usually made by whoever codes the invoice, which is why the policy needs clear examples and not just a principle.

Depreciation runs and the period close

Depreciation is calculated by a scheduled run inside the module. It applies the method and life from each record, produces a posting, and sends a summarised journal to the ledger. Most systems can simulate the run first, which is worth doing before every close.

The run belongs in the close calendar. Additions and disposals should be cut off before it, or the period's charge will be wrong. Once the period is closed in the asset module, late items roll forward and catch up in the next run.

Reconciliation and physical verification

The register is reconciled to the general ledger control accounts every period. Differences usually trace back to manual journals, unsettled construction balances or postings made after the asset period was closed.

Physical verification is a separate exercise. Teams compare tagged items on site against the register, using scanners or printed lists, then raise disposals for missing assets and records for untagged ones. Many organisations run counts on a rolling basis by location.

Tax and statutory books

Most systems support several depreciation books on the same asset. One serves management or group reporting, another follows local statutory rules, and a third may follow tax rules with different lives or accelerated allowances. Each book runs independently and feeds its own reports. The tax team usually pulls movement schedules and deferred tax inputs straight from the module.

Questions to ask the people who run it

The documented process and the daily one rarely match. These questions tend to surface the gap:

• How does a new asset actually get created, and who decides it is capital and not expense?
• When an item goes into use, who tells finance, and how late does that information usually arrive?
• Are any journals posted directly to asset control accounts? Why?
• What happens to construction in progress balances that never get settled?
• How do disposals reach finance? Is anyone checking for assets that have quietly disappeared?
• When was the last physical count, and what happened to the differences it found?
• Do the tax and statutory books get updated in the system, or in a spreadsheet kept by one person?
• Which reconciling items reappear every period without ever being cleared?
• If a useful life changed tomorrow, who would update the class settings, and would existing assets be recalculated?

APQC's Process Classification Framework® (PCF) is an open standard developed by APQC, a nonprofit that promotes benchmarking and best practices worldwide. To download the full PCF or to view definitions and measures, please visit www.apqc.org/pcf.