Git as an Audit Trail

August 21, 2026 · 5 min read

Most ERP systems have an "audit log." It is a database table where the application writes a row every time someone changes something. It is better than nothing, but it is not an audit trail. It is a diary written by the system about itself — and the system can lie.

NeoDonkey does not have an audit log. It has git.

The Problem with Application-Level Audit Logs

Consider what happens when an accountant posts a journal entry in a typical ERP:

1. The application writes the booking to the database
2. The application writes a row to the audit_log table: "User 42 posted JE-1234 at 14:32"
3. If the admin has database access, they can delete both rows
4. The audit log is now a lie, and there is no way to detect it

Some systems add "tamper-evident" hashes — each audit log row contains a hash of the previous row. This is better, but the hash algorithm and the verification code are part of the application. If an attacker compromises the application, they compromise the verification too.

Git Commits as Immutable Records

In NeoDonkey, every business document is a git commit. Not a row in a table — a commit in a git repository. This is not a metaphor. You can literally run git log in your company's folder and see every booking, every invoice, every goods receipt.

A git commit has properties that make it ideal for audit trails:

• Cryptographic chain: Each commit contains the hash of its parent. Change any commit in history, and every subsequent commit's hash changes.
• Content-addressed: A commit's ID is a hash of its contents. You cannot alter a commit without changing its ID.
• Detached from the application: The git repository is a plain folder of files. You can verify it with standard git tools, completely independent of NeoDonkey.

Ed25519 Signatures on Every Commit

Every commit is signed with the author's Ed25519 key. The signature is stored in the commit's gpgsig field and can be verified with standard git tools:

$ git verify-commit HEAD
gpg: Signature made Fri Aug 21 14:32:00 2026 CET
gpg:                using EDDSA key 7A3B...
gpg: Good signature from "Sarah Weber <sarah@neodonkey.eu>"

This means:

• You know who made every change
• You know when they made it
• You can prove it in court (Ed25519 signatures are legally binding in the EU)
• An attacker cannot forge a signature without the private key

The Kernel Enforces It

The signing is not optional. The NeoDonkey kernel (runtime/kernel.js) will not create a commit without a valid signature. The flow is:

1. User submits intent (e.g., "create journal-entry JE-001")
2. Operating model validates the intent
3. Kernel constructs the commit object
4. Kernel signs the commit with the user's Ed25519 key
5. Kernel writes the commit to the git repository
6. If signing fails, the entire operation is aborted

There is no "disable signatures" flag. There is no admin override. The signature is the commit.

Where the Code Lives

• runtime/kernel.js — The main kernel, handles commit creation and signing
• runtime/identity/ed25519.js — Ed25519 key generation and SSH signature format
• runtime/identity/sshsig.js — SSH signature encoding and verification
• runtime/git/repo.js — Pure-JS git implementation, no Node dependencies
• runtime/truth/authority.js — Role-based access control, signed into commits

What This Means for Auditors

When a German tax auditor (Finanzamt) asks for your GoBD-compliant records, you hand them a folder. They can:

1. Verify every commit with git verify-commit
2. Check the full history with git log
3. Confirm no commits were altered with git fsck
4. Export the entire ledger to DATEV format with one command

No proprietary tool required. No "trust us, our audit log is secure." Just git, the same tool that powers the Linux kernel.

NeoDonkey is an open-source ERP that stores your company as a git repository. Every booking is a signed commit. Try the demo.