Most people setting up a chart of accounts treat the numbers as filing labels. Pick something, keep it tidy, move on. Then two years later the chart has 40 accounts wedged into a range built for 10, the P&L sorts in an order nobody intended, and adding a second location means either renumbering everything or living with a mess.
The numbers are doing two jobs, and both of them are structural. They set the order every report prints in, and they define ranges that reports roll up. Get the ranges right at the start and the chart absorbs a decade of growth. Get them wrong and every fix is a migration.
This is about how to choose that structure. It is not tax or accounting advice, and the judgment calls at the end belong to your accountant.
The numbers are a sort key and a namespace
Accounting systems sort accounts by code, not by name. That single fact explains most of what follows. Your profit and loss statement prints in account-number order, so the number is what puts revenue above cost of sales and cost of sales above labor. Rename an account and nothing moves. Renumber it and it jumps.
The second job is grouping. Reports, budgets, and integrations refer to ranges. "Everything from 5000 to 5999" is cost of sales. That range is a namespace, and the useful question when you add an account is not "what should I call this" but "which range does it belong in, and is there room."
The conventional ranges, and why they are only a convention
Most small-business charts follow a layout that looks like this:
Balance sheet accounts first, income statement accounts after, in the order the statements themselves are read.
Worth being clear about what this is: a widely used convention, not a rule handed down by GAAP. US GAAP prescribes how transactions are recognized, measured, and presented. It does not prescribe account numbers, and there is no numbering scheme you can be out of compliance with. Certain regulated and government contexts do impose prescribed structures, but an ordinary restaurant, bar, or hotel is free to number its chart however it likes.
Which means the real constraint is internal consistency, not conformity.
The counter-example worth knowing
Our restaurant chart of accounts starts revenue at 4000, exactly as the table above suggests, because it follows USAR, the Uniform System of Accounts for Restaurants. Sales in the 4000s, cost of sales in the 5000s, labor in the 6000s, operating expenses in the 7000s.
Our hotel chart of accounts starts operating revenue at 1000.
That is not an error. USALI, the standard for lodging, organizes the income statement by department rather than by account category, and the template numbers the departments in the order they are reported. Operating revenue is 1000. The rooms department's expenses are 2000. Food and beverage expenses are 3000. Each undistributed department gets its own block after that.
Two charts in the same product, both defensible, numbered on completely different principles, because the reports they have to produce are different. The lesson is that the ranges follow the statement you need to read, and once you pick them, you stop moving them.
Mirror the cost block against the revenue block
This is the highest-value trick in the whole exercise, and it is the one most default charts miss.
In the restaurant template the last three digits are deliberately parallel across revenue and cost:
Change the leading digit and you move between the sales account and the cost account for the same category. Nothing else changes.
That buys you three things. Margin by category becomes a subtraction between two accounts whose codes differ by exactly 1000, so a wine margin report is trivial to build and trivial to audit. Miscoding becomes visible, because liquor cost landing in 5400 while liquor sales sit in 4300 shows up as a beer margin that makes no sense. And when you add a category later, you add it in both blocks at once: a new 4600 seltzer sales line tells you a 5600 seltzer cost line is missing.
A chart where revenue and cost are numbered independently can still balance. It just cannot tell you which category made money.
Charts that grow organically almost never have this property, because the revenue accounts get created when someone sets up the POS and the cost accounts get created months later when someone is coding invoices.
Leave gaps, and leave them where growth actually happens
Look closely at the restaurant revenue block and you will notice 4500 Wine Sales is followed by 4700 Catering and Banquet Revenue. There is no 4600. In cost of sales, 5500 Wine Cost is followed by 5700 Paper and Packaging Cost. There is no 5600.
Those holes are deliberate. They are the room a new beverage category moves into without disturbing the parallel structure.
The general discipline:
- Number top-level headings in thousands. 4000, 5000, 6000.
- Number their children in hundreds. 4100, 4200, 4300. That leaves 99 slots between any two.
- Number the third level in tens. Food cost splits into 5110 Meat, 5120 Seafood, 5130 Poultry, 5140 Produce, 5150 Bakery, 5160 Dairy, 5170 Grocery and Dry Goods. The gaps between them leave 5111 through 5119 available if a kitchen ever needs to separate premium cuts from standard.
- Skip a slot wherever you can see growth coming. Beverage categories change. Delivery channels multiply. Leave those ranges loose and tighten the ones that never move, like utilities.
Gaps cost nothing. A chart is not graded on density.
Digit width: four is usually right, five is a commitment
Four digits gives you 1000 codes per major range, which is far more than a single-site operator will use. Five digits is the right call when you genuinely need a segment inside the code, and the wrong call when you are using it to solve a problem the accounting system already solves.
Which brings us to the most expensive numbering mistake in multi-unit hospitality.
Location is a dimension, not an account. Every serious accounting system has a separate field for it: classes and locations in QuickBooks Online, tracking categories in Xero, dimensions in NetSuite and Sage. One 5110 Meat account, tagged by site, gives you per-site food cost and consolidated food cost from the same data, with no duplication and nothing to reconcile.
The same logic applies to departments in a hotel. USALI puts the department in the account structure because the department is the reporting unit and the statement is organized around it. A restaurant group's locations are not that. They are the same business repeated, and repetition belongs in a dimension.
Reserve extra digits for cases where the segment genuinely changes what the account means, not for cases where it changes only whose number it is.
Three levels of depth, and post only to the leaves
The templates go three levels deep and stop. Revenue, then Liquor Sales, then nothing further. Cost of sales, then Food Cost, then Meat.
Three levels is enough to produce a readable P&L with meaningful subtotals. A fourth level tends to appear when someone is trying to track something that is really a vendor, an item, or a project, and those belong in the transaction detail rather than the chart. A chart of accounts with 400 accounts is not more precise than one with 90. It is just harder to code invoices against, and coding accuracy is what actually determines whether the numbers mean anything.
The related rule: parent accounts are for rolling up, not for posting. If transactions land on both 5100 Food Cost and its children 5110 through 5170, your subtotal double-counts in some reports and hides orphaned transactions in others. Post to the leaf. Let the parent do arithmetic.
Renumbering is a migration, so try to do it once
Account codes leak into more places than people expect. Historical comparisons and memorized reports reference them. Bank feed rules and recurring transactions point at them. Budgets are built on them. Any integration that posts to your ledger, including AP and payroll systems, maps to them. Some systems will not let you reuse a retired code at all.
None of that makes renumbering impossible. It makes it a project rather than an afternoon. If you are going to do it:
- Do it at a period boundary, ideally the start of a fiscal year, so comparatives break in one predictable place.
- Export the full existing chart with balances first, as a reference you can reconcile against.
- Write the old-code-to-new-code mapping down before touching the system, and keep it.
- Check every integration that posts to the ledger, since AP, payroll, and POS systems may map by code.
- Rebuild bank rules and recurring transactions. These fail quietly rather than loudly.
- Re-point budgets and any saved or memorized reports.
- Confirm the prior-year comparison still runs before you close the first period on the new codes.
If the existing chart is merely untidy rather than structurally wrong, the cheaper move is usually to leave the codes alone, make the accounts you no longer want inactive, and impose the new discipline on everything added from here.
Descriptions are part of the numbering system
A number tells you where an account sorts. It does not tell the person coding a delivery invoice whether ice belongs in liquor cost or in kitchen supplies.
Every account in our templates carries a plain-English note for exactly that reason. 5320 Bar Consumables reads "mixers, garnish, bitters, syrups and ice consumed in drink production." 5420 Draft Beer reads "kegs and keg deposits." Those sentences are what make the structure survive a staffing change, because the structure only holds if the next bookkeeper codes the way the last one did.
A well-numbered chart with no descriptions degrades into an arbitrary one within about two turnovers of whoever does the books. This is the part teams skip, and it is the part that decides whether the chart still means anything in year three.
Applying it
The six chart of accounts templates are numbered on the principles above: thousands for headings, hundreds for children, tens for detail, gaps where categories grow, revenue and cost mirrored across blocks, three levels deep, and a description on every account. They download as CSV or Excel with no email required.
Structure is the easy half. The recurring work is coding every vendor invoice into it correctly, week after week, which is where the granularity either becomes real or quietly stops being true. That argument, with sources, is in why your restaurant P&L is lying to you. The classification questions that come up while you are coding, particularly what belongs in cost of sales versus operating expenses, are covered in COGS vs operating expenses.
