Acumatica · Customization

Acumatica Fixed Assets — Depreciation Schedule Configuration

How to configure the Acumatica fixed asset depreciation schedule — book, tax, and IFRS books, calculation methods, half-year and mid-quarter conventions, and the month-end batch that posts depreciation automatically.

John Kihiu12 min read

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:

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.

TYPICAL CLASS SETUP
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:

Migrated assets: the cutover trap

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.

John Kihiu
Acumatica ERP Developer · Laravel Engineer

Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.