How to Design a Chart of Accounts (With SaaS and Ecommerce Examples)

The chart of accounts is the numbered list of every bucket a dollar can land in: each bank account, each revenue line, each expense category, each liability. Every transaction in the business gets coded to one of these buckets, and the buckets roll up into the profit and loss statement, the balance sheet, and the general ledger behind both.

It is structural, not cosmetic. A weak chart of accounts, too thin, too fragmented, or organized around how a bank labels transactions rather than how the business actually operates, produces financials that are technically correct and practically useless. An owner staring at a P&L that lumps every tool subscription, every contractor payment, and every one-off purchase into "Miscellaneous Expense" cannot answer basic questions: what is this business actually spending money on, is a specific cost trending up, would cutting a vendor move the numbers.

The chart of accounts is also what a lender, an investor, or a tax preparer sees first when they open the books. A clean, logically organized chart signals a business that knows its own numbers. A chart with 40 nearly identical expense accounts, half of them unused, signals the opposite, whether or not the underlying numbers are actually accurate.

Get this right once, ideally before the first transaction is ever coded, and the software mostly gets out of the way after that. Get it wrong, and every month of activity coded against a bad structure is a month that eventually has to be recoded, at real cost, before the books are usable for anything beyond "did we make money."

Most US accounting software, and most bookkeepers trained on US GAAP-adjacent conventions, follow a version of the same numbering band, even though nothing in the tax code or GAAP requires it:

