Chart of Accounts Best Practices

The COA has five standard top-level categories:

• Assets
• Liabilities
• Equity
• Revenue
• Expenses

The first three feed the balance sheet. The last two feed the income statement. Some structures break gains and losses into separate top-level categories, giving you seven total. Fine. Just know it changes what your reports can show, so decide that before you touch anything else.

Standard ordering follows financial statement sequence. Balance sheet accounts come first, then income statement accounts. Within each category, you subdivide. Under assets: cash, receivables, inventory. Under expenses: COGS and operating expenses each get their own block.

The conventional numbering runs like this:

• 1000s (Assets)
• 2000s (Liabilities)
• 3000s (Equity)
• 4000s (Revenue)
• 5000s (Cost of Goods Sold)
• 6000s (Operating Expenses)

First digit tells you account type. Everything after specifies subcategory and individual account. In a five-digit system, account 10010 is "Cash in Checking." The "1" means asset. "00" means current asset. "10" is the specific account.

GAAP doesn't care what numbering format you use. That's your call. What it does care about is proper classification and consistent presentation. The numbering is for your team. Make it clear enough that a new hire can follow it without calling someone for help.

This is the skeleton. Everything that follows is about how well or poorly you build it out.

Getting the Number of Accounts Right: Enough Detail to Be Useful, Few Enough to Stay Readable

Most small to mid-sized businesses run fine with 40 to 80 accounts. Fewer than 20 usually means the structure is too vague to do anything useful. More than 150 almost always means you went too far — like a restaurant menu so long that ordering becomes a part-time job.

Here's something that catches people off guard. When you first log into QuickBooks Online, it hands you 70 to 80 default accounts. Most small businesses actually need 30 to 40. That gap between what the software gives you and what your business needs is exactly where early clutter starts. People accept the defaults because the list looks official. A year later they've got accounts nobody touches and categories that don't map to anything real in the business.

The problems live at both ends.

Too few accounts. Categories collapse in ways that hide what you need. A single "Revenue" line blending three product lines tells you nothing useful. You can't manage what you can't see separately.

Too many accounts. Coding slows down and gets inconsistent because nobody's sure which of six nearly identical accounts to pick. Reports get harder to read. Eventually no single person fully understands the chart, and that's when the spreadsheet workarounds start appearing outside the accounting system entirely.

One thing worth pushing back on: the "keep it short" advice can backfire when it leads to collapsing genuinely different account types. Under IFRS and US GAAP, how you classify a transaction matters for compliance. A long list is acceptable; accounts that mash unrelated things together just to keep the count down are the real problem.

A practical test. Does this account get used regularly, and does it show up on a report someone actually reads? If the answer to either question is no, it probably shouldn't exist as its own account.

Same logic applies to sub-accounts. If a sub-account rarely has any activity, fold it into the parent. Deep nesting creates maintenance work without adding anything back.

The Structural Decisions That Most Directly Shape What Reports Can Show

Start with the reports, not the transactions.

Before you build or restructure a COA, ask what the income statement needs to show. Ask what the business is actually trying to manage. If the expense groupings don't help anyone make a decision, the COA is wrong. The report isn't the place to fix it.

Separate COGS from operating expenses.

This is often the single most valuable fix for any business that sells a product or uses subcontractors.

• COGS. Costs that exist only because revenue exists. Subcontractor fees, direct materials, payment processing fees tied to sales.
• Operating expenses. Overhead that runs whether or not revenue comes in. Rent, salaries, software subscriptions, utilities.

Mix those two and your gross margin line means nothing. Once gross margin means nothing, every profitability conversation is a guess with a spreadsheet attached — you're essentially trying to navigate by a map drawn in fog.

Organize expenses by function, not by vendor.

One "Office Supplies" account. Separate accounts for Staples, Amazon Business, and the local print shop break category-level analysis. You want to know what you spend on office supplies total, not which vendor processed the card that week.

Reflect tax categories in your expense structure.

A single "Marketing" catch-all mixes meals (50% deductible), advertising (fully deductible), and entertainment (not deductible). Blending those creates extra work at tax time and raises the odds of missed deductions. The COA is the right place to draw that line, before the tax return is filed after the year is already closed.

Each of these decisions is invisible day to day. But each one either surfaces the right information or buries it every single time someone runs a report.

Naming Conventions and Account Descriptions as Operational Infrastructure

Naming inconsistency is a slow, compounding problem. When the marketing team codes something to "Facebook Ads" and finance codes the same type of spend to "Paid Advertising," that spending splits across two accounts. Category totals become unreliable. Nobody notices for months. Then someone tries to reconcile the numbers and the whole thing falls apart at once.

Before any accounts get created, settle on a naming format:

• Singular vs. plural ("Utility Expense" vs. "Utilities")
• Capitalization style
• Whether account names include a verb

Pick one approach and apply it everywhere, every account, no exceptions.

Every account should carry a description. One or two lines defining what belongs in it and, just as importantly, what doesn't. A practical move: export your COA to a spreadsheet, add a column for the account definition, add another with real transaction examples. Anyone coding has a shared reference. This matters especially when you're bringing on new finance staff who weren't around when the structure was built.

