Acumatica Fixed Assets — Extension Patterns

Fixed Assets is a small module with an outsized capacity to go wrong, because depreciation calculations touch GL posting, tax reporting, and disposal accounting all at once. Most FA customizations are about depreciation methods or disposal handling that don't match the client's specific accounting policy — rarely about the core asset record itself.

Core DACs and screens

The asset record is FixedAsset, maintained through the Fixed Assets screen (commonly AM301000 in the Acumatica numbering scheme), with depreciation history tracked in something like FADepreciationHistory per book. Assets can originate from an AP bill line (capitalization) or be entered directly; the graph is FixedAssetMaint, and depreciation runs through a scheduled calculation process rather than being computed inline on save.

Extension points

Custom depreciation methods are the highest-value extension point here. Acumatica ships a set of standard methods (straight-line, declining balance, and variants), and adding a method the client's accounting policy requires but the stock set doesn't cover means implementing a calculation class against the method interface the FA engine expects, then registering it so it's selectable from the Depreciation Method field like any built-in option — not intercepting the graph's save event to overwrite computed values after the fact.

A realistic scenario: custom disposal handling

A common ask is routing disposal gain/loss to a different GL account depending on disposal reason (sold vs. scrapped vs. stolen) rather than the single disposal account stock configuration assumes. This is typically a small graph extension on the disposal action that reads a custom field (disposal reason) and overrides the GL account used for the gain/loss posting before the transaction is committed.

public class FixedAssetMaint_DisposalReason_Extension : PXGraphExtension<FixedAssetMaint>
{
    #region FixedAssetExt
    public class FixedAssetExt : PXCacheExtension<FixedAsset>
    {
        [PXDBString(1, IsFixed = true)]
        [PXStringList(new[] { "S", "C", "T" }, new[] { "Sold", "Scrapped", "Stolen" })]
        public string DisposalReason { get; set; }
        public abstract class disposalReason : PX.Data.BQL.BqlString.Field<disposalReason> { }
    }
    #endregion

    protected virtual string GetDisposalAccount(FixedAsset asset)
    {
        var ext = PXCache<FixedAsset>.GetExtension<FixedAssetExt>(asset);
        return ext?.DisposalReason switch
        {
            "T" => "6150-00", // theft/loss account
            "S" => "6100-00", // scrap account
            _ => null // fall back to stock configured disposal account
        };
    }
}

The fallback to the stock configured account when no reason is set matters — the customization should degrade to standard behavior, not require the new field to be populated for existing disposal flows to keep working.

Tax books and multi-book depreciation

Assets typically depreciate across more than one book (financial vs. tax) simultaneously, and a customization that only touches one book's calculation while leaving the other on stock logic is a common source of quiet drift between the books over a few fiscal years. If the ask is book-specific, confirm explicitly which books it applies to and verify the others are unaffected, rather than assuming a single code path covers all books.

Testing considerations

Run a custom depreciation method through a full asset lifecycle in a sandbox — capitalization, several periods of depreciation, a partial transfer, and a disposal — before shipping it. FA bugs are notorious for surfacing only in period three or four of depreciation, not period one, because the calculation carries state (net book value, accumulated depreciation) forward.

Wrapping up

Fixed Assets rewards patience: extend the depreciation method interface properly rather than patching after the fact, keep multi-book behavior explicit, and test across a full asset lifecycle rather than a single period. The module's small footprint hides how much downstream GL and tax reporting depends on it being right.