Most restaurants do not have an accounting problem. They have a data-entry problem that shows up as an accounting problem three weeks after the month closes.
August 16, 2026
Here is the version of month-end most independent operators know. Somebody prints or exports a stack of daily close reports. Somebody else — a bookkeeper, a spouse, occasionally the owner at 11pm — retypes the totals into QuickBooks or Xero, one day at a time. The deposits in the bank do not match the sales in the register, because they never do, so a suspense account quietly absorbs the difference. Six weeks later the accountant asks why food cost moved four points and nobody can answer, because the numbers being asked about were assembled by hand from three systems and are already stale. None of that is an accounting failure. It is a plumbing failure, and it is fixable in an afternoon if you understand what the plumbing is supposed to do.
The most common mistake is expecting the POS to push every ticket into the general ledger. It should not. Your accounting system is not a sales database and it will get slow and unusable if you treat it as one — a busy store writes thousands of tickets a month, and no accountant wants to scroll through them. What you want is a daily sales journal: one summary entry per business day, per location, that books the day in totals and balances to zero.
That single entry credits your revenue accounts by category, credits sales tax payable, credits any liability you took on (gift cards sold, tips owed to staff), and debits the settlement side — cash, each card batch, each third-party delivery receivable, house accounts. If the entry balances, the day is right. If it does not, the POS should tell you before the entry ever reaches the ledger. Order-level detail stays in the POS, where it belongs and where you can actually search it.
The second thing worth automating is the purchase side: vendor invoices coded to inventory or expense accounts, ideally captured where you receive the goods rather than from a shoebox in the office. But start with sales. Sales is the entry you make 365 times a year and it is where the manual hours actually go.
Every integration failure I have seen traces back to mapping done in a hurry. The connector asks which account each POS category should hit, somebody picks something plausible under time pressure, and the mapping then quietly misstates the books for a year. Spend the hour up front. A restaurant chart of accounts does not need to be elaborate — it needs to match how you actually make decisions.
Split revenue into the categories you would genuinely act on: food, beverage split between alcohol and non-alcohol if you carry a liquor licence, retail or packaged goods, catering, gift card redemption. If you would never change anything based on the distinction, do not create the account. Twelve revenue lines you ignore are worse than four you read weekly. Below is the mapping most operators end up with.
| POS figure | Where it belongs | Common mistake |
|---|---|---|
| Gross sales by category | Revenue accounts | Booking net-of-discount totals, which hides discount spend entirely |
| Comps, voids, discounts | Contra-revenue accounts | Netting them into sales, so nobody ever sees what they cost |
| Sales tax collected | Liability, not revenue | Leaving it in sales and overstating the top line all year |
| Card settlements | Clearing account per processor | Booking straight to the bank, which guarantees a reconciliation gap |
| Processing fees | Expense — never netted against sales | Recording only net deposits, so the true fee is invisible |
| Tips collected on cards | Liability until paid out | Treating tips as revenue, which inflates sales and distorts every ratio |
| Gift cards sold | Deferred revenue liability | Recognizing revenue at sale instead of at redemption |
| Third-party delivery sales | Revenue plus a receivable from the platform | Booking only the net payout and losing both the gross and the commission |
Two of those are worth stating plainly because they distort more restaurant P&Ls than anything else. Tips are not your money — they are a liability you hold briefly and hand to staff, and running them through revenue will inflate sales, wreck your labour percentage, and make food cost look artificially good. And discounts belong in contra-revenue where you can see them. A store that comped four points of sales last month should be able to read that in one line rather than infer it. Our guide to comps, voids and discounts covers the operational side of that control.
New operators lose a lot of evenings to this. Tuesday shows 8,400 dollars in sales and the bank shows 7,900 arriving Thursday. Nothing is wrong. Card batches settle a day or two later and on a lag over weekends, processing fees come out either per batch or in one monthly lump, tips are paid out on a different cycle, and delivery platforms remit weekly net of commission. Sales and cash are two different events and the gap between them is exactly what a clearing account exists to hold.
The discipline is simple: every card batch the POS reports gets debited to a clearing account, and every deposit that lands in the bank gets credited out of it. A clearing account that trends toward zero means your payments are healthy. A clearing balance that grows month over month means something is genuinely wrong — a batch that never settled, a chargeback nobody booked, or fees being deducted in a way your mapping does not reflect. That balance is one of the more useful early-warning numbers in the whole system, and it costs nothing to watch.
If your processor deducts fees before depositing rather than billing them monthly, insist on booking the gross and the fee separately. Netting is tempting because it matches the bank line exactly, but it means you can never answer what payments actually cost you — see restaurant credit card processing fees for why that number deserves its own line.
Marketplace orders are where integrations most often go quietly wrong. The platform collects the full menu price from the guest, keeps a commission, and remits the remainder days later. If your books only ever see the remittance, your revenue is understated, your commission cost is invisible, and your food cost percentage is calculated against the wrong denominator — which makes every margin conversation you have that quarter mildly untrue.
Book the gross order value as revenue, book the commission as an expense, and carry a receivable from each platform until the payout arrives. Then you can actually compare channels: what a marketplace order contributes versus what the same order contributes through your own commission-free online ordering. That comparison is impossible if one channel is booked gross and the other net, and it is the single most valuable thing a clean integration gives you. The arithmetic is laid out in commission-free vs third-party delivery.
An integration is not a set-and-forget appliance. Menus change, somebody adds a category, a new payment type appears, a platform changes how it remits. Fifteen minutes a week catches nearly everything before it becomes a month-end archaeology project.
Do that and month-end stops being a reconstruction exercise. It becomes a review — which is what it was always supposed to be, and what makes numbers like food cost percentage trustworthy enough to act on.
Do not try to run perpetual restaurant inventory inside your accounting system. General ledgers are not built to track case-to-each conversions, recipe yields, or par levels, and forcing it produces a slow system nobody updates. Track inventory and recipes in the POS platform, where receiving, counts, and theoretical usage already live, and let the accounting system carry the financial result: purchases coded to inventory or COGS, and a periodic adjustment at month-end from the physical count.
What you want flowing to the books is the summary — opening inventory, purchases, closing inventory, cost of goods sold — and what you want to stay operational is the detail that tells you which items drifted and why. Keeping those separate is the difference between an inventory process that survives a busy August and one that gets abandoned in week three.
Ask whether the integration is native or goes through a paid third-party connector, and what that connector costs per location per month, because it is a line that quietly scales with growth and rarely appears in the original quote — the same category of cost covered in restaurant POS cost. Ask whether the entry is a summary journal or order-level detail. Ask how it handles multiple locations against one chart of accounts, whether each location can carry its own class or tracking category, and what happens when a day fails to post — silent failure is the difference between fifteen minutes and a lost weekend.
Then ask to see it. A vendor should be able to show you a real daily journal entry from a real store, on your accounting system, before you sign anything. If the answer involves a CSV export and a manual import step, that is not an integration, it is a shorter version of the retyping you are already doing. And if you are evaluating a switch, this is a legitimate line of comparison when weighing a Toast alternative, a Square alternative, or a Clover alternative — vendor capabilities differ and change, so confirm the current behaviour directly with each one rather than relying on any published comparison, including this one.
No. Send a summary journal entry per business day, per location, that books revenue by category, contra-revenue, sales tax, tips and gift card liabilities, and the settlement side. Order-level detail belongs in the POS, where it is searchable and does not slow the ledger down. Pushing thousands of individual tickets into an accounting file makes it unwieldy for your bookkeeper and gives you nothing you cannot already get from POS reporting.
Because sales and cash are different events. Card batches settle a day or more later, weekends compress into one deposit, processing fees may be deducted before the deposit or billed monthly, tips pay out on a separate cycle, and delivery platforms remit weekly net of commission. Book each batch to a clearing account and clear it as deposits land. A clearing balance drifting toward zero is healthy; a growing one means a batch, chargeback, or fee is unaccounted for.
Card tips are a liability from the moment they are collected until they are paid to staff, not revenue. Booking them as revenue inflates your top line, understates labour cost as a percentage of sales, and flatters food cost — three of the numbers you most rely on. Post them to a tip liability account and clear it when payroll or the tip-out runs, then verify each week that no stale balance is sitting there.
Record the gross order value as revenue, the platform commission as an expense, and a receivable from the platform until the payout arrives. Booking only the net remittance understates revenue, hides what the channel actually costs, and skews every percentage calculated against sales. Booking it properly also lets you compare marketplace orders against your own direct ordering channel on the same basis, which is the comparison that usually drives the decision.