Skip to main content
Your chart of accounts defines every GL account available for posting in DualEntry. A well-structured chart keeps reporting clean, integrations predictable, and multi-entity consolidation straightforward. For the steps to create, structure, merge, or renumber accounts, see How to Create and Manage Chart of Accounts.

Plan your numbering scheme

DualEntry assigns account numbers within a fixed range per account type, and new accounts auto-populate the next available number in that range. The default account-number length is four digits, but that isn’t a fixed limit. You can extend it up to 10 digits in Settings → Organization, and any existing ranges automatically scale to match, existing account numbers included. DualEntry proposes a rescaled number for each account and shows you the before-and-after for review before you confirm. Because that rewrites every existing account number, decide on a length during initial setup rather than after your organization is live. The table below shows both ends of that range: Any length from 4 to 10 digits scales the ranges the same way, not just the two extremes shown above: a 6-digit configuration yields 100000–199999 for assets, 200000–299999 for liabilities, and so on. Every account type gets one fixed range, and every account number is a plain integer inside it. A child account shares its parent’s account_type, so it also shares the parent’s range. For example, a child of an other income parent takes an 8-series number, matching its parent, even if you’d rather see it grouped under 4-series revenue on reports. Plan your parent/child grouping with the ranges in mind before you start creating accounts. Leave gaps between accounts within each range so you can insert new accounts without renumbering. If you operate multiple entities, use classifications to tag entries by entity rather than encoding the entity into the account number. DualEntry shares a single chart of accounts across companies. Before finalizing the scheme, map it against your reporting requirements: your financial statement groupings rely on the account’s account_type, so a consistent scheme within each range speeds up the setup of those groupings. If you’re migrating from QuickBooks, Xero, or another system, an imported account keeps its source number only if that number already falls inside the correct range for its account type. Otherwise, the import assigns it a new number in that range. See Migrating from QuickBooks or Xero.

Statistical accounts

Statistical accounts track non-financial quantities, such as headcount, square footage, or machine hours, alongside your chart of accounts. They record non-monetary values without posting to the General Ledger or appearing on financial statements. See How to Set Up Statistical Accounts for setup steps.

Account fields

Every account carries the following fields:
The account form does not change an account number once transactions have posted to it, and the public API does not support updating accounts at all. Use the Account Renumbers bulk import instead, which renumbers the account in place and keeps its history. See Renumber an account.

Parent-child hierarchy

DualEntry supports a nested hierarchy within the chart of accounts, up to five levels deep: parent accounts group related child accounts (also called sub-accounts) under a roll-up, and a child account can itself be the parent of further children. Use this when you want detail for day-to-day posting but a single line on financial statements.
  • Parent account: postable, so a user can post a transaction directly to a parent account. That posting is the parent’s own independent balance; it does not merge with the children’s balances. A separate subtotal line then adds the parent together with its children. Parents must share the same account type and normal balance direction as their children (for example, an Expense parent can only have Expense children).
  • Child account: a postable account that reports its balance both on its own and as part of the subtotal with its parent.
If you don’t want users posting directly to a parent (or any) account, deactivate it. A deactivated account can no longer be selected when posting a new transaction, but it keeps its place in the hierarchy, and its children still roll up to it on reports. If you deactivate an account that already has posted transactions, reports continue to include it while the account stays unavailable for new transactions. For example, you might create a parent expense account 6000 - Marketing with children 6010 - Paid Advertising, 6020 - Events, and 6030 - Content. Your team codes invoices to the child accounts, and the P&L can display either the full detail or just the 6000 - Marketing roll-up depending on the report’s grouping level. See Create a child account to build a hierarchy like this.

How deep the hierarchy can go

A chain of accounts can be up to five levels deep, counting the top-level parent and the deepest child. A child account can be selected as the parent of another account, so 6000 - Marketing can hold 6010 - Paid Advertising, which can in turn hold 6011 - Paid Search, and so on to the fifth level. DualEntry rejects any save that would push a branch past five levels with the message Max nesting of accounts is 5. The check runs against the whole branch rather than just the account you are editing. The limit applies to the branch, not to the account. Adding a parent above an existing five-level group counts the levels below it as well, so a re-parent that looks like a single change can fail because of depth further down the tree. Deep hierarchies also make reporting harder to read, because every level adds a subtotal row. Most organizations get what they need from two or three levels and use classifications for the remaining detail rather than nesting further.

Change accounts after transactions have posted

Once an account carries posted entries, DualEntry allows some changes and blocks others. The table below summarizes each change and where you make it. Account type is constrained by hierarchy as well as by posted activity: every account in a parent-child group must share one type. To re-type a parent, re-type it and all of its children in the same operation, or DualEntry rejects the change. If you need to restructure more than the number, see Merge two accounts or Renumber an account.

Align accounts with items, banking, and 1099

Certain DualEntry features depend on specific account mappings. Setting these up correctly before you go live prevents misclassified transactions that require reclassification later.
  • Items: each product or service item links to an income account and optionally a COGS account. When you create invoices or bills referencing items, DualEntry posts to these accounts automatically.
  • Bank connections: each connected bank account maps to a GL asset account. See Bank Connections for setup.
  • 1099 tracking: vendor payments that qualify for 1099 reporting post to expense accounts flagged as 1099-eligible. See 1099 Tracking to configure which accounts are included.
Review these mappings during initial setup and again when you add new bank connections, items, or vendor payment workflows. Catching misalignments before a close period saves time compared to running bulk reclassification after the fact. If you change an item’s income or COGS account, the change applies to future transactions only; existing posted entries retain their original account.

Retained Earnings (system) account

DualEntry provides a system account, Retained Earnings (system) (default number 3900, which can be renumbered like any other account), that posts directly into the system-calculated retained earnings balance shown on the Balance Sheet and Trial Balance. This account can only be posted to via a manual journal entry. It isn’t selectable on other transaction types, such as bills, invoices, or expenses. You can merge existing user-generated Retained Earnings accounts into it, see Merge two accounts. For why DualEntry computes retained earnings this way instead of posting a closing entry, see Retained earnings and year-end close.

Retrieve and create accounts via the API

Use the following endpoints to manage accounts programmatically: The list endpoint supports filtering by account_types, number, and company_id. Use it to pull a specific subset (for example, all expense accounts for a single entity) when building reports or integration logic. The public API reads and creates accounts but does not update them, so editing an existing account happens on the account form in the app. To renumber an account that already has activity, use the Account Renumbers bulk import described in Renumber an account. You can delete an account only if it has zero posted transactions. Archive inactive accounts instead: archiving hides them from dropdowns while preserving historical data.

Where to go next

Last modified on September 22, 2026