• 1000-1999: Assets (cash, accounts receivable, inventory, fixed assets)
• 2000-2999: Liabilities (accounts payable, credit cards, loans, deferred revenue)
• 3000-3999: Equity (owner's capital, retained earnings, distributions)
• 4000-4999: Revenue (sales by line, service revenue, other income)
• 5000-5999: Cost of goods sold (direct product or service delivery cost)
• 6000-8999: Operating expenses (payroll, rent, software, marketing, professional fees)
• 9000-9999: Other income and expense (interest income, interest expense, gains and losses outside normal operations)

Within each band, leave gaps: 1010 for the primary checking account, 1020 for a second account, rather than 1010 and 1011, so a new account can slot in later without a renumber. Sub-bands work the same way inside expenses: 6100s for payroll-related costs, 6200s for occupancy, 6300s for software and tools, 6400s for marketing, so a new software vendor gets 6310 instead of forcing a resequence.

Neither QuickBooks Online nor Xero requires numbered accounts at all; both will run on account names alone. The numbering exists for the humans using the file, not the software. It makes a 60-account list scannable in the way an alphabetically sorted list never quite is, and it makes onboarding a new bookkeeper or accountant faster because the structure is one they have likely seen before.

There is no regulatory ceiling on account count, but there is a practical one: past roughly 100 to 150 accounts, most owners stop being able to look at their own P&L and understand it without help. A workable range for a small business, one entity, under a few million in revenue, is 40 to 80 accounts total across all five categories.

The instinct to add an account for every new vendor or every slightly different expense is the single most common cause of chart-of-accounts bloat. A new advertising platform does not need its own account if "Digital Advertising" already exists and can absorb it. A new one-off legal matter does not need its own account if "Legal and Professional Fees" already does the job.

The test that generally holds up: does this need its own line to make a real decision, or would a memo on the transaction do the same job. If the owner would genuinely act differently seeing "Facebook Ads: $4,200" versus "Digital Advertising: $4,200" broken out from a combined total, split it. If not, it is a memo, not an account.

The opposite failure, a chart that is too thin, shows up as an "Office Expenses" or "Miscellaneous" account that quietly becomes 20% of total spend because nobody wanted to build out the detail underneath it. Both failure modes point to the same fix: revenue and expense categories should mirror the actual decisions the business makes, not the defaults a software template shipped with.

The mistake that causes the worst chart-of-accounts bloat is trying to track a second dimension, department, product line, region, entity, by multiplying accounts instead of using the tagging feature built for exactly this.

QuickBooks Online offers Classes (for departments, funds, or business segments) and Locations (for physical sites or regions), available on Plus and Advanced plans. Xero offers Tracking Categories, up to two per organization (for example "Department" and "Region"), each with its own set of options. Both let a single transaction carry the account it belongs to (Advertising Expense) plus a tag (Department: Marketing, Location: Austin) without creating "Advertising Expense - Marketing" and "Advertising Expense - Sales" as two separate accounts.

This distinction matters because it is reversible in one direction and not the other. Adding a class or tracking category to an existing chart of accounts is close to free: turn it on, start tagging new transactions, backfill history if it matters. Un-splitting an account that was needlessly duplicated by department requires recoding every transaction that was ever posted to either version, or living with two accounts that should have been one forever.

A business with three product lines, two locations, or a services arm alongside a product arm should have one revenue account per genuinely distinct revenue type, then use classes or tracking categories to slice any of those by department, location, or team. The chart of accounts answers "what kind of money is this." Classes and tracking categories answer "whose money is this, and where." Keep the two jobs separate.

A seed-to-Series-A SaaS business on accrual accounting needs a chart of accounts built around subscription revenue mechanics, which look nothing like a typical services business:

• 4000 Subscription Revenue (recognized monthly as earned, not when the invoice is paid)
• 4010 Setup and Implementation Revenue (often recognized on a different schedule than the subscription itself)
• 4020 Usage-Based Revenue (for consumption or overage billing)
• 2300 Deferred Revenue (a liability: cash collected for subscription periods not yet delivered)
• 5000 Hosting and Infrastructure Costs (AWS, GCP, Azure, treated as cost of revenue, not a general operating expense)
• 5010 Third-Party API and Data Costs (per-seat or per-call vendor costs tied directly to delivering the product)
• 5020 Customer Support Payroll (allocated to COGS, not G&A, because support is part of delivering the subscription)
• 6100 Sales and Marketing Payroll, 6110 Paid Advertising, 6120 Content and SEO
• 6200 Research and Development Payroll, 6210 Contractor Engineering
• 6300 General and Administrative, split into payroll, software, legal, and insurance sub-accounts

The two structural choices that matter most here: deferred revenue as its own liability account, because a SaaS business collecting annual payments upfront is holding a real obligation, not revenue, until it is earned; and hosting or infrastructure costs classified as cost of revenue rather than a general "Software" operating expense, because gross margin, one of the first numbers an investor asks about, is meaningless if server costs are buried in G&A. A board deck built on a chart of accounts that miscategorizes either of these will show a materially wrong gross margin, which is exactly the number a Series A investor checks first.

An ecommerce business selling on Amazon, Shopify, or both needs a chart of accounts built around inventory and channel-level cost of goods sold, since margin varies meaningfully by channel:

• 4000 Product Sales - Shopify (DTC), 4010 Product Sales - Amazon, 4020 Product Sales - Wholesale
• 2200 Sales Tax Payable (collected on behalf of states, not revenue)
• 1200 Inventory (an asset until sold, not an expense on purchase)
• 5000 Cost of Goods Sold - Product Cost
• 5010 Freight and Landed Cost (inbound shipping, duties, and customs, added to the cost of the goods, not booked as a standalone expense)
• 5020 Amazon Fulfillment and Referral Fees (FBA, referral, and storage fees, classified as cost of revenue since they are a direct cost of the sale on that channel)
• 5030 Payment Processing Fees (Stripe, PayPal, Shopify Payments)
• 6100 Advertising - Amazon PPC, 6110 Advertising - Meta/Google
• 6200 Warehousing and 3PL Fees (if not already captured in landed cost)

A worked example on why the split matters: say a business sells a product for $40 on both Shopify and Amazon. On Shopify, cost of goods is $12, payment processing is $1.20, and shipping is $6, leaving a contribution margin of $20.80. On Amazon, the same $12 product cost applies, but Amazon referral and FBA fulfillment fees run roughly $14 on a $40 item, leaving a contribution margin of $14. Combine both channels into one "Cost of Goods Sold" account and the business sees a blended 60% margin that looks healthy. Split it by channel, using classes or separate revenue and COGS accounts per channel, and the same business sees that Amazon is 15 to 20 margin points worse per unit, information that should change ad spend allocation and pricing, and that a combined account hides completely.

Most chart-of-accounts problems that surface a year or two in trace back to a handful of setup mistakes:

• Copying a generic software template without editing it. QuickBooks Online and Xero both offer industry-specific starting templates, but every one of them ships with accounts a specific business will never use and misses ones it needs, so this is always a starting point, not a finished chart.
• Booking inventory purchases as an expense instead of an asset. Inventory is a balance sheet item until it is sold; expensing it on purchase overstates cost of goods sold in the purchase month and understates it in the month the item actually sells, distorting margin in both periods.
• Treating owner draws or loan proceeds as revenue or an expense. Both are balance sheet or equity movements, not P&L items, and miscoding either inflates or deflates taxable income on paper.
• Splitting one expense into department-specific duplicate accounts instead of using classes or tracking categories, the single largest source of unnecessary account-count growth.
• No sub-account structure inside broad categories like "Professional Fees" or "Software," so a category that starts small becomes an unreadable blend of legal, accounting, and consulting spend with no way to separate them after the fact.
• Changing the chart of accounts mid-year without a plan for historical data, leaving some months coded to the old structure and some to the new, which breaks any year-over-year comparison until someone recodes the earlier months to match.

Each of these is straightforward to avoid at setup and genuinely time-consuming to unwind once a year of transactions sits on top of it.

A chart of accounts that worked at $200,000 in revenue with one product line often stops working once the business adds a second revenue stream, crosses into multi-state sales tax, hires its first employees, or starts talking to investors who expect gross margin broken out by cost of revenue rather than buried in general expenses.

Signs a redesign is overdue: the P&L requires a mental translation exercise every time it is reviewed, one account (commonly "Miscellaneous" or "Other Expense") has grown to represent a meaningful share of total spend, a lender or investor request for financials by segment cannot be answered without manually re-sorting transactions, or a new business line was bolted onto the existing revenue accounts instead of getting its own.

A redesign does not have to mean starting over. The two-step approach that avoids breaking historical comparability: map every existing account to a new account under the revised structure, then decide whether to remap history (recode prior transactions to the new accounts, which keeps year-over-year comparisons clean but takes real bookkeeping time) or to draw a line at the start of a new fiscal year and only apply the new structure going forward (faster, but it means comparing last year's old-structure P&L to this year's new-structure P&L takes an extra translation step).

Either way, this is a project to scope deliberately, with a clear cutover date and a plan for the transactions on either side of it, not something to do piecemeal by adding and abandoning accounts over several months. A messy mid-year transition usually creates more confusion than the outdated chart it was meant to fix.