German Federal Ministry of Finance circular of 28 November 2019, last amended 2024; Sections 146, 147 AO

What the GoBD require when an AI agent touches the books, and what Logsiegel contributes

The GoBD, the German principles for the proper keeping of books and records in electronic form, require that every posting and every change is recorded traceably and unalterably. As soon as an AI agent reads invoices, matches source documents or prepares postings, it becomes part of that process, and the tax audit will ask what it did and when.

Who this applies to

Every business in Germany that is required to keep books and that uses AI in document processing, invoice capture, account assignment or dunning, plus tax advisers and vendors of accounting software who offer such agents. The principles apply regardless of whether a person or a program does the preparatory work.

What the regulation requires in terms of records

The relevant margin numbers of the ministry circular and the statutory basis:

Reference	Requirement
Para. 30 to 35	Traceability and verifiability: an expert third party must be able to get an overview of the business transactions within a reasonable time; processing must be traceable without gaps (progressive and retrograde verifiability).
Para. 58 to 60	Unalterability: a posting or record must not be changed in such a way that the original content can no longer be established. Changes are to be logged, in a way that keeps the time and the content of the change visible.
Para. 36 to 57	Completeness, accuracy, timely capture, order: every business transaction is to be captured completely and promptly.
Para. 151 to 155	Process documentation: a description of the data processing procedure including the programs used, the controls and the retention. An AI agent belongs in that description.
Section 146(4) AO	The statutory basis of unalterability: postings and records must not be changed in such a way that the original content can no longer be established.
Section 147 AO	Retention: books and records for ten years, accounting source documents for eight years after the 2025 reduction; data access by the tax administration (Z1 to Z3).

What Logsiegel contributes today

A trail alongside the accounting system. Logsiegel does not replace the change history of your accounting software. It records what the agent did: which input (hash of the source document), which model, which output (hash of the proposed posting), and when. That makes the AI part of the procedure traceable, as para. 30 et seq. require.
Unaltered records, verifiable. Every entry is hash-linked to the one before it; at intervals a Merkle root is formed and signed with Ed25519 (a checkpoint). Any later edit, reorder or truncation makes logsiegel verify fail. For the tax auditor that means: the agent's trail is unalterable in the sense of para. 58 et seq., and they can recompute that themselves.
Human approval as an event. When an employee approves or rejects the agent's proposal, that is an entry of its own. The chain shows: proposal, review, approval, in that order.
Retention you can prove. A signed checkpoint shows that at a given moment the trail had a certain length and a certain content. Anyone who truncates it later stands out against every checkpoint or receipt handed out earlier. Across eight or ten years of retention, that is the difference between an assertion and evidence.
A readable dossier. logsiegel export writes the trail as a Markdown dossier for people who do not want to touch a command line. As an annex to the process documentation and for the tax administration's data access.
Single-entry receipts for third parties. logsiegel receipt builds a file for one single action, made of the entry, an inclusion proof and a signed checkpoint. An auditor, customer or court verifies it offline against your published key, without access to your systems and without seeing the rest of the trail.

What is in progress planned

Qualified timestamps, so that timely capture (para. 45 et seq.) does not hang on the operator's clock alone.
Retention policy with provable expiry of the period.

What Logsiegel does not do

Not an accounting system. Logsiegel does not post, does not keep accounts and does not replace the unalterability and change history in your accounting software. It records what the agent did, alongside.
Process documentation. It has to describe the agent; Logsiegel supplies the “logging” part, not the document.
Substantive accuracy. Whether the agent assigned the right account is not something a log can show. It shows what the agent proposed and who approved it.
Certification. There is no GoBD certification, neither for Logsiegel nor for any other software; the ministry circular says so explicitly (para. 179 et seq.).
Completeness. What is proven is that the recorded material is unaltered, never that everything was recorded. That is an integration question: the adapter has to sit at a point every action must pass (LiteLLM today, MCP proxy in progress).
Protection against the operator itself. Whoever holds the signing key could rewrite the trail and sign it again. That comes to light precisely when somebody else holds an earlier checkpoint or receipt. So hand your checkpoints out; counter-signing by an independent witness is the next stage of the project.
Time. Timestamps in the trail are a claim by the operator until they are counter-signed by a witness or by a qualified timestamping service.
Legal assessment. Whether your system falls under the regulation, which duties apply in detail and whether a receipt is enough in a given case is decided by your legal or compliance review, not by this tool.

How to put it to work

1. Install it and create a trail

The SDK is Python, Apache 2.0, no server and no account. The origin (origin) names the system whose actions are being recorded.

pip install logsiegel
logsiegel init ./trail --origin "acme.example/support-agent"

2. Plug the adapter in at the point every action must pass

If your AI traffic runs through LiteLLM, every completion becomes a signable inference entry, and errors are recorded as an anomaly. Human interventions you record explicitly, as an event of their own.

import litellm
from logsiegel.integrations.litellm_logger import LogsiegelLogger

litellm.callbacks = [LogsiegelLogger("/var/lib/logsiegel/prod", store_payload=True)]

3. Record approvals

Every approval or rejection of an agent proposal becomes an entry with the person handling it and a reference to the original proposal.

logsiegel log ./trail --event human_override \
  --attr actor="accounting@acme.example" --attr decision=approved --attr ref_seq=1284

4. Create checkpoints and hand them out

Create checkpoints regularly (via cron, for instance) and put them outside your own infrastructure: with the auditor, with the customer, in someone else's repository. Only a checkpoint you no longer control alone makes the trail hold up against yourself.

logsiegel checkpoint ./trail
logsiegel verify ./trail

5. Put the trail and the checkpoints into the process documentation

Describe in the process documentation that the agent's actions are recorded with Logsiegel, where checkpoints are filed, and how verification with logsiegel verify and the dossier export work for the tax administration's data access.

More regulations: EU AI Act GDPR DORA NIS2 / critical infrastructure ISO/IEC 27001 ISO/IEC 42001 eIDAS Overview

Legal status September 2026. This page is a technical assessment by the project, not legal advice and not a conformity statement. Please check the references against the current text of the law. Corrections welcome via GitHub issue.