Chart of Accounts and Accounting Dimensions
Every transaction in ERPNext posts to an account. An account is the default accounting dimension: the primary axis on which the General Ledger is organized, and the field that is always required on every journal entry. All other dimensions (Cost Center, Project, and any custom dimensions) are supplemental. The Chart of Accounts (CoA) is the hierarchical list of all accounts available to a company; it defines the structure of every financial report the company produces.
Each account belongs to exactly one company and, with limited exceptions covered in the Multi-Currency Accounting article, is denominated in that company's base currency. Accounts are organized as a tree of groups and ledgers. Groups contain other groups or ledgers; ledgers are the leaf nodes where transactions actually post. An account of type Group cannot receive journal entries directly.
Default and Imported Charts of Accounts
ERPNext ships with preconfigured charts of accounts for many countries, installable at company setup. These are adequate for experimentation and light use. Most organizations migrating from another system will import their existing CoA to preserve account numbers, hierarchy, and reporting conventions. The import uses a spreadsheet template exported from ERPNext; after import, the system reconstructs the tree from the specified parent-child relationships.
Account numbering is strongly recommended. A consistent numbering scheme enforces ordering in reports, makes the hierarchy self-documenting, and speeds up data entry for users who know the CoA by number. ERPNext embeds the number in the account name automatically when an account number is assigned or updated.
Structural Limitations
ERPNext organizes all accounts under five root types: Asset, Liability, Equity, Income, and Expense. These correspond to the fundamental accounting equation. IFRS-compliant charts of accounts commonly add two further root categories, Other Income and Other Expense, to separate ordinary operating results from non-operating items. ERPNext does not support these as distinct root types. Organizations following IFRS typically accommodate this by using account numbering (for example, a 6xxx series for Other Income and a 7xxx series for Other Expense) to distinguish the classification within the Income and Expense roots, and by building custom financial statement templates that present them separately.
Account Configuration
When creating or editing an account, several fields affect how ERPNext treats it beyond simple categorization.
Is Group determines whether the account can receive transactions. Only leaf (non-group) accounts can be posted to. Group accounts exist solely to organize the tree and roll up balances for reporting.
Currency defaults to the company's base currency. Accounts denominated in a foreign currency are used for transactions with overseas parties and are covered in the Multi-Currency Accounting article.
Account Type controls which transactions the account is available in and what system behaviors it participates in. ERPNext filters account selection lists by context: a Tax type account only appears in Taxes and Charges templates, a Bank type account only appears in payment and banking fields. Setting the wrong type, or leaving it blank, is a common configuration error that causes accounts to disappear from the fields where they should appear, or to behave incorrectly in reports. The table below describes each type and its primary use.
| Account Type | Root | When to Use |
|---|---|---|
| Receivable | Asset | Party accounts for customers. Drives Payment Ledger entries, aging reports, and reconciliation. Every company must have at least one. |
| Payable | Liability | Party accounts for suppliers. Same downstream effects as Receivable on the payables side. |
| Bank | Asset | Checking, savings, and other bank accounts. Required for Payment Entry and bank reconciliation. At least one Bank-type group account must exist. |
| Cash | Asset | Petty cash and cash-on-hand accounts. At least one Cash-type group account must exist. |
| Tax | Liability / Asset | Sales tax payable, input VAT, use tax payable. Required for use in Taxes and Charges templates. |
| Fixed Asset | Asset | Long-lived assets subject to depreciation. Required for the Asset module to function. |
| Accumulated Depreciation | Asset (contra) | Offsets the Fixed Asset account on the balance sheet. |
| Depreciation | Expense | Periodic depreciation expense posted by the Asset module. |
| Capital Work in Progress | Asset | Costs accumulating on an asset under construction, before it is placed in service. |
| Cost of Goods Sold | Expense | The expense account debited when inventory is sold via Delivery Note or Sales Invoice with stock update. |
| Stock | Asset | The group account under which warehouse accounts are created for perpetual inventory. |
| Stock Received But Not Billed | Liability | Temporary clearing account for the gap between Purchase Receipt and Purchase Invoice. |
| Asset Received But Not Billed | Liability | Same clearing pattern for fixed assets received but not yet invoiced. |
| Stock Adjustment | Expense | Used for stock reconciliation entries and inventory write-offs. |
| Expenses Included in Valuation | Expense | Landed costs and other charges that affect item valuation in perpetual inventory. |
| Expenses Included in Asset Valuation | Expense | Same pattern for fixed asset landed costs. |
| Income Account | Income | Standard revenue accounts. No special system behavior beyond reporting. |
| Equity | Equity | Owner contributions, retained earnings, share capital. |
| Chargeable | Expense | Accounts for additional charges on items (freight, forwarding). Available in Taxes and Charges templates as a non-tax charge. |
| Round Off | Expense / Income | Captures rounding differences on invoice totals. |
| Temporary | Any | Used during mid-year migrations to balance opening entries. Should have a zero balance in steady state. |
Multi-Company Environments
In environments with multiple legal entities, each company can maintain its own CoA or inherit from another company's CoA. When a company inherits another's CoA, that company's structure becomes the template; new accounts can only be added to the master, and the inheriting company receives them automatically. This enforces consistency across subsidiaries and prevents account drift over time. The inheritance is configured at the point of creating the new company. The accounting treatment for transactions between related entities, including intercompany invoices, eliminations, and notes payable and receivable, is covered in the Intercompany Transactions article.
Accounting Dimensions
Dimensional accounting classifies transactions along additional axes beyond the account itself, without creating new accounts for every combination of interest. Rather than maintaining separate revenue accounts for each branch or each department, a single Revenue account can be tagged with a Branch dimension and a Department dimension, and reports can then slice the data along either axis independently.
ERPNext includes Cost Center and Project as built-in dimensions. Cost Center is designed for tracking profitability by operational unit: a production line, a store location, a service territory. Project is designed for tracking revenue and costs against a specific deliverable or engagement. Both appear on most transaction forms and can be filtered in financial reports including the General Ledger, Profit and Loss Statement, and Balance Sheet.
Custom dimensions can be added by specifying any ERPNext DocType as the reference. A dimension based on the Department DocType, for example, adds a Department field to transaction forms; a dimension based on a custom Branch DocType adds a Branch field. Common custom dimensions include:
- Branch or Location — for multi-site organizations tracking P&L per physical location
- Division or Business Unit — for organizations with distinct operating segments that share a legal entity
- Grant or Fund — for nonprofits and government entities tracking expenditure against specific funding sources
- Sales Region or Territory — for organizations reporting revenue by geography
Each dimension can be configured as mandatory globally or per company, and company-specific default values can be set so that routine transactions are tagged automatically. Mandatory enforcement can be scoped further: a dimension can be required only on Profit and Loss accounts (Income and Expense), only on Balance Sheet accounts (Asset, Liability, Equity), or both. This allows, for example, a Department dimension that is mandatory on expense postings but optional on balance sheet movements.
Dimensions can be disabled when they are no longer needed. Disabling removes the field from new transaction forms but preserves all historical tags on existing entries, so reports filtered by that dimension continue to return accurate historical data.
Design Considerations
Every additional dimension introduced creates an independent data entry burden. A user completing a Purchase Invoice must correctly tag every line with the right Cost Center, Project, Department, and Branch; if any are mandatory, the transaction cannot submit without them. Dimensions that are inconsistently applied produce reports that are worse than no segmentation at all, because the untagged transactions create an unexplained remainder.
Before adding a dimension, the design question is whether the reporting need can be met by the CoA instead. If the organization has three revenue streams that always map cleanly to distinct account ranges, separate accounts are simpler and require no additional tagging discipline. Dimensions are the right tool when the classification crosses account lines (when the same expense account needs to be split across departments, or the same revenue account needs to be attributed to different locations) and when the team can be relied upon to apply the tags consistently.
Accounting Dimension Filters
Dimension Filters add validation rules that restrict which dimension values are permitted for specific accounts. An administrator can configure a filter that allows only certain Cost Centers to be used with a given expense account, or makes a particular dimension mandatory on all postings to a specific revenue account. This is the mechanism for enforcing tagging discipline programmatically rather than through training alone. When a transaction violates a filter, whether by using a restricted value or by omitting a mandatory dimension, ERPNext blocks submission and reports the specific validation failure.