Constitutional Architecture
The Universal Ledger and constitutional design. · 9 posts
Actuals Are Sacred: Why We Made Financial Data Read-Only at the Source
Adjusting a posted entry is how small errors get quietly fixed. It's also how fraud happens. It's how audit findings get buried. It's how a company's financial history becomes something that reflects what people wanted to be true rather than what was. Immutable actuals aren't a constraint — they're the thing that makes the data trustworthy.
Revenue Recognition Is Not a Spreadsheet Problem
ASC 606 compliance lives in spreadsheets at most mid-market companies. The ERP records the invoice. The spreadsheet figures out when it's actually revenue. This arrangement works until a contract gets amended, a subscription changes mid-term, or an auditor asks to see the supporting workpapers for every deferred revenue balance. At that point, the spreadsheet becomes the problem.
Multi-Entity Without the Mess: How Intercompany Transactions Should Actually Work
Multi-entity accounting in most ERPs means running separate books and periodically trying to reconcile and consolidate them. Intercompany eliminations happen at month-end, done by hand or by a consolidation module that runs after the fact. We describe what it looks like when intercompany transactions are architecturally enforced — and eliminations happen as a property of the data, not as a step in the close.
The Economic Event Model: Treating Every Transaction as a Constitutional Moment
When a contract is signed, a subscription is activated, an invoice is issued, or a payment is received — these aren't separate events in separate systems. They're one economic event with one set of financial consequences. Designing software around that reality, rather than around the organizational silos that process each step, changes what the system can guarantee about the data it holds.
What "Single Source of Truth" Actually Means (And Why Most ERPs Don't Have One)
Every ERP vendor claims to be your single source of truth. Most of them mean: 'our system is the one you should trust most.' That's authority by convention, not by architecture. There's a meaningful difference between a system that claims to be authoritative and one that is structurally incapable of being wrong — and the difference matters every time the books need to close.
Reconciliation Variance: The Bug That Became an Industry
Reconciliation software is a multi-billion-dollar market. Close management tools. Flux analysis platforms. Variance tracking dashboards. This entire category exists because the financial systems underneath produce discrepancies that need to be managed. We've built an industry to clean up after a bug that we've decided to live with.
Database-Layer Business Rules: Why We Enforce at the Bottom, Not the Top
UI validation can be bypassed. API validation can be bypassed. A sufficiently motivated person with database access can bypass both. Database triggers and constraints cannot — they fire regardless of which path data took to get there. When the rules live at the bottom of the stack, the guarantees they produce are absolute.
Subledgers as Views, Not Sources: Rethinking Financial Data Architecture
In traditional ERP, accounts receivable maintains its own truth. So does accounts payable, fixed assets, and inventory. Reconciling them to the general ledger is a scheduled ritual every finance team knows well. There's a different model: subledgers that don't maintain their own truth because they're derived from the same source as the GL itself.
What If the Ledger Were the Law?
Most ERP systems treat the general ledger as a destination — a place where transactions land after traveling through other systems. What happens when you reverse that? When the ledger is the starting point, the rule-setter, the thing every financial event must pass through before it exists? The answer changes what financial software can actually guarantee.