Audit trail in accounting: what GoBD requires, and how AI agents fit in it

An audit trail in accounting is the unbroken record that links every booking to its source document, the person or system that created it, the approval, and every later change. In Germany, § 146 (4) of the Fiscal Code (AO), § 239 (3) of the Commercial Code (HGB) and the GoBD (German digital bookkeeping rules) require that the original entry stays visible, that changes are logged, and that the log itself cannot be altered.

Many finance teams treat the audit trail as a technical log that IT keeps somewhere. Under German rules it is more than that: it is the evidence that the process you describe on paper is the process that actually ran. When AI prepares bookings, that evidence gets easier to produce, not harder, as long as every suggestion and every human decision is an entry in the same trail.

---

What does an audit trail in accounting have to show?

An auditor, whether from the tax office or an audit firm, usually starts from one number and works backwards. Take a supplier invoice booked to consulting costs in March. The audit trail has to answer five questions about it without anyone searching their inbox:

1. Where did it come from? The original document, received and stored unchanged.
2. Who created the booking, and when? A named user or a clearly identified system process, with a timestamp.
3. On what basis? The account, cost centre and VAT treatment chosen, and why.
4. Who approved it? A person other than the preparer where your rules ask for that.
5. What happened afterwards? Every correction, reversal, payment and lock, each with its own author and time.

If any link is missing, the trail breaks at that point. A booking without a document fails the voucher principle. A booking that was edited without a record fails the rule on unchangeability. An approval that lives in an email is outside the books entirely, which is why we argue for approval at the ledger rather than by email.

What does German law require?

The legal core is short. Under § 146 (4) AO and § 239 (3) HGB, an entry may not be changed in a way that makes its original content impossible to determine, and it must remain clear whether a change was made at the time of the original entry or later. The GoBD, the administrative guidance from the Federal Ministry of Finance (BMF), turn that into requirements for software.

The principle is called Unveränderbarkeit (unchangeability). The GoBD name automatic logging, history and versioning as the ways to achieve it, and they say plainly that a normal file system usually does not meet the standard on its own. Three details are easy to miss:

• Settings count too. Changes to the configuration of the software, such as posting rules or parameters, must be logged, not just changes to bookings.
• The log is protected as well. A change history must not itself be editable later. A log that an administrator can clean up is not an audit trail.
• Controls must leave evidence. The GoBD require an internal control system (IKS) whose controls are set up, carried out and logged. We cover what that means in practice in internal controls in accounting.

The trail has to survive as long as the records it explains. Retention periods and archive formats are covered in archiving under GoBD. During a tax audit, the inspector may also ask for direct access to the data or an export under § 147 (6) AO, so the trail must be readable by someone who has never used your system.

Which changes do finance teams forget to log?

Most accounting software logs edits to bookings. The gaps sit around the bookings, in places that change the result without touching a single entry directly.

Master data. A changed bank account on a supplier record is the classic route for payment fraud, and a changed VAT ID can break an input VAT claim. Who changed it, when, and who confirmed it should be as visible as a booking change.

Rules and mappings. If an automation rule sends all invoices from one supplier to a different account from next month, every booking that follows depends on that change. Under the GoBD logic on settings and parameters, the rule change itself belongs in the trail.

Access rights. A user who was given posting rights for one week during the close, and kept them for a year, is a control problem. Rights changes need a date and an author.

Reopened periods. Reopening a locked month to post a late correction can be legitimate. It should never be silent. The reopen, the reason, the postings made and the new lock belong together.

How do AI agents fit into the audit trail?

German law does not mention AI, and it does not need to. A process that creates bookings has to meet the same rules whether a clerk, a script or an agent performs it. The practical question is what an agent's entry in the trail must contain, so that a reviewer can follow it in two years' time.

A useful log entry for an AI suggestion holds seven things:

• Actor: the agent, identified as a system actor and never hidden under a human user name.
• Input: the document or data it worked from, linked, not copied.
• Proposal: the booking it suggested, with account, cost centre, VAT code and amount.
• Basis: what the suggestion rests on, for example earlier bookings for the same supplier or a named rule.
• Confidence: the score the system gave the suggestion.
• Decision: who accepted, changed or rejected it, and when. If the person changed the account, both versions stay visible.
• Version: which rule set or model produced the suggestion, so a change in behaviour can be traced to a change in configuration.

Structured this way, an agent makes the trail more complete than a manual process does. A person rarely writes down why each account was chosen. An agent records it every time. What it must not do is post silently. We explain where agents need approval in AI agents for finance.

What belongs in the procedural documentation when AI is involved?

The procedural documentation (Verfahrensdokumentation) describes how your bookkeeping works, from receiving a document to storing it. The GoBD expect it to be complete and current, and the description of the internal control system is part of it. An auditor reads it next to the trail and checks whether the two match.

For an AI-assisted process, add four points to it:

1. What the system may suggest, and what it may never do without approval.
2. The thresholds: which suggestions a person must review, by amount, account, confidence or supplier.
3. Who approves what, and how segregation of duties is kept when the approver also maintains the rules.
4. How rules and models change: who may change them, how a change is tested, and where the change is logged.

The GoBD also expect an event-based check that the system in use still matches the documented one, for example after a system change. Switching on a new automation is such an event. If the documentation says every invoice above a set amount needs a second approval, the trail should prove it for every one of them. Our guide on tax audit preparation explains what inspectors look at first.

How does Agent F keep the audit trail in the ledger?

In Agent F, the audit trail is part of the same data model as the bookings, documents and approvals.

When an invoice arrives, the original is stored with the record. The AI layer suggests account, cost centre and VAT treatment from your own booking history, each with a confidence score, and the suggestion is logged as a system action. A person approves, changes or rejects it. Only then is it posted, and the approval is linked to the entry rather than sitting in an email.

Every later step adds an entry: corrections as visible reversing bookings, payments matched from the bank, period locks after the close. Changes to supplier master data, automation rules and user rights are logged with author and time. The audit trail is immutable, and data is hosted in Germany. When your tax advisor (Steuerberater) receives the DATEV export, the bookings come from the same records an auditor would trace.

To test your own trail, pick five bookings from last quarter and try to answer the five questions above for each, without asking a colleague. Then check whether a supplier bank detail change and an automation rule change from the same period can be found with author and date. Finally, compare your procedural documentation with what your team actually does today. Where the answers depend on someone's memory, that is where the trail needs work.

Learn how Agent F works, or see it on your own bookings at agent-f.ai/demo.