Special projects

LedgerCore

Double-entry accounting: postings, balances and reversals. A repeated command returns the original result, and competing withdrawals lock the accounts before the balance check.

Type: Accounting service
Stack: Java · Spring Boot · PostgreSQL
Code: Open on GitHub
Year: 2026

A double-entry balance

A posting puts weights on both pans, debit and credit. The stamp comes down only when the beam is level, and a punched ticket with the same key never passes twice.

The commit stamp: it comes down only when the beam is levelPosting weights: debit left, credit right, sized by amountReceipt file and the ticket with its punched keyA tabletop model of LedgerCore, a double-entry accounting service in Java, Spring Boot and PostgreSQL. A transaction has two or more postings, and debits equal credits in each currency: the left pan holds the debit weights, the right pan the credit weights, and a weight's size is its amount in whole minor units. The commit stamp comes down only when the beam is level, and it sees the whole set of postings at once; an unequal pair leaves the beam tipped and the stamp locked. Every request arrives on a ticket with its idempotency key: the punch recognises a key that was already punched and returns the original receipt instead of a new stamp. History is never edited: a reversal puts a new mirrored pair on the pans with every side inverted, and the earlier weights stay. The bench shows only the latest weights on the pans and the latest six receipts; the database keeps the whole history.

The model

Every transaction has two or more postings, and debits equal credits in each currency. Amounts are stored as 64-bit minor units; no fractional money reaches the database. Balances are derived from postings and history is never edited: a reversal is a new transaction with every side inverted.

The write path

Every request carries an idempotency key. A replay with the same key and body returns the original transaction; a different body is rejected. The affected accounts are locked in a stable order, so of two concurrent attempts to spend the last unit only one succeeds. Deferred PostgreSQL constraints check the complete posting set at commit.

Under the hood

Double entry with a balance check per currency.
An idempotency key behind a PostgreSQL advisory lock.
Accounts locked in UUID order against races.
Reversal only as a new transaction, one per original.
Updating and deleting postings is blocked by the database.

Code on GitHub

Shall we talk about your project?

Discuss your project