A Standardized Restaurant Chart of Accounts — And How to Automate It

Every report your restaurant will ever produce — weekly P&L, prime-cost variance, year-end return, the spreadsheet you email a potential buyer three years from now — sits on top of a chart of accounts. If that skeleton is a tangled mess of 140 half-used custom accounts bolted on over six bookkeepers, everything built on top of it is unreliable. If it is a disciplined, restaurant-standardized baseline, every downstream report basically writes itself. This is the technical reference we hand to operators who ask why ALCIDAS restaurants all run on the same chart of accounts, and what it takes to migrate. It is a companion to the restaurant AI bookkeeping guide, which teases this topic but does not go deep.

Why Chart of Accounts Matters More Than You Think

Your COA is the skeleton of every financial report you will ever produce. Every line of sales, every dollar of food cost, every payroll run, every Mercury or Chase transaction posts to an account in it. Get the skeleton wrong and everything built on top of it is deformed. You can have perfectly reconciled bank feeds, a flawlessly wired POS integration, and pristine invoice OCR, and still produce a P&L that is useless because your food-cost bucket lumps dairy with produce with proteins and you cannot see which one just jumped.

If your COA is custom — built around whatever vocabulary your first bookkeeper happened to use — you lose two things. First, you cannot benchmark across your own future locations if you grow. Second, you cannot benchmark against any industry norm; the National Restaurant Association and the Uniform System of Accounts for the Restaurant Industry (USAR) publish peer data organized around a standard framework. And every hour your CPA spends at year-end mapping custom accounts back to a standard filing category is an hour you are paying for at CPA rates — typically $150 to $350 an hour in the US. Bad COA equals expensive accounting, always.

The 68-Account Baseline (Abbreviated)

The ALCIDAS baseline is 68 active accounts in the standard five-digit structure. We won't enumerate all 68 — that is a spreadsheet, not a paragraph. What matters is the logic, because the logic tells you whether a new account belongs.

• Assets (1000s). Operating bank, savings, merchant clearing, deposits held, inventory split by food / beverage / paper, fixed assets, accumulated depreciation.
• Liabilities (2000s). Credit cards, sales tax payable, tips payable, payroll liabilities, notes payable. Tips and sales tax get their own accounts because both are money that is not yours and needs to be visible.
• Equity (3000s). Owner contribution, owner distribution, retained earnings. Short on purpose.
• Revenue (4000s). Food, beverage, merchandise, delivery-platform sales booked net of platform fees, catering, gift card redemption, other income. Breaking delivery-platform out is non-negotiable if you ever want to answer "does DoorDash actually make us money after their cut?"
• COGS (5000s). Food split into meat / dairy / produce / dry goods / specialty. Beverage split into beer / wine / liquor / non-alc. Paper as its own line. This is the granularity that catches the cheese price spike in week one instead of at year-end.
• Operating Expenses (6000s). Labor (6100-6199: wages, overtime, tips paid out, benefits, payroll tax, workers comp). Occupancy (6200s: rent, utilities, R&M). Marketing (6300s). Admin (6400s: software, bank fees, professional). Supplies (6500s).
• Other (9000s). Depreciation, interest, taxes — below-the-line items that do not belong tangled with operating cost.

Every account has one obvious bucket and the top-level categories map directly to USAR-style reports. No translation, no mapping, no guessing.

Why 68 (Not 30, Not 200)

At 30 accounts, COGS collapses into "Food" and "Beverage" and maybe "Paper". When dairy prices jump eight percent in a week, nothing in your P&L tells you. You see total food cost up a point and a half, shrug, and move on. By the time you figure out it was cheese specifically, you have eaten three weeks of margin. Thirty accounts cannot do early detection at the sub-category level.

At 200 accounts, the failure mode flips. Your closer — human or AI — has to pick between "Dairy — Cheese", "Dairy — Milk", "Dairy — Specialty Cheese" every time an invoice comes in. Accuracy falls, posting time explodes, and reports get noisier, not sharper. You end up with a dozen near-empty sub-accounts that add no signal.

Sixty-eight is the field-tested middle. It is the number we converged on after running eight consecutive monthly closes at Uzy's NY Pizza. Enough granularity to catch cost spikes at the sub-category level, few enough accounts that a vendor invoice almost always has one obvious home.

Mapping POS, Payroll, and Vendors to the COA

Designing the COA is the easy part. The hard part is getting every transaction posted to the correct account every night, across thousands of transactions a month, from three or four different sources.

