Most accounting software tells you it does double-entry bookkeeping. Almost none of them tell you the actual rules their ledger is built to — what happens when you try to edit a posted entry, what a "delete" really does under the hood, how a VAT figure is computed and by which single piece of code, how a foreign-currency invoice gets translated back into pounds. That's usually because the rules were never written down anywhere a customer could read them.
We wrote ours down. What follows is The Ideal Ledger — nine principles that describe what a ledger has to guarantee to be trustworthy, and what ac-co's posting engine is built to do about each one. It draws on UK GAAP, specifically FRS 102 and FRS 105, the financial reporting standards published by the Financial Reporting Council (FRC) that most UK small companies and micro-entities report under. We are not "FRS 102 certified" — no such certification exists for bookkeeping software, and any product that claims one is making it up. What we can do is show our working: here is the standard, here is why each rule exists, and here is what it means day to day for the books you're looking at.
This page is the index. Each of the nine principles below has a longer companion guide — on journal posting, the chart of accounts, counterparties and products, invoices and bills, bank and payments, and VAT/FX/reports — linked at the bottom.
1. Posted entries don't change
The rule: once a journal entry is posted, editing its amounts, its accounts, or its date isn't an operation ac-co exposes. A journal entry is either not yet posted (a draft, freely editable) or posted (fixed). There's no third state where a posted number quietly moves.
The reasoning is simple: a ledger you can edit after the fact isn't evidence of anything. The whole point of "posting" is that it's the moment a transaction stops being a proposal and becomes part of the record — a bank statement, an HMRC filing, an auditor's sample, all of them assume that once you show someone a number, it stays that number unless there's a new, dated entry explaining the change. Software that lets amounts drift after the fact turns every report into a snapshot of "whatever it says right now," which is a different, much weaker claim than "this is what happened."
What this means for you: if you spot a mistake in a posted transaction, you won't find an "edit" button on the amount. Instead you correct it the way an accountant always has — by posting an adjustment — and the system does the bookkeeping mechanics of that for you (see principle 3).
2. Every figure traces to a source document
The rule: a posted entry always references what caused it — an invoice, a bill, a bank transaction, a payment, or an explicit manual journal with its own audit note. There's no such thing as a number that just appears on your P&L with no evidence chain behind it.
This is what makes a set of books auditable rather than merely plausible. When your accountant, a lender, or HMRC asks "where did this £4,200 in the accounts come from," the answer shouldn't be "the bookkeeper remembers typing it in." It should be a specific document, dated, with a counterparty, that you or your bank fed into the system. Chasing that chain — from a number on a report, back through the journal entry, back to the invoice or bank line that caused it — is the basic move of any review, and it only works if every entry actually has that thread attached.
What this means for you: every transaction you can see in your reports has a "why" behind it that you can click through to — a document, a bank line, or a note explaining the manual entry. Nothing is a bare number.
3. Correcting a mistake means reversing it, never deleting it
The rule: there is no delete button for a posted transaction. To undo one, the system posts a second entry that mirrors the first — same accounts, opposite signs — so the two net to zero. Both entries stay visible in your history: the original, now marked reversed, and the reversal that cancelled it.
This sounds like a technicality until you think about what "delete" would actually mean for a filed tax return or a signed-off set of accounts. If a transaction that was part of a VAT return you already submitted simply vanished from the database, your books and your filing would permanently disagree with no record of why. A reversal keeps both statements true at once: "this happened" and "this was then undone" are both facts, and a ledger that only remembers the second one is quietly rewriting its own past.
What this means for you: nothing you've posted is ever silently gone. If something needs to be undone, you'll see two lines instead of a hole where one used to be — which is exactly what you want to be able to show someone asking "what changed, and when."
4. The books remember what they looked like before, not just what they look like now
The rule: this is bitemporal record-keeping — every row on the financial spine tracks two independent timelines. Valid time is when the money actually moved (the entry date on the transaction). Transaction time is when the system was told about it (when the row was written, and — if it was later corrected — when that version was superseded). A report as of "today" reads the latest, uncorrected version of every fact; a report as of "31 March, as we knew it on 5 April" reads exactly what was on file at that moment, corrections and all.
Real bookkeeping needs both. A late invoice discovered in June but dated back to March should show up in March's numbers (valid time) — but the auditor reviewing your March close in April, before that invoice existed, was correct at the time (transaction time), and a bitemporal ledger can reproduce both views without contradiction.
What this means for you: if a number you filed or reported changes later, you can still pull up exactly what the report said on the day you filed it — not a best-effort reconstruction, the actual historical state.
5. VAT lives on one control account, and one calculation decides the number
The rule: VAT is never treated as revenue or as an expense. Every posting path — an invoice, a bill, a bank-fed transaction — books the underlying amount net of VAT and puts the VAT itself on a dedicated VAT control account. And there is exactly one place in the system that answers "how much VAT do we owe this period" — every screen, dashboard and the actual submission to HMRC read the same calculation, not separate approximations that happen to usually agree.
The failure mode this prevents is familiar to anyone who's used spreadsheet-era bookkeeping: your VAT dashboard says one number, your P&L implies another, and the figure you actually file is a third thing someone typed in by hand. That's not a rounding issue, it's three different systems of record disagreeing with each other, and nobody can tell you which one is right without redoing the sums from scratch.
What this means for you: the VAT figure you see anywhere in the product — on a report, before you file, in your VAT return itself — is the same figure, computed the same way, every time.
6. Foreign currency is translated at the rate on the day it happened, and gains are split into realised and unrealised
The rule: your books are kept in one functional currency. A transaction in another currency is translated at the exchange rate on its own transaction date — never a rate the system invents or defaults to 1 because a real one wasn't available — and every stored rate carries a note saying where it came from (a bank feed, a manual entry, a published rate). When a foreign-currency balance is actually settled, the difference between the booked rate and the settlement rate becomes a realised gain or loss. When it's still open at a reporting date, the same comparison against the period-end rate produces an unrealised one — a paper movement that reverses the moment the real world catches up.
This split matters because a foreign-currency debtor you haven't been paid yet isn't the same kind of gain or loss as one you have — mixing them together overstates or understates your actual cash position depending on which way the currency has moved.
What this means for you: if you trade in dollars or euros, your reports separate "we made money because the rate moved and we've banked it" from "the rate moved and this is what it would be worth if we cashed out today" — two different facts, kept as two different lines.
7. The chart of accounts has structure, not just a flat list of names
The rule: accounts sit in a hierarchy. Only the accounts at the bottom of that hierarchy — leaf accounts — can actually be posted to; the ones above them exist purely to group and total. Accounts your ledger itself depends on to function — the VAT control account, your AR and AP control accounts, retained earnings — are flagged as system accounts, and an account that's already been posted to can't just be deleted out from under your reports.
Without that structure, a chart of accounts degrades into whatever anyone typed into it — duplicate accounts with slightly different names, postings landing on a summary line that was supposed to be a subtotal, and reports that no longer add up cleanly by category.
What this means for you: your reports group consistently because the underlying accounts are governed, not just listed — you won't find a stray posting sitting on an account meant to be a header, and you won't be able to accidentally delete an account your own reports rely on.
8. Bank reconciliation ties to real evidence, not to a number you typed
The rule: bank feed evidence is append-only — once a bank line arrives, it isn't edited or deleted, only excluded (with a reason) or matched. A given bank line links to at most one live journal entry at a time, so the same transaction can't be booked twice under two different categorisations. And when you sign off a reconciliation, the system keeps a durable, item-level snapshot of exactly what matched at that moment — not just a "reconciled" checkbox that stops meaning anything once the underlying data moves.
This is the difference between reconciliation as a real control and reconciliation as a formality. A checkbox that anyone can silently untick, or a bank feed you can quietly edit, gives you the appearance of a reconciled bank account without the substance of one.
What this means for you: a bank account you've reconciled stays reconciled — the evidence behind that sign-off doesn't move under you later.
9. A closed, filed period locks — and reopening one is never silent
The rule: once a VAT period is closed and a return filed against it, new entries can't be posted inside that period. Reopening a locked period is a distinct, deliberate action — it requires a reason, and that reason is recorded — rather than something that happens as a side effect of an unrelated edit.
Filed figures are legal facts, not drafts. A ledger that lets a closed period keep quietly absorbing new postings gives you a VAT return that no longer matches what actually happened, with nothing telling you it drifted. Locking is what makes "we filed this" mean something.
What this means for you: the numbers behind a return you've already submitted to HMRC don't keep moving after the fact. If a period genuinely needs reopening — a correction discovered later — that's a visible, reasoned action, not something that happened quietly overnight.
The six domains
Each principle above is enforced across a specific slice of the product. The companion guides below go deeper on each:
- Journal & posting — how an entry gets created, balanced, and posted; what "reversal not deletion" looks like in practice.
- Chart of accounts — leaf vs. header accounts, system accounts, and why structure matters.
- Counterparties & products — customers, suppliers, and the catalog items you bill and buy against.
- Invoices & bills — numbering, issuing, and what happens once a document is no longer a draft.
- Bank & payments — the bank feed, categorisation, allocations and reconciliation.
- VAT, FX & reports — the VAT control account, currency translation, and statutory output.
None of this replaces reading the standards themselves. If you want the source, FRS 102 and FRS 105 are published by the FRC — everything above is our account of how we've built to them, not a substitute for them.