At some point every founder meets double-entry accounting, usually via an accountant saying something impenetrable about debits. This post is the explanation we wish existed: what the system actually is, why it has survived five centuries of better technology, and which of its mechanisms you should demand from any software that touches your books.
No prior accounting knowledge assumed. Some opinions included.
The core idea: every transaction has two sides
Money never simply appears or disappears. It always moves from somewhere to somewhere. Double-entry bookkeeping records both sides, every time.
You invoice a customer $1,000. Two things became true simultaneously: the customer owes you $1,000 (an asset called accounts receivable went up), and you earned $1,000 (a revenue account went up). One transaction, two entries.
The customer pays. Again two sides: cash up $1,000, accounts receivable down $1,000 — they no longer owe you.
You buy a $2,000 laptop: cash down, equipment up. Take a $50,000 loan: cash up, and a liability up — the money arrived with a matching obligation attached, which is exactly the fact a single-entry record loses.
Debits, credits, and the zero-sum rule
The two sides have old names: debit and credit. Forget the bank-statement intuition that debit means “money out” — in accounting they are just the left and right side of every entry, with one iron rule:
For every transaction, total debits must equal total credits.
Debits increase assets and expenses; credits increase liabilities, equity and revenue. You do not need to memorize that today. You need the consequence: because every entry sums to zero, the whole ledger sums to zero, always. Any transaction that does not balance is provably malformed — not unusual, not a judgment call: wrong.
That is the entire genius of the system. Single-entry records (a spreadsheet of ins and outs) can silently drift: a typo, a pasted-over cell, revenue counted twice. Double-entry cannot drift silently, because an imbalance is mechanically detectable at any moment. It is a checksum for your finances, invented around five hundred years before checksums.
The general ledger: one place where everything lands
All these entries land in the general ledger — the master record, organized by account via a chart of accounts: cash, receivables, inventory, payables, revenue, expense categories, and so on. Every financial statement you will ever produce is a different summary of the same ledger rows:
- Profit & Loss: revenue and expense accounts over a period.
- Balance Sheet: assets, liabilities and equity at a moment.
- Trial balance: the checksum report — do all debits equal all credits?
One underlying record, many views. When your “dashboard revenue” and your “books revenue” disagree, it is because they are not views of one record — they are two systems with a sync between them. Hold that thought.
Two mechanisms that separate real books from a numbers file
Balanced entries are the foundation. Two more mechanisms make books trustworthy to outsiders — a bank, an auditor, an acquirer, the tax authority.
Period locks
Books are reported in periods, usually months. Once a month is reported, its numbers must stop moving. A period lock enforces this: a closed period accepts no new postings, full stop. Found a March error in June? You do not reach back into March — you post the correction in June, where it is visible. Without period locks, every report you have ever issued is provisional, and “what was Q1 revenue?” has a different answer depending on when you ask.
Reversal-only corrections
Mistakes happen. The trustworthy way to fix one is never to edit or delete the wrong entry — it is to post a new, linked, mirror-image reversal, then the correct entry. History stays intact; the fix is itself part of the record. Books where entries can be edited in place are books where anything could have been edited in place. That is not an accusation an auditor makes out loud; it is a discount they apply quietly.
What this means for your software
Here is the founder-practical part. When you evaluate anything that will hold your books, translate the theory into blunt questions:
- Is it actually double-entry, enforced? Not “produces reports that look like accounting” — does the system refuse an unbalanced entry, at the storage layer, where no bug in the app can sneak one past?
- Do invoices post to the ledger automatically and atomically? If issuing an invoice and recording its accounting are two separate steps — or two separate products connected by a sync — there is a window where they disagree. Windows like that are where books rot.
- Are there period locks? And is closing a period a real barrier rather than a label?
- Are corrections reversal-only? Can the same entry be reversed twice by accident? (It should not be possible.)
Since this is our blog, our own answers, verifiable in the product: Oneop’s finance module is a real double-entry general ledger. Debits-equal-credits is checked in the application and again by a PostgreSQL trigger that rejects an unbalanced write outright — the invariant lives in the database, beneath any application bug. Issuing an invoice posts receivable, revenue and the tax split in one atomic transaction. Periods close and stop accepting postings, closed-period entries are rejected rather than refiled, corrections post as linked mirror-image reversals, and the same entry cannot be reversed twice. New workspaces start with a default chart of accounts, four journals and twelve monthly periods, so nobody begins from a blank ledger.
One boundary, stated plainly: the finance module is included in every workspace, but its surfaces unlock by plan. Invoicing and the ledger behind it are on every plan, Free included, capped at 5 invoices a month. Financial reports start at Starter. Payables, expenses, tax and bank reconciliation start at Pro. Multi-currency starts at Business.
Why this belongs in the same system as your CRM
The traditional answer is that accounting lives in accounting software, and your operational tools sync into it. Every one of those syncs is a place where the number in your sales tool and the number in your books diverge — quietly, at 3 a.m., in a job log nobody reads.
The alternative is one record: chat becomes deal becomes invoice becomes ledger posting, as state changes on the same database rather than copies between products. That argument is bigger than accounting and we made it in full at why Oneop.
And one honest boundary, since AI is what we are known for: the ledger mechanisms in this post contain no AI. Posting, balancing, locking and reversing are deterministic, and they should be — this is precisely the category of work where you want a trigger, not a model. Where AI does help in finance is at the edges: reading a photographed receipt or bill into structured data, suggesting an expense category. Judgment about money stays with mechanisms and people — a distinction we explore in When not to automate.
If you are at the stage where the spreadsheet is starting to creak, the free plan includes invoicing and the ledger underneath it, and the rest of the books unlocks as you move up plans. No credit card, and — fittingly — no surprises.