A modern Toast, Square, or Clover feed surfaces roughly a dozen revenue sub-categories per day — dine-in food, takeout food, delivery food, beverage split by type, merchandise, gift card purchases, gift card redemptions, third-party platform, service charges. Those twelve-plus categories have to route into four or five GL revenue accounts cleanly, defined once and applied every night forever.

Payroll is worse. A typical run has roughly eight line items — regular wages, overtime, tips paid out, employer payroll tax, withheld tax, benefits, workers comp, reimbursements — that split across two or three GL account groups. Get the split wrong and your labor percentage lies to you.

Vendors are the messiest. Each maps to a typical GL account — your produce company to 5030 Produce, meat to 5020 Proteins, linen to 6530 Supplies. But every vendor has exceptions. Your produce vendor sometimes drops off beverages when the beverage distributor runs short; those go to 5100 Beverage COGS, not produce. A strict vendor-to-GL rule fails because the real world is messy. Automation handles this by learning vendor-to-GL pairs over time, flagging invoices that deviate from the learned pattern for a one-tap owner review. Invoice OCR and coding is the piece that wires vendor intake into the COA; this pillar describes the skeleton it is coding into.

Ready to see what this looks like on your own books? Book a thirty-minute call and we will walk through your current COA and where a standardized baseline would land.

Why Customization Kills CPA Handoff

The single biggest driver of CPA cleanup time is a custom chart of accounts. Your CPA opens the file in February. They see accounts called "Food — Special Ingredient — Tuesday Only", "Misc Kitchen", "Owner Fun Account", "That One Vendor From 2023". Before they can produce a return, they have to map every one of those back to a standard filing category. At $150 to $350 an hour, every hour of that mapping is a direct transfer from your pocket to theirs, producing no value for you. Pure translation cost.

A standardized COA makes that translation go to zero. When books arrive already in USAR-aligned 68-account structure, the CPA's first hour is review, not reconstruction. At Uzy's, the CPA was taken aback the first time she opened the books — the structure was cleaner than what most of her junior staff produce. Engagement fees dropped, filing got faster, and the cleanup line disappeared. For a restaurant with moderate complexity, cleanup can be five to fifteen CPA hours a year that simply do not need to exist.

The Three Things Automation Does That Humans Can't (Reliably)

A disciplined human bookkeeper can maintain a clean 68-account COA. Almost none of them do, because three sub-tasks are nearly impossible to execute reliably at restaurant volume.

First, remembering every vendor-to-GL pair across thousands of transactions. A restaurant with 40 active vendors generates 300 to 500 invoices a month. Every one has a typical coding and a small set of exception patterns. A human doing this by memory drifts over months. A system that stores the pair and applies it every time does not.

Second, flagging deviations from the 90-day pattern. If your dairy vendor has coded to 5010 Dairy for ninety days and a new invoice suddenly posts to Paper Products, that is almost certainly a coding error. A human closer rarely catches it in the moment; an automated consistency check catches it every time. Same for unit-price drift — cheese at $3.10/lb for a quarter suddenly billed at $3.45/lb is a flag the system raises in minutes and a human usually won't notice until the monthly variance report.

Third, reconciling sub-totals at every account level every night. In a manual close, reconciliation is a month-end event and exhausting. By the time you notice a sub-account is off by $240, you're reconstructing four weeks of activity to find it. In an automated close, every account reconciles nightly, so a $240 variance is a question about yesterday, not last month. Year-end stops being a forensic exercise.

Migrating to a Standardized COA — What It Takes

Honest talk: if you have three years of historical books in QuickBooks with a custom 40-account COA, migrating is a real project. Not a ten-year-plan project, but not a one-afternoon project either.

The core work is a mapping exercise. Every existing account gets mapped to the new baseline, and historical transactions inherit their new account via the mapping. That alone is a half-day to a full day for a typical independent restaurant. Add another half-day to re-post the current fiscal year's transactions so year-to-date reports are clean under the new structure. Prior years usually don't get re-mapped — they get archived in their original structure for audit trail.

Most operators we talk to don't migrate historicals at all. They switch fresh at the start of a new fiscal year — typically January 1 — and let the old and new charts co-exist for one year, with prior years staying in the old structure and current year onward running on the new one. This is cleaner, cheaper, and avoids the "did we map 2023 correctly?" anxiety. By the time you've run twelve full months on the new COA, nobody looks at the old structure except your CPA pulling comparatives.

A standardized COA is the kind of infrastructure decision that feels annoying for one month and then pays back every single report you produce for the rest of your operating life. Once that skeleton is in place, everything else — your choice of banking stack, your POS coding, your CPA handoff, your benchmarking against peers — gets dramatically easier. The rest of the resource hub covers the adjacent pieces.