Setting Up a Chart of Accounts in Intuit Enterprise Suite

Last reviewed 2026-10-31

Most chart of accounts work happens in the first week of a new ledger, when nobody has run a report yet. The structure is set to get the opening balances in, and the books move on. Two years later a consolidation package will not tie, and the cause traces back to an account that was created in a hurry.

Intuit Enterprise Suite runs on the same accounting core as QuickBooks Online, so the account list behaves in the ways familiar to anyone who has built a QuickBooks file. What follows is how to set that list up so it survives reporting, imports, and the occasional restore from backup.

The account list is the spine of your reporting

Every figure on the profit and loss, the balance sheet, and the trial balance is a rollup of balances sitting in named accounts. If two accounts both hold "contract labour", the report shows two lines and a reader has to add them mentally. If a bank account is typed as an expense, it will never appear where you expect.

Treat the chart as a data model rather than a list of labels. The names, the types, and the parent relationships are all load-bearing. Get them right at the start and later work is mostly adding detail at the edges.

Decide the numbering before you type a single account

A numbering scheme is the cheapest control you will ever put in place. It gives the list a stable order, keeps related accounts adjacent, and makes gaps obvious when someone adds an account in the wrong block.

Pick ranges by statement section and leave room inside each range. A scheme with ten numbers between categories will run out during the first busy quarter, and the person patching it will start appending suffixes instead. If several entities will report together, agree on the ranges across all of them before any of them goes live. The same discipline shows up in ordinary chart of accounts design work, where a shared scheme is what makes consolidation possible at all.

The account type decides which report line it lands on

The type you choose at creation (bank, receivable, payable, income, cost of sales, expense, equity and so on) is what routes the account onto a report. Detail type refines the placement further.

Because of that, converting a wrongly typed account later is not cosmetic. Changing a type can move balances between sections and unsettle comparatives from earlier periods. Where an account was typed badly and has history, decide deliberately: either keep it and live with its position, or create a clean account, reclassify the transactions, and make the old one inactive.

Subaccounts carry detail, not totals

A subaccount rolls into its parent, and most reports will show the parent figure with the children available underneath. That makes subaccounts the right tool for splitting a balance without cluttering the face of the statements.

Keep the hierarchy shallow enough to read. Deep nesting is hard to scan on a printed report and harder to explain to anyone reviewing the numbers. If you find yourself three levels down, the detail probably belongs in a class or a location instead.

Renaming is safe; merging is not

Renaming an account keeps every transaction attached to it and simply changes the label. That is the correct fix for a typo or a vague name.

Merging is different. When two accounts are combined, the transactions move onto one account and the other disappears, and there is no undo. Do the merge deliberately, after exporting the list and after confirming that both accounts really mean the same thing. A merge performed to tidy a duplicate created by an import can quietly fold two genuinely separate cost centres together.

Inactive is not the same as deleted

An account holding transactions generally cannot be deleted, and it should not be. Making it inactive removes it from pick lists while leaving history and prior-period reports intact. Reserve deletion for accounts created by mistake and never used.

Review inactive accounts once a year. A long tail of dead accounts makes the picker harder to use and hides the accounts that actually matter.

Imports are where most charts go wrong

Spreadsheet imports and conversions into the suite are the usual source of duplicate accounts. Matching is typically by name, so "Travel" and "Travel " (with a trailing space) arrive as two accounts. The same happens with "Office Supplies" and "Office supplies" when the case differs.

Before importing, export the existing chart and reconcile the incoming list against it line by line. After importing, sort by name and scan for near matches. Then check that the balances landed where you intended, particularly for bank and receivable accounts.

After a restore, check the account structure first

A restore from backup, or a file recovered after a crash, can come back with accounts that look fine in the picker but behave oddly in reports. Start with three checks: sort the list by name for duplicates, confirm each account still has its expected type, and run a trial balance to see whether debits and credits still agree.

If the balance sheet will not balance after that review, the problem sits deeper than the account list, and our QuickBooks balance sheet out of balance repair covers what causes it and how it is corrected. Moving lists and history between two companies raises a separate set of matching problems, which we describe in the notes on moving lists and transactions between QuickBooks companies.

Export the chart and keep it with your backups

Export the full account list today, with names, types, and current balances, and store it alongside your company file backups. It takes a minute and it gives you a reference copy to reconcile against the next time an import, a merge, or a restore changes something it should not have. Repeat the export after any structural change, and keep the dated versions.