A professional double-entry accounting database schema following GAAP/IFRS principles. Features a hierarchical chart of accounts (assets, liabilities, equity, revenue, expenses), journal entries with balanced debit/credit lines, invoice generation with line items, and full audit trail. Suitable for building accounting software like QuickBooks or Xero, ERP financial modules, or bookkeeping platforms.
The rule that governs this schema is not written in any column: for every journal_entries row, the sum of its journal_lines debits must equal the sum of its credits. Nothing in the table definitions enforces it, which is why the entry carries a status — a draft can be unbalanced, a posted entry cannot.
Debits and credits are separate columns rather than one signed amount. That mirrors how ledgers are actually read and kept, and it makes an unbalanced entry visible as two different sums instead of a total that happens not to be zero. Each line fills exactly one of the two.
Invoices do not replace journal entries; they produce them. invoices.journal_entry_id links the commercial document to its accounting effect, so the invoice can be revised, voided or chased while the ledger keeps the immutable record of what was posted and when.
A single signed amount would be smaller and would let a line be both at once by accident. Two columns make the convention explicit, let the balance check be two sums compared, and match every report an accountant already knows how to read. The cost is a constraint the schema cannot express — exactly one of the pair must be non-zero — which has to live in the application or a check constraint.
status on journal_entries exists so a posted entry becomes immutable. Correcting a mistake means posting a reversing entry and a new correct one, which leaves three rows telling the truth about what happened. Editing in place would be simpler and would make the ledger unauditable — the entire point of double-entry is that history cannot be quietly rewritten.
Once a period is closed and reported, a new posting into it changes numbers that have already been published. The flag makes that a rejected write rather than a discovered discrepancy months later. It also gives the close process somewhere to record itself, with closed_at as the moment the books stopped moving.
Assets and expenses increase with a debit; liabilities, equity and income increase with a credit. That is a property of the five classifications, not of individual accounts, so storing it per category keeps one definition and makes every account inherit the right sign. Putting it on each account would invite a cash account configured as a liability.