The Fixed Assets module is one of Acumatica's better-behaved corners — once configured, it grinds out depreciation month after month without drama. The catch is the word "configured": depreciation behaviour is determined by a chain of settings (posting book, depreciation method, averaging convention, useful life, class defaults) made mostly at implementation time, and mistakes surface months later as numbers that are subtly, compoundingly wrong. This is a walkthrough of the chain, with the settings that matter and the ones that bite.
Books: where depreciation lives
Everything starts on the Books screen (FA205000). A posting book generates GL transactions; non-posting books calculate depreciation without touching the ledger — for tax bases, IFRS-vs-local-GAAP differences, or management views. One posting book, several non-posting books is the standard shape. In Kenya I typically run the posting book on the company's accounting policy and a non-posting book mirroring the KRA wear-and-tear classes, so the tax computation at year-end reads straight off a report instead of a spreadsheet.
Each book has its own calendar. Verify the book calendars align with your GL financial periods before creating a single asset — mismatched calendars are miserable to fix after assets exist.
Depreciation methods and averaging conventions
The Depreciation Methods screen (FA202500) ships with the standard catalogue: straight-line, declining balance (150%/200%), sum-of-the-years digits, units of production (via custom methods), plus table-based methods for jurisdictions that need them. For most of my clients, straight-line covers 95% of assets and declining balance covers vehicles and computing equipment.
The setting people skim past is the averaging convention, and it changes real numbers:
- Full period — a full period's depreciation in the period placed in service.
- Mid period — half a period at the start and end of life.
- Next period — depreciation starts the period after acquisition.
- Full day / actual days — daily-accurate, for policies that prorate by days.
Whatever the accounting policy manual says, encode it here and stop arguing about it monthly. A mismatch between the convention and the policy is the most common source of "the auditor's model says X, Acumatica says Y" tickets I see, and it is always a five-minute check on the method definition.
Asset classes: defaults that do the heavy lifting
Fixed Asset Classes (FA201000) bundle useful life, method per book, GL accounts (asset, accumulated depreciation, depreciation expense, gain/loss), and the averaging convention. A clean class structure — MOTOR-VEH, COMP-EQUIP, FURN-FIT, BUILDINGS, LEASEHOLD — means whoever converts a purchase into an asset makes zero accounting decisions: pick the class, everything defaults. That is the goal; every field a user must fill manually is a future inconsistency.
Class: COMP-EQUIP
Useful Life: 3.00 years
Book: FIN Method: SL Averaging: Full Period
Book: TAX-KE Method: DB-30 Averaging: Full Period (non-posting)
Accounts: 1240 Computer Equipment
1249 Accum. Depr. — Computer Equipment
6350 Depreciation Expense
Reading and trusting the depreciation schedule
Per asset, the projected schedule lives on the Fixed Assets screen (FA303000), Depreciation tab — period by period, per book: calculated amount, depreciated-to-date, net value. Two operational notes:
- The schedule is a projection until the Calculate Depreciation / Depreciate process (FA502000) runs for the period and the FA transactions are released to GL. The month-end step is: run depreciation for all assets, review the FA register, release. Put it on an Automation Schedule with the release step manual.
- Changes to an in-service asset — life extension, method change, additions to basis via the Asset Summary's cost additions — trigger recalculation from the current period forward by default. Acumatica does not silently restate history, which is what you want; catch-up amounts land in the current period. Understand this before you "fix" a wrong useful life eighteen months in, and warn the accountant that month's expense will jump.
For assets converted from a legacy system, you load original cost, in-service date, and accumulated depreciation to the cutover date, and Acumatica continues from there. The classic error is loading them as new acquisitions at net book value — the schedule then depreciates NBV over a fresh full life, understating monthly expense forever. Use the conversion fields (or the Fixed Assets import scenario with Depreciated history) and reconcile total accumulated depreciation to the legacy register before releasing anything.
Disposals, transfers, splits
Mid-life events run through their own processes — Dispose (full or partial, with proceeds and gain/loss computed against the disposal-date NBV), Transfer (between branches/departments, moving future expense to the new cost centre), and Split (proportioning cost and accumulated depreciation, for partial disposals of bulk assets). The only advice that matters here: never journal these directly in GL. Every manual journal against an FA-controlled account creates a subledger-to-GL gap that someone must reconcile at year-end. Same rule as bank accounts: control accounts stay controlled.
The reports the auditors actually want
The FA module's standing exports at year-end: the Fixed Asset Register (cost, additions, disposals, accumulated depreciation, NBV by class — the note in the financial statements, basically), the depreciation projection for budget season (run Calculate for future periods in a non-posting scenario or pull the schedule via GI), and the tax book register for the wear-and-tear computation. Build the GI versions once, expose them read-only, and the annual audit's FA section becomes self-service.
Wrapping up
Depreciation quality is decided at configuration time: books aligned to real reporting obligations, methods with the averaging convention your policy actually states, classes that default everything, and migrated assets loaded with their history intact. Do that, schedule the monthly run, keep manual journals away from FA accounts, and the module rewards you with the rarest thing in ERP finance — a subledger that just agrees.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.