Diff: infrastructure/data-vault-bookkeeping-substrate.es
From 13b8caa to 13b8caa
+0 / −0 lines
| Before | After |
|---|---|
| --- | --- |
| schema: foundry-doc-v1 | schema: foundry-doc-v1 |
| title: "Data vault bookkeeping substrate" | title: "Data vault bookkeeping substrate" |
| slug: data-vault-bookkeeping-substrate | slug: data-vault-bookkeeping-substrate |
| category: infrastructure | category: infrastructure |
| type: topic | type: topic |
| quality: complete | quality: complete |
| short_description: An SMB bookkeeping and accounting architecture built on an immutable source vault, append-only journal, and structural separation between the bookkeeping record and any accounting tool. | short_description: An SMB bookkeeping and accounting architecture built on an immutable source vault, append-only journal, and structural separation between the bookkeeping record and any accounting tool. |
| status: active | status: active |
| bcsc_class: public-disclosure-safe | bcsc_class: public-disclosure-safe |
| last_edited: 2026-05-06 | last_edited: 2026-05-06 |
| editor: pointsav-engineering | editor: pointsav-engineering |
| cites: | cites: |
| - ni-51-102 | - ni-51-102 |
| paired_with: data-vault-bookkeeping-substrate.es.md | paired_with: data-vault-bookkeeping-substrate.es.md |
| --- | --- |
| The dominant pattern in SMB accounting software places the general ledger, chart of accounts, and transaction history inside a proprietary database operated by the software vendor. Migration between platforms requires re-importing journal entries, reconciling every period, and re-linking source documents manually — a process that routinely costs thousands of dollars in accountant time. The data vault bookkeeping substrate addresses this structural lock-in by separating the canonical record from every tool that consumes it, applying the same [[worm-ledger-design|WORM ledger discipline]] used across [[three-ring-architecture|Ring 1 boundary services]]. | The dominant pattern in SMB accounting software places the general ledger, chart of accounts, and transaction history inside a proprietary database operated by the software vendor. Migration between platforms requires re-importing journal entries, reconciling every period, and re-linking source documents manually — a process that routinely costs thousands of dollars in accountant time. The data vault bookkeeping substrate addresses this structural lock-in by separating the canonical record from every tool that consumes it, applying the same [[worm-ledger-design|WORM ledger discipline]] used across [[three-ring-architecture|Ring 1 boundary services]]. |
| ## Three structural inversions | ## Three structural inversions |
| The substrate rests on three architectural choices that invert the hyperscaler pattern: | The substrate rests on three architectural choices that invert the hyperscaler pattern: |
| **The vault is the only canonical layer.** Source documents — invoices, receipts, purchase orders — arrive in any supported format and are stored immutably in the platform's append-only ledger. The parsed semantic fields, the original document, and a cryptographic commitment are stored together. The vault retains the original document alongside every derived representation of it; nothing is ever overwritten. | **The vault is the only canonical layer.** Source documents — invoices, receipts, purchase orders — arrive in any supported format and are stored immutably in the platform's append-only ledger. The parsed semantic fields, the original document, and a cryptographic commitment are stored together. The vault retains the original document alongside every derived representation of it; nothing is ever overwritten. |
| **Bookkeeping and accounting are separate concerns.** The bookkeeping application is a read surface: it allows browsing, auditing, searching, and exporting from the vault. The accounting application is a productive surface: it generates trial balances, financial statements, and tax compliance documents. The customer's accountant can use any tool — including tools the vendor has no relationship with — against the vault export. The vendor does not own the accounting logic; it owns the vault platform, not the data within it. | **Bookkeeping and accounting are separate concerns.** The bookkeeping application is a read surface: it allows browsing, auditing, searching, and exporting from the vault. The accounting application is a productive surface: it generates trial balances, financial statements, and tax compliance documents. The customer's accountant can use any tool — including tools the vendor has no relationship with — against the vault export. The vendor does not own the accounting logic; it owns the vault platform, not the data within it. |
| **No accounting logic lives inside the vault.** The vault stores facts; consumers compute derived views. Migration away from the accounting tool is structurally costless: the vault remains intact, the new tool replays the ledger, and the derived views are rebuilt from the same canonical source. | **No accounting logic lives inside the vault.** The vault stores facts; consumers compute derived views. Migration away from the accounting tool is structurally costless: the vault remains intact, the new tool replays the ledger, and the derived views are rebuilt from the same canonical source. |
| ## Three layers | ## Three layers |
| The substrate has three architectural layers: | The substrate has three architectural layers: |
| **The vault layer** organizes parsed invoice data into a flat-file structure with three directories: `/source` (the original documents, immutable, SHA-256 hashed), `/ledger` (the double-entry journal, append-only, cryptographically signed per row), and `/asset` (materialized derived views of account balances, rebuildable from the ledger by replay and never the source of truth). Corrections to journal entries are compensating entries, never row edits. | **The vault layer** organizes parsed invoice data into a flat-file structure with three directories: `/source` (the original documents, immutable, SHA-256 hashed), `/ledger` (the double-entry journal, append-only, cryptographically signed per row), and `/asset` (materialized derived views of account balances, rebuildable from the ledger by replay and never the source of truth). Corrections to journal entries are compensating entries, never row edits. |
| **The bookkeeping layer** provides the read-mostly query surface: browse journals by date, account, vendor, or amount; view source documents inline; run full-text searches; export to CSV with source-document references preserved. The bookkeeper uses this layer for daily entry and audit work. | **The bookkeeping layer** provides the read-mostly query surface: browse journals by date, account, vendor, or amount; view source documents inline; run full-text searches; export to CSV with source-document references preserved. The bookkeeper uses this layer for daily entry and audit work. |
| **The accounting layer** provides the productive surface for trial balance generation, financial statement preparation, and tax compliance work. It reads from the vault export and produces documents using whichever accounting tool the customer chooses. The vault export is the interface; no single accounting tool is required. | **The accounting layer** provides the productive surface for trial balance generation, financial statement preparation, and tax compliance work. It reads from the vault export and produces documents using whichever accounting tool the customer chooses. The vault export is the interface; no single accounting tool is required. |
| ## E-invoicing native support | ## E-invoicing native support |
| European regulatory mandates are making structured electronic invoice formats — EN 16931-compliant XML in the Peppol and ZUGFeRD specifications — compulsory for business-to-business transactions on a rolling schedule from 2025 to 2028. The substrate is designed to ingest these formats natively alongside PDF invoices. The United States does not have a comparable federal mandate as of 2026; PDF remains dominant, though the FedNow instant-payment network carries ISO 20022 remittance data that the substrate is intended to support. | European regulatory mandates are making structured electronic invoice formats — EN 16931-compliant XML in the Peppol and ZUGFeRD specifications — compulsory for business-to-business transactions on a rolling schedule from 2025 to 2028. The substrate is designed to ingest these formats natively alongside PDF invoices. The United States does not have a comparable federal mandate as of 2026; PDF remains dominant, though the FedNow instant-payment network carries ISO 20022 remittance data that the substrate is intended to support. |
| ## Audit and assurance | ## Audit and assurance |
| The substrate's structure satisfies the chain-of-custody requirements of ISAE 3402 Type II and SOC 2 Processing Integrity by construction: | The substrate's structure satisfies the chain-of-custody requirements of ISAE 3402 Type II and SOC 2 Processing Integrity by construction: |
| - Original source documents are retained immutably alongside their parsed representations. | - Original source documents are retained immutably alongside their parsed representations. |
| - Journal entries reference their source documents and are cryptographically signed by an authorized identity. | - Journal entries reference their source documents and are cryptographically signed by an authorized identity. |
| - The append-only ledger property means retroactive modification is structurally impossible without detection. | - The append-only ledger property means retroactive modification is structurally impossible without detection. |
| - Monthly anchoring to a public transparency log produces independently verifiable evidence that the ledger state at each checkpoint has not been altered. | - Monthly anchoring to a public transparency log produces independently verifiable evidence that the ledger state at each checkpoint has not been altered. |
| A quarterly attestation report cites these properties explicitly. An auditor can verify the attestation independently using publicly available verification tooling, without relying on the vendor's characterization of their own controls. This is a categorically different property from a vendor's SOC 2 report, which attests the vendor's controls over the vendor's infrastructure rather than the customer's data integrity. | A quarterly attestation report cites these properties explicitly. An auditor can verify the attestation independently using publicly available verification tooling, without relying on the vendor's characterization of their own controls. This is a categorically different property from a vendor's SOC 2 report, which attests the vendor's controls over the vendor's infrastructure rather than the customer's data integrity. |
| ## Why structural lock-in cannot be replicated at enterprise cloud scale | ## Why structural lock-in cannot be replicated at enterprise cloud scale |
| Enterprise cloud accounting platforms cannot structurally offer per-tenant immutable vaults with per-tenant signing identities because their business model depends on customer stickiness that per-tenant vault portability would eliminate. The architectural separation of vault from accounting destroys the switching cost that is the moat; no platform that depends on that moat can offer the separation voluntarily. | Enterprise cloud accounting platforms cannot structurally offer per-tenant immutable vaults with per-tenant signing identities because their business model depends on customer stickiness that per-tenant vault portability would eliminate. The architectural separation of vault from accounting destroys the switching cost that is the moat; no platform that depends on that moat can offer the separation voluntarily. |
| ## Working pattern: domain-expert apprenticeship | ## Working pattern: domain-expert apprenticeship |
| The behavioral specification for the bookkeeping substrate is intended to emerge from real operations performed by an actual domain expert — capturing the procedural knowledge of how bookkeeping work is done before writing software to automate it. This inverts the common pattern of building software from a product hypothesis. The eventual software inherits its behavioral specification from observed operations rather than from assumptions about what operations look like. This is planned for the initial development phase; actual outcomes depend on the scope and cadence of those operational sessions [ni-51-102]. | The behavioral specification for the bookkeeping substrate is intended to emerge from real operations performed by an actual domain expert — capturing the procedural knowledge of how bookkeeping work is done before writing software to automate it. This inverts the common pattern of building software from a product hypothesis. The eventual software inherits its behavioral specification from observed operations rather than from assumptions about what operations look like. This is planned for the initial development phase; actual outcomes depend on the scope and cadence of those operational sessions [ni-51-102]. |
| ## See also | ## See also |
| - [[compounding-substrate]] — the substrate sovereignty pattern this architecture extends | - [[compounding-substrate]] — the substrate sovereignty pattern this architecture extends |
| - [[worm-ledger-design]] — the WORM ledger substrate this bookkeeping layer depends on for immutable audit trails | - [[worm-ledger-design]] — the WORM ledger substrate this bookkeeping layer depends on for immutable audit trails |
| - [[design-system-substrate]] — a parallel substrate with the same vault-as-canonical, consumer-as-interchangeable pattern | - [[design-system-substrate]] — a parallel substrate with the same vault-as-canonical, consumer-as-interchangeable pattern |