Double-Entry Ledger for PHP

About Double-Entry Ledger for PHP

A double-entry accounting ledger in plain PHP. It keeps accounts and journal entries in a SQLite file, refuses to write an entry whose debits do not equal its credits, and computes the trial balance, general ledger, income statement and balance sheet from the journal every time you ask for one.

Eleven PHP files, 2,313 lines, no Composer, no framework, no server. Unzip it and run php ledger.php init.

The one rule, enforced where it counts

Most small accounting code enforces the balance rule in a form somewhere, or in a validator that runs before save, or in a comment. This one enforces it in Journal::post(), and it does it twice.

The first check sums the input array before a database transaction is opened, so an unbalanced entry never reaches SQLite at all. The second inserts the rows, then sums them straight back out of the database inside the same transaction and compares before COMMIT. If those disagree, the transaction rolls back.

The second check is nearly always redundant, and it is there anyway, because the first one trusts an array in memory and the second one trusts the file on disk. Those are two different claims and only one of them is what your accountant cares about.

Underneath both, the schema carries its own constraints: an amount cannot be negative, and a line cannot hold a debit and a credit at the same time, or neither. Also rejected at write time, each with a message that says what to do instead: an entry with fewer than two lines, an account code that is not in the chart, an account you archived, an entry of all zeroes, and a date that is not a real YYYY-MM-DD.

php ledger.php post --date=2026-01-16 --memo="Off by ten" 
    --debit=1000:100.00 --credit=4000:90.00

Error: Entry rejected: debits 100.00 do not equal credits 90.00 (difference 10.00).

Nothing written. Exit code 1.

No balance column, anywhere

There is no cached total on any table. Every figure in every report is a SUM over journal_lines, computed at the moment you ask for it.

That is a deliberate trade and it costs something. A stored running total is faster to read, and it is also a second source of truth. The first time it drifts from the entries it claims to summarise, the ledger is quietly wrong and nothing in it tells you which number to believe. Recomputing costs a scan of the lines and buys the guarantee that a report and the journal cannot disagree.

The test suite does not take that on trust. It reads PRAGMA table_info for every table and fails if a column named balance, total or running ever appears in the schema.

If you would rather have the cache — a journal large enough that the scan matters, a reporting endpoint under load — then this is the wrong ledger and you should say so now rather than discover it in month nine.

Money is an integer, all the way down

Amounts are minor units in a PHP int. 12345 means 123.45. There is no float anywhere near an amount in any shipped file, and test.php proves it the only way that stays true over time: it greps the source for floatval, (float), (double), number_format and round(, and fails if it finds one.

Money::parse() reads the decimal string with integer arithmetic, so 0.10 plus 0.20 is exactly 30 and not 0.30000000000000004. It accepts thousands separators, so "1,234.5" becomes 123450. It rejects a third decimal place instead of rounding it away, because silently losing a hundredth of a currency unit is how a set of books stops tying out, six months before anyone notices.

Under --json, amounts stay as minor-unit integers rather than being formatted for you. Converting them on the way out would be the one place a float could get in.

The four reports

Trial balance lists every account with movement, debit balances in one column and credit balances in the other, with totals that are equal because every entry that produced them was.

General ledger for one account gives an opening balance, every line that touched it in the window, a running balance carried down the page, and a closing balance — in the account’s normal direction, so an asset reads positive when it should.

Income statement covers any date window you name, income less expenses.

Balance sheet shows assets against liabilities plus equity as of a date. The part worth knowing about: this ledger does not force a year-end close, so income and expense accounts still carry the period’s activity, and the balance sheet shows their net as a separate equity line called Current earnings. It is the same number the income statement reports for the same window. Post a closing entry into 3900 Retained Earnings and that line falls to zero while the amount appears under 3900 instead. Equity totals the same either way, and the test suite posts a closing entry and asserts precisely that.

Entries are append-only

You cannot edit or delete an entry, which is the only arrangement in which an audit trail is worth having. To correct entry #7, post a new entry that reverses it — the same lines with debit and credit swapped — and then post the right one. All three stay visible in entries:list. That is the feature, not a missing one.

The CLI

php ledger.php init
php ledger.php post --date=2026-01-15 --memo="Invoice 2026-001" --ref=INV-2026-001 
    --debit=1100:9750.00 --credit=4000:9750.00 
    --debit=5000:4100.00 --credit=1200:4100.00
php ledger.php report:trial-balance

That third command is one entry with four lines: the invoice and the cost of what it shipped, posted together, balanced as a whole rather than in pairs.

There is also accounts:list, accounts:add, accounts:archive, entries:list, entries:show, report:ledger, report:income and report:balance-sheet. Two options work on everything: --db=FILE picks the ledger file, --json prints the structure instead of a table.

ledger.php refuses to run under any SAPI except CLI, checks for PHP 8.1 and for pdo_sqlite at startup, and names whichever one is missing rather than failing later with something cryptic.

The same three objects are available as a library — $ledger->accounts, $ledger->journal, $ledger->reports — behind a require of one bootstrap file.

What it does not do

This is the section to read before downloading, because it is shorter than finding out yourself.

• No multi-currency. No currency column, no rate table, no revaluation. The ledger does not know which currency it holds. Two currencies in one file would produce totals that mean nothing, so the feature is absent rather than half-present.
• No tax or VAT. No codes, no rates, no return. Post to an account you create for it and work the numbers yourself.
• No invoicing and no documents. 1100 Accounts Receivable is a number, not a list of customers. Nothing here will produce, send or chase an invoice.
• No user accounts and no permissions. Whoever can run the file can post to it. There is no record of who posted what.
• No accruals automation. No recurring entries, no prepayment schedules, no depreciation runs. Accrue by posting the entry.
• No period locking. Nothing stops a backdated entry into a closed month.
• Two decimal places, fixed. Not configurable.
• Not a web application.

It is a ledger. An accounting suite is a much larger thing and this is not the small version of one.

Verify it yourself

php test.php

The suite builds a ledger in your temp directory and posts a realistic month: a capital injection, a purchase on credit, a four-line sale carrying its own cost of goods, a customer receipt, a supplier payment and a rent payment. It prints all four reports, then asserts that the trial balance ties at 36,750.00 on both sides, that assets of 30,850.00 equal liabilities plus equity, that net income of 3,850.00 equals the movement in retained earnings between two balance sheet dates, that a closing entry leaves every total unchanged, and that nine kinds of bad entry are each rejected with no row left behind.

54 assertions. Exit code 0 means they all held. Built and tested on PHP 8.3.33 with SQLite 3.53.2; the floor is PHP 8.1.

MIT licensed. Use it commercially, modify it, ship it inside something you sell.