Gap discipline in your numbering matters too. If your current assets run from 10010 to 10050, don't fill the sequence so tightly that the next logical account has to go at 10051. Leave room to insert accounts in the right place later without breaking the logic of the whole sequence.

Write the coding rules down. Train everyone who touches the system on them. Naming decisions made at setup erode fast when nobody's actively holding the line. The COA is a shared language, and when that language is clear, coding is faster, audit trails are cleaner, and getting a new hire up to speed takes days instead of weeks.

Common Ways a COA Degrades Over Time: And Exactly How Each One Happens

Most COA problems aren't design failures at launch. They're accumulation failures. The structure starts reasonable and slowly becomes something nobody fully trusts.

The default-acceptance trap. Someone sets up QuickBooks or NetSuite, accepts whatever the software installs, and never adjusts it for the actual business. The starting structure is generic by design. It's often wrong for the specific company from day one. But it looks official, so it stays.

Account proliferation. Finance creates a new account to handle a one-off reporting request. Then again. Then again. Over time the chart becomes a patchwork of overlapping, near-identical line items. "Travel Expenses," "Employee Travel," "T&E," "Travel and Entertainment." All four exist. Nobody knows which one to use, so people pick at random and the data becomes meaningless. You could call it death by a thousand line items.

Vendor creep. An account gets created for a specific vendor, project, or transaction that should have been a tag or a class — a permanent account is the wrong tool. These stick around long after the project ends or the vendor relationship changes because nobody ever goes back to clean them up.

The "one more subcategory" problem. Each nesting decision looked fine on its own. The result across three years is a hierarchy too deep to read on any standard report. Nobody planned it that way. It just kept going.

Compliance-driven additions that never get cleaned up. ASC 842, for example, forced companies to add right-of-use assets and lease liabilities to their books. Without someone watching the COA, those additions sit as structural oddities long after they've served their purpose. The FASB issued 11 accounting standards updates in 2025, matching the highest recent annual pace. The pressure to add new account structures for compliance isn't a one-time event.

The end result: inconsistent reporting, spreadsheet workarounds living outside the accounting system, and a COA that no single person can fully explain.

Governance Practices That Keep the COA From Drifting

The COA needs an owner. One person on the finance team is accountable for its integrity. Someone watching it month to month, well before the auditors arrive at year-end.

Set up a formal approval process for new account requests. A standard form, a named approver, a documented reason. No accounts created on the fly because someone asked for a new line item in a budget meeting. That's how you get four "Travel" accounts.

Review the full COA at least once a year. Three questions worth asking:

• Are there accounts with no activity?
• Are there accounts that duplicate each other?
• Are there accounts whose original purpose no longer exists?

Delete or deactivate unused accounts at year-end only, not mid-period. Pulling an account mid-year breaks reporting continuity and creates period-over-period comparison problems that are genuinely hard to explain to someone who wasn't there when the change happened.

When accounts are added, renamed, or retired, update every downstream thing that references them. Reporting templates, dashboards, budgets, consolidations. The account doesn't live in isolation.

Treat any change to an account with real transaction history carefully. The history doesn't update retroactively. Renaming an account mid-year can make your period comparisons look wrong even when the underlying numbers are completely fine. That sends people on a long search for a problem that doesn't actually exist, which is a terrible way to spend an afternoon.

The governance layer is what separates a COA that stays useful from one that quietly becomes an obstacle.

Designing for Growth: Keeping the COA Extensible as the Business Adds Entities, Products, or Geographies

The most common growth-related COA failure is a structure built for one entity, one currency, one product line that gets stretched to cover three entities and two geographies without being redesigned. The result is inconsistent consolidation and reports that need manual reconciliation every single period, indefinitely, until someone finally rebuilds the whole thing.

Leave numbered gaps by design. Deliberate spacing in your numbering sequence means new accounts can go in the right logical place without disturbing what's already there. It sounds like a minor detail. It saves real hours under deadline pressure.

Know what belongs in the COA versus what belongs in dimensions, classes, or tags.

Department-level expense tracking, project codes, and location splits are often better handled as reporting dimensions than as separate accounts. Adding a new department as a dimension is a configuration change, maybe ten minutes. Adding it as a new block of accounts is a structural change with consequences across every report, template, and consolidation that touches those accounts. Those are very different problems to solve.

This keeps the COA structure stable while still giving you granular reporting. The structure doesn't have to grow every time the business does.

Multi-entity growth introduces consolidation requirements. Accounts that don't share a consistent structure across entities create manual reconciliation work and make clean consolidated statements much harder to produce. If you know you'll have three entities, design for three entities now, before 18 months of history accumulate across a structure that wasn't built for it.

Build a couple of stages ahead. A company that knows it will add a services line alongside its product revenue should separate those two in the COA before services revenue actually starts flowing, rather than waiting until it's been lumped into a single revenue line and someone has to untangle the history. Untangling history is miserable, time-consuming work, and it's entirely avoidable if you think ahead by even one step.

A COA that was never designed to scale is rarely worth patching forever. At some point the cost of working around a broken structure exceeds the cost of rebuilding it. Better to design it right early, or at least rebuild it before it becomes a genuine emergency.