Agentic Fixed Asset Accounting: Catching Capex/Opex Misclassification and Depreciation Drift Before the Asset Register Splits From the GL

Most businesses have a written capitalization policy — a dollar threshold, a list of qualifying asset categories, rules for what counts as a betterment versus a repair — and most capex/opex miscoding happens because whoever codes the AP invoice is applying judgment under time pressure rather than checking the policy line by line. An agent can do the mechanical version of that check at invoice-coding time: does the line item exceed the capitalization threshold, does the vendor and item description match a category the policy treats as capital, is this a repair to an existing asset (expense) or a betterment that extends its useful life or capacity (capital). None of these questions are hard individually. What makes them error-prone by hand is volume — a mid-size company codes hundreds of invoices a month, and the policy has to be re-applied identically to every one of them, which is exactly the kind of consistency a person doing it 200 times loses and a rule engine backed by an agent doesn't.

A depreciation schedule is configured once, at acquisition, and then runs on autopilot unless someone actively intervenes to change it. But the physical facts it depends on — where the asset is, what it's being used for, whether it's still in service — change through channels that don't touch the fixed asset module at all: a maintenance work order, a facilities relocation ticket, a capacity-planning decision to idle a line. An agent that cross-references the asset register against these operational systems can flag the mismatches: an asset still depreciating on its original useful life after being redeployed to a role with a materially different expected life, an asset tagged active in the register with no corresponding activity (usage, maintenance, output) in months, a location field that hasn't matched a facilities system in over a year. Each of these is a candidate for someone to review, not an automatic correction — the agent's job is surfacing the discrepancy with the specific evidence behind it, not deciding the new useful life itself.

Impairment testing under most accounting frameworks is triggered by indicators — a significant drop in an asset's market value, a change in how it's used, physical damage, a plan to dispose of it early — and the accounting team is rarely the first to know about any of them. Operations knows a line was idled. Facilities knows equipment was damaged. Sales knows a product line the asset supports is being discontinued. An agent that watches for these triggers in the systems where they actually originate — maintenance and downtime logs, capacity utilization reports, product-discontinuation decisions — and maps them back to the specific asset or asset group they affect can get an indicator in front of the accounting team while there's still time to do a proper test, instead of at year-end close when the auditors ask why an idle asset is still being depreciated at full value. What it produces is a flagged asset and the specific triggering fact, not an impairment calculation — that math, and the judgment about whether the trigger is real, stays with the accountant.

A useful life is an estimate made at acquisition, and estimates are supposed to be revisited when facts change — but revisiting them requires someone to notice the original estimate no longer fits, which rarely happens absent a trigger. An agent can compare an asset's assigned useful life against operational signals that bear on it: maintenance frequency and cost trending up in a way that suggests accelerating wear, an asset still in heavy daily use well past its scheduled end of life with no plan to replace it, or a category of assets where the actual disposal age, tracked across the whole fleet, consistently differs from what the depreciation schedule assumes. None of this proves the estimate is wrong — assets legitimately run past their scheduled life all the time — but a pattern across a category is a much stronger signal than any single asset, and it's the kind of aggregate comparison that's tedious to do by hand and mechanical to do continuously.

The output that actually gets used is a short list an accountant can act on in an afternoon: this invoice was coded to expense but matches capital criteria, with the invoice and the policy clause it matches; this asset's location hasn't matched facilities in fourteen months, with the last confirmed facilities record; this asset group shows a maintenance-cost trend inconsistent with its remaining useful life, with the underlying maintenance data. Ranking these by dollar impact and by how close they are to affecting the current close matters more than surfacing every discrepancy with equal weight, because a capex/opex miscoding on a large purchase is a materially different problem than a stale location field on a fully depreciated laptop, and a queue that doesn't distinguish between them trains people to skim past all of it.