A production ledger where every dollar is hash-chained, double-entered, and reconciled against the bank daily — because 'the numbers are probably right' is not good enough for the IRS.

Engineering

Product

Founder

2025

PostgreSQL

Double-entry ledger

SHA-256 hash chain

SERIALIZABLE

Stripe webhooks

NUMERIC(19,4)

Presented as an anonymized engagement: no client name, branding, or screenshots appear anywhere on this page, and every figure below is synthetic. What follows is the engineering, not the client.

The problem

A 501(c)(3) Scholarship Granting Organization under the new IRS §25F federal tax credit has to move real money under real rules: process donations, keep each school's funds segregated, disburse directly to approved vendors, and stay audit-ready — all before a statutory effective-date deadline. When the auditor is the IRS, "the totals look about right" is a failure condition. Correctness had to be enforced by the system, not trusted to careful code.

Solution & demo

The answer is an append-only, double-entry ledger where the database — not the application — is the source of truth. Beyond the ledger, dense regulation is translated into enforceable product mechanics: a 90% expenditure ratio, anti-earmarking rules, income-based eligibility thresholds, IRS Pub 1771 receipt requirements encoded as database CHECK constraints, and a 7-year retention posture. A six-role access model (donor, parent, school, homeschool hub, admin, auditor) gives each party its own portal, and ineligible expense categories are made literally unselectable rather than merely discouraged.

Recorded walkthrough — 'follow a dollar': one synthetic donation is auto-split into balanced ledger entries, linked into the hash chain, checked against the cap, receipted, and disbursed to a vendor, each step annotated with the rule it enforces. All data is synthetic; nothing from any client system appears.

Live “Try it” demo lands in a later release. For now, the recorded walkthrough above is the demo.

How it works

Synthetic compliance-ledger flow. A donation enters through an idempotent Stripe webhook, splits into balanced double-entry ledger rows written on NUMERIC money columns, and links to the prior transaction through a SHA-256 hash chain. An annual cap check runs under SERIALIZABLE isolation. A daily reconciliation job compares virtual fund balances against the physical bank account and hard-blocks vendor disbursement on any mismatch. All values shown are synthetic. — Synthetic diagram — generic components only. Correctness lives in the database: append-only writes, hash chaining, and a daily bank reconciliation gate.

Financial correctness is treated as a first-class discipline. The ledger is append-only because UPDATE and DELETE are revoked at the database role layer, so there is no code path that can rewrite history. Every transaction carries a SHA-256 hash linking it to the prior one, so tampering is detectable. Money is decimal on NUMERIC(19,4) columns and never a float, so a rounding error cannot creep in. Deferrable constraints require debits and credits to balance at commit time. The statutory annual donation cap is enforced under SERIALIZABLE isolation with SELECT FOR UPDATE, so two concurrent donations cannot both squeak under the limit. Stripe webhooks are idempotent across three layers so a retried event is never double-counted. And a daily reconciliation job compares the virtual per-school balances against the physical bank account and hard-blocks any disbursement when they disagree.

Tradeoffs & lessons

What I'd do differently

Raw SQL over an ORM for ledger writes. The correctness guarantees here are all in the details an ORM abstracts away — isolation level, lock ordering, the exact write shape. Writing the ledger paths in raw SQL kept those guarantees explicit and auditable, at the price of more verbose code.
Virtual fund segregation over per-school bank accounts. One physical account with strict virtual sub-ledgers is dramatically simpler to run than dozens of real accounts — but only survives audit because reconciliation is unforgiving: no reconciliation, no disbursement.
AI deliberately absent from the money path. The judgment on display is knowing where a model does not belong. Compliance enforcement is deterministic by design, and saying so plainly makes the AI-heavy projects more credible, not less.

Links

Because this is anonymized client work, there is no public repo or live link. An anonymized engineering write-up is prepared from synthetic material only; publishing it in full is gated on client sign-off, and engagement status is described generically on purpose.