What Is Double-Entry Bookkeeping? With Journal-Entry Examples

Double-entry bookkeeping records every transaction twice: once for where value came from, once for where it went. Each recording is a set of debits and credits that must be equal in total. Sell services for 1,000 € and the books don't just note "earned 1,000" — they note that receivables went up and revenue went up, in the same entry, by amounts that balance.

That one constraint — debits always equal credits — is the whole system. Everything else in accounting is built on top of it.

The core idea: every transaction has two sides

Money never appears or disappears in a business; it moves. A sale converts work into a claim on a customer. A payment converts that claim into bank balance. A loan converts a bank balance increase into an obligation. Double-entry makes both sides of each movement explicit:

• What was received (the debit side)
• What was given, or who now has a claim (the credit side)

Because both sides are always recorded, the books describe the complete position of the business at any moment — not just its cash. That is what makes a balance sheet derivable from the ledger instead of assembled by hand, and it is why the accounting equation holds at all times.

The mechanics

Each transaction is captured as a journal entry: a date, a description, and at least two lines. Each line names an account from the chart of accounts and carries a debit or a credit amount. The entry is valid only if total debits equal total credits.

Which side increases an account depends on its type — assets and expenses grow with debits, liabilities, equity and income grow with credits. The full rules, with a cheat sheet, are in Debits and Credits Explained.

Worked examples

A Lithuanian services company, amounts in euros, VAT at the standard 21%. Account codes from the standard Lithuanian chart.

1. Issue a sales invoice for 1,000 € + VAT:

Account	Debit	Credit
2410 Trade receivables	1,210
5001 Service revenue		1,000
4492 VAT payable		210

Revenue is recognized when earned, not when paid. The customer's debt and the VAT owed to the state are both on the books from day one.

2. The customer pays:

Account	Debit	Credit
2710 Bank	1,210
2410 Trade receivables		1,210

No income here — the income was recorded in entry 1. This entry only converts one asset (a receivable) into another (bank balance). Single-entry systems conflate these two moments; double-entry keeps them apart, which is the entire subject of cash basis vs accrual accounting.

3. Receive a supplier invoice for 121 € including VAT:

Account	Debit	Credit
6209 Administrative expenses	100
2441 VAT receivable	21
4430 Trade payables		121

Three lines, still balanced: 100 + 21 = 121. Entries can have any number of lines as long as the totals match — payroll entries routinely have five or more.

4. Buy a 6,000 € machine with a bank transfer:

Account	Debit	Credit
1220 Machinery and equipment	6,000
2710 Bank		6,000

Note what did not happen: no expense. The business swapped one asset for another. The expense arrives gradually, as depreciation, through adjusting entries.

What double-entry buys you

• A complete picture. Assets, debts, and equity are tracked continuously, so a balance sheet and profit and loss statement fall out of the ledger mechanically.
• Built-in error detection. If the books don't balance, something is wrong — and a trial balance will show it. Single-entry records have no equivalent alarm.
• An audit trail. Every balance decomposes into the entries that produced it. "Why is VAT payable 2,100 €?" has a precise, line-by-line answer.
• Resistance to manipulation. Hiding a transaction requires falsifying at least two accounts consistently, and the imbalance risk grows with every touch.

These are the reasons every accounting standard, every tax authority, and every serious piece of accounting software assumes double-entry. The comparison with the alternative is covered in Single-Entry vs Double-Entry Bookkeeping.

The method is old precisely because it works: it was already standard practice among Venetian merchants when Luca Pacioli documented it in 1494, and nothing since has improved on the core invariant.

How software enforces it

In manual bookkeeping, "debits must equal credits" is a discipline. In a well-built system it is a constraint that cannot be violated. Nordlet's ledger API rejects any transaction whose lines don't balance: POST /v1/ledger/journal/transactions/create requires at least two lines and validates the totals before anything is written. Most entries aren't typed in at all — sales invoices, purchase invoices, payroll and bank transactions post themselves through configurable posting rules, each producing a balanced entry in the general ledger. Unbalanced books are not a state the database can represent.

FAQ

What is double-entry bookkeeping in simple terms?

Every transaction is recorded in at least two accounts — what was received and where it came from — with equal debit and credit totals. Because both sides are always captured, the books describe the whole business, not just its cash.

Why must debits equal credits?

Because a transaction is a movement of value, and a movement has a source and a destination. Equal debits and credits are how the books state both. If they differ, part of the movement went unrecorded — that's an error, and the imbalance is what exposes it.

Does a small business need double-entry bookkeeping?

Any limited company effectively does: statutory financial statements are derived from a double-entry ledger, and accounting law in EU countries assumes one. Only the smallest sole traders can get by on single-entry cash records — until they need a balance sheet, credit, or an audit.

Is double-entry the same as recording everything twice?

No. The transaction is recorded once, as one entry — but the entry has two sides. Nothing is duplicated; the two sides say different things about the same event.

Who invented double-entry bookkeeping?

It evolved among Italian merchants in the 13th–14th centuries; Luca Pacioli systematized and published the method in 1494. It has survived five centuries essentially unchanged because the balancing invariant is as useful in a database as it was in a Venetian ledger book.