Compliance
Built for GoBD-relevant requirements. Audit-proof. Immutable.
LedgerLou provides technical functions that support GoBD-relevant requirements: an append-only ledger, cryptographic audit hashes, irreversible period closings and complete document linking are not add-on features but core building blocks of the architecture. Whether a specific set of books is GoBD-compliant in a concrete case additionally depends on the configuration, usage, data completeness and internal controls of the taxpayer.
What is the GoBD?
The Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form sowie zum Datenzugriff (GoBD) define the German tax authorities’ requirements for electronic bookkeeping systems. They apply to every company that keeps its books in digital form and form the basis for tax audits carried out by the Finanzamt.
The GoBD prescribes:
- How postings must be recorded and retained
- That subsequent changes must be logged or prevented
- What access rights tax auditors have to bookkeeping data
- How long records must be retained (10 years)
GoBD requirements and the LedgerLou implementation
1. Immutability and completeness
“Every entry must be made in such a way that it cannot be changed without leaving a trace of the change.” — GoBD margin no. 91
ledger_events table is technically append-only. A database rule (PostgreSQL trigger) blocks every UPDATE and DELETE on ledger entries — even for database administrators. There is no API endpoint and no admin function to delete or modify postings.2. Traceability and audit trail
“The bookkeeping must be structured in such a way that it enables an expert third party to obtain an overview of the business transactions within a reasonable amount of time.” — GoBD margin no. 30
ledger_event receives a SHA256 hash over its core fields (amount, accounts, date, description, tenant) at write time. The hash is stored with the entry and can be used to verify data integrity at any time.created_at (UTC), booking_date (economic date) and — for reversals — a reference to the original posting ID. Every action is attributed to a user ID or an API key.3. Timeliness of recording
“Cash receipts and cash payments shall be recorded daily.” — GoBD margin no. 47
Postings can be recorded with any economic date (booking_date). The technical recording date (created_at) is stored separately — the time gap between the economic date and when it was recorded is therefore auditable for every entry.
The GoBD requirement for timely recording is considered met when postings are recorded within 10 days of the economic event. LedgerLou does not enforce this deadline technically, but makes it visible and verifiable for every entry through the timestamp comparison.
4. Period closing and period integrity
locked) cannot be reopened. There is no API, no admin command and no database operation to unlock them. The database trigger check_period_lock() blocks every attempt to post into locked periods at the database level.SHA256(tenant_id | period | last_audit_hash). This hash chains the closing to the immutable ledger state at the moment of locking — any subsequent manipulation would invalidate the hash.5. Document retention and duplicate protection
“Every posting must be based on a document.” — GoBD margin no. 65
6. Data access for tax auditors (Z1 / Z2 / Z3)
“Upon request, the taxpayer must provide data to the auditor in a machine-evaluable form.” — GoBD margin no. 164
The GoBD defines three access types for tax audits:
7. Retention periods
“Books of account must be retained for 10 years.” — § 257 HGB, § 147 AO
8. Data security and tenant isolation
app.current_tenant — rows belonging to another tenant are technically invisible, even in the case of faulty application logic.api.mistral.ai) — no data leaves the EU.admin scope is never delegable via OAuth or MCP.