Engineers do not get to make startup mistakes when they build ledgers

Original Article ↗ Hacker News Discussion ↗

Double-entry accounting and why it matters

  • Many argue double-entry is essential for ledgers: every transaction changes at least two accounts and must net to zero, enforcing “money can’t appear/disappear.”
  • Supporters say it provides redundancy for error detection, fraud resistance, and auditability, especially when reconciling with external parties.
  • Several note that “double-entry” doesn’t have to mean two rows; it can be a single tuple (amount, debit_account, credit_account) or a multi-leg transaction that still balances.
  • Some developers prefer a simpler signed-amount model (positive/negative per account) and treat debit/credit as a presentation layer, claiming it’s equivalent if rigorously enforced.

Rounding, “dancing cents”, and numeric types

  • Many point out that the “lost cents” problem is usually from using binary floating point or poorly specified rounding rules, not from lack of double-entry alone.
  • Common advice: store money as integers (smallest unit) or exact decimal types, and clearly define contract rounding behavior (e.g., wages, energy billing, partial installments).
  • Double-entry can reveal but not fix arithmetic issues; tests and clearly defined rounding policies are still required.

Engineering responsibility, regulation, and accountability

  • Debate over whether individual software engineers should be personally liable for bad financial systems.
  • In North America, “software engineer” is mostly unlicensed, unlike PEs in civil/mechanical fields; in some other jurisdictions certain financial roles are now individually accountable.
  • Several compare fintech failures to the 2008 crisis or the UK Post Office scandal to argue that consequences are often diffused and under-enforced.

Fintech risk vs banks; Synapse/Yotta example

  • Multiple comments use the Synapse collapse (missing tens of millions in pooled FBO accounts) as a cautionary tale about buggy or unreconciled ledgers.
  • Emphasis that FDIC insurance typically applies to the partner bank, not to fintech accounting errors; customers of intermediaries can be left frozen or short.
  • Some say they now avoid fintech “banking” products entirely, preferring direct relationships with regulated banks or brokerages.

Implementation patterns and tools

  • Several advocate append-only, immutable ledgers (journal of movements; balances are derived views, not stored truth).
  • Reconciliation systems separate from the trading or payment platform are seen as critical in serious finance.
  • Tools and systems mentioned (TigerBeetle, ledger-cli, Postgres schemas, event sourcing, QLDB-like append-only logs) are praised by some, but others warn about new, unproven stacks and insist on understanding accounting fundamentals first.

Blockchains, Merkle trees, and tamper-resistance

  • Some suggest internal Merkle-tree–based logs or blockchain-style append-only structures to prevent tampering with history.
  • Others argue standard databases with write-once or audit-logging controls are sufficient unless you truly need decentralized trust; proof-of-work–style consensus is seen as overkill for internal ledgers.

Domain knowledge and culture

  • Strong theme: “Accounting for programmers” should be baseline for anyone touching money; lack of domain knowledge leads to brittle, ad-hoc systems that later require painful rewrites.
  • Several describe careers built on cleaning up non-ledger-based billing or trading code, reinforcing that “move fast and break things” is dangerous when dealing with real money.