Acumatica GL Account Screen — A Deep Dive

Chart of Accounts (GL202500) defines the natural accounts every GLTran row ultimately posts against, maintained through AccountMaint over the Account DAC. It looks like one of the simplest master-data screens in the system, and mostly is — the complexity shows up not in the screen itself but in how deeply account structure is woven into every other module's posting logic.

Account type and account group

An account's type (Asset, Liability, Income, Expense, Equity) controls its normal balance and how it rolls up on financial statements. Account Group is a separate, parallel classification used specifically by Financial Reporting and, in Manufacturing/Distribution contexts, cost accounting — the two aren't the same thing, and a customization or report built against account type alone will miss whatever structure account groups were designed to provide.

Key tabs

• General — account number, description, type, and active status.
• Financial — account group assignment, consolidation settings for multi-branch/multi-company setups, and restriction group membership.

Extending AccountMaint

Restricting who can post to specific accounts beyond the standard restriction-group mechanism is a common ask — for example, a "manual journal entries only" flag that blocks the account from being selected on Sales Order or AP Bill GL-override lines while still allowing it from the Journal Transactions screen directly.

public class AccountExt : PXCacheExtension<Account>
{
    [PXDBBool]
    [PXUIField(DisplayName = "Manual Entries Only")]
    public virtual bool? UsrManualOnly { get; set; }
    public abstract class usrManualOnly : BqlField { }
}

Custom fields and tabs via the Customization Project Editor

Adding a field to General or Financial is a routine DAC extension. Because Account is referenced by nearly every module's posting logic, any new field intended to influence posting behavior (like the manual-only flag above) needs its enforcement added at each entry point that lets a user pick an account — the Journal Transaction screen, and any transaction screen with a GL-override line — not just on the Chart of Accounts screen itself.

Common validation and event-handler use cases

Beyond posting restrictions: enforcing a naming/numbering convention for new accounts beyond the segmented key structure alone, blocking deactivation of an account that still has a nonzero balance, and validating that an account's assigned Account Group doesn't conflict with its Account Type in ways that would break Financial Reporting rollups.

Gotchas

Accounts, once used in a posted transaction, can't be deleted — only deactivated — which is easy to forget when a customization script tries to clean up test/demo data. The segmented account key structure (if the company uses account/subaccount combinations, common in Acumatica) means account numbers aren't necessarily standalone — validation logic that only checks the account, ignoring subaccount segment restrictions, misses half of the actual posting rules most implementations rely on. And restructuring the segmented key itself (adding a new segment) is a substantial data migration, not a Chart of Accounts screen edit — it's easy to underestimate this if you've only ever worked with single-segment charts.

Wrapping up

Chart of Accounts is deceptively simple — its real weight comes from how many other screens reference an Account without going back through this one. Customizations that add posting rules here need to be enforced at the transaction screens themselves, not assumed to cascade automatically.