Fixed-asset accounting: what software can run and what still needs a person

Software can already run depreciation, post period-end entries and match the asset sub-ledger to the general ledger. People still decide what gets capitalised, judge impairments and revaluations, and confirm that assets physically exist. None of this works until each asset record carries a correct class, cost, in-service date and location.

Steps software can take over now

Depreciation is the clearest case. Once an asset has a method, a useful life and a start date, the calculation is arithmetic. A fixed-asset module will run it for every book at once, including the separate tax book, and post the journal at close without anyone touching a spreadsheet.

Additions that arrive through purchasing are close behind. When a purchase order is coded to a capital project and the invoice matches it, the system can create the asset record, assign the class and start depreciating on receipt. The same holds for retirements triggered by a sale or scrapping entry, provided the disposal is recorded against the right asset number.

Reconciliation of the asset sub-ledger to the general ledger is mostly matching. Software does it well and does it every period, which beats the quarterly scramble most teams live with. What it cannot do is explain a break. It can only show where one sits.

Where AI helps but should not have the final word

The hardest daily question in fixed assets is whether a cost is capital or expense. A new roof, a replacement motor, an upgrade to a software licence: each sits on the line between enhancement and repair. AI models trained on past coding decisions can read invoice text and suggest a treatment. They are useful for triage. They also repeat whatever mistakes the history contains.

Similar logic applies to proposing a useful life for an unfamiliar asset, reading lease agreements to pull out terms, or flagging records that look like ghost assets because nothing has posted against their cost centre in a long time. Treat each output as a prompt for review.

Steps that need a person

Policy comes first and stays human. Capitalisation thresholds, componentisation rules and the choice of depreciation method are accounting judgments with audit consequences. Someone has to own them and update them when standards or the business change.

Impairment and revaluation need judgment about future use and market value. Transfers between legal entities raise tax and transfer-pricing questions that a rule engine will get wrong in edge cases.

Physical inventory needs feet on the floor. Scanners and tags speed up counting, but deciding what to do with an asset found in the wrong building, or not found at all, belongs to a person who knows the site.

Tax and statutory reporting can be generated by the system. Signing it off cannot.

What has to be true about the data first

Automation amplifies whatever sits in the asset register. Before switching anything on, check these conditions.

Every asset needs a single unique identifier that links the physical item, its tag and its ledger record. Many registers carry duplicates created when an asset moved departments and someone set up a new record instead of transferring the old one.

In-service dates must be real. A common shortcut is to use the invoice date, which starts depreciation early for anything that sat in a warehouse or under construction.

Construction in progress needs its own clean handling. Projects that finished long ago but were never moved out of that account will distort any automated depreciation run.

The policy itself has to be written down precisely enough to encode. If the threshold depends on who is asked, software cannot apply it.

Finally, the sub-ledger and general ledger must agree before automation goes live. Starting from a known break means every future reconciliation carries it forward.

Questions to ask the people who run the process

What gets written in procedure manuals and what happens at the desk often diverge. These questions tend to surface the gap.

• When an invoice could be capital or repair, who actually decides, and what do they look at?
• How do assets get set up when they arrive outside the purchasing system, such as through a project or an acquisition?
• Which manual journals get posted to fixed-asset accounts at close, and why?
• When was the last physical count, and what happened to the items nobody could find?
• Are there assets everyone knows are gone but are still on the register?
• How do transfers between sites or entities get communicated to accounting, if they do at all?
• Which spreadsheets sit alongside the system, and what would break if they disappeared?
• For tax reporting, does the team trust the system output or rebuild it?

Answers to the spreadsheet question usually reveal the real process. A side file that tracks useful lives or project status is a sign the master data cannot yet support automation.

Where changes tend to go wrong

The usual failure is automating depreciation on a register nobody has cleaned. The postings become fast and confidently wrong. Another is removing the human review of capital versus expense coding because a model scored well in testing, then discovering at audit that repairs were capitalised for a whole year.

Sequence the work so the data cleanup and the physical count finish before the system takes over the calculation.

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.