Books that post themselves: what automatic double-entry accounting really means

Most restaurant systems will happily tell you what you sold. Far fewer can tell your accountant what you owe, own and earned — in a form they can sign.

The difference has a name: double-entry.

What double-entry actually is

Every transaction touches at least two accounts, and the debits must equal the credits. Not as a philosophy — as an arithmetic rule that makes errors visible.

A cashier takes 240 in cash for a meal, of which 24 is tax:

Two hundred and forty in, two hundred and forty out. If a system can produce that table for every order, refund, purchase, wage and expense, you have accounts. If it can only produce “today’s sales: 240”, you have a report.

The chart of accounts is the backbone

Underneath is a tree of accounts, each with a code, a name and a type: Asset, Liability, Equity, Revenue, Expense. Accounts can nest, so “Food purchases” can sit under “Cost of sales” and roll up automatically.

Once that tree exists, three statements fall out of it without anyone assembling them:

• Trial balance — every account and its balance; debits equal credits, or something is wrong and you will see it.
• Profit and loss — revenue accounts minus expense accounts, for a period, per branch.
• Balance sheet — what the business owns and owes at a point in time.

Those are not “reports the software renders”. They are the ledger, read three different ways.

Where the entries come from

This is the part that distinguishes an accounting engine from an accounting module you have to feed. Entries are written by the operational events themselves, each carrying a reference back to the thing that caused it:

Because each entry keeps the id and type of its source, you can always click from a number in the P&L back to the order or the invoice that produced it. That single property is what makes a month-end review possible in an afternoon instead of a fortnight.

Corrections are reversals, not edits

A posted entry is not editable. A mistake is corrected by a reversing entry that cancels it, linked to the original, leaving both visible.

This feels bureaucratic until the first time someone asks why last month’s revenue changed after it was reported. In an editable ledger, nobody can answer. In a reversing one, the answer is a row with a date, a number and a user on it.

The same principle runs through the rest of the system: an audit trail records who changed what and when, and activity logs sit alongside it. An accountant does not have to trust your memory.

Branch-aware from the start

Entries carry a branch. That means a P&L for one location, a consolidated P&L for all of them, and the ability to see which site is actually funding which — without three exports and a spreadsheet that only one person understands.

Your own tax rules

Rates, whether prices are tax-inclusive, service charge and the registration number that must appear on the bill are configuration, not code. You set what applies to your business in your country, and the ledger splits every bill onto the right lines from there. Nothing is hard-wired to one jurisdiction.

How to test any vendor in two questions

1. “Show me a trial balance.” If they show you a sales dashboard instead, the answer is no.
2. “Refund an order and show me the ledger.” You should see a new, numbered, reversing entry — not a row that quietly changed.

If both answers are clean, your accountant can work from the system directly. That is worth more than any feature on the marketing page, because it is the difference between software that records your business and software that merely watches it.