Human approval and auditability in AI-assisted bookkeeping

Approval is a chain, not one button

One person may perform several layers under an engagement, but the system should not collapse them. “Approved” must state what was approved and what was not.

The minimum approval record

A reviewable approval should contain:

1. the object and version being approved;
2. original sources and relevant extracted facts;
3. owner-supplied facts and who supplied them;
4. the prepared result and its financial or workflow effect;
5. open exceptions, assumptions, and professional boundaries;
6. changes since the last review;
7. reviewer identity, role, permission, time, and action;
8. the reason for approval, change, rejection, or return;
9. which downstream actions the approval enables;
10. which later changes invalidate it.

This record should be understandable without exposing private prompts, scores, mappings, or internal system architecture.

Synthetic example: approval must reopen

The example is invented.

Elbwinkel Beratung GmbH uploads an invoice from Cloud North Ltd for €1,190.00. Because the supplier usually bills €119 software subscriptions, the first prepared proposal follows the recurring supplier context. The current invoice, however, says “two-day staff training”.

The correct workflow is:

1. The source invoice is preserved and its amount and description are shown.
2. The system marks the difference from the recurring pattern.
3. The owner confirms that six employees attended training and that the normal software invoice is separate.
4. The bookkeeper attaches the answer and prepares a revised proposal rather than reusing the recurring one.
5. The accountant reviews the source, owner fact, payment context, and revised effect, then changes or approves it.
6. The decision record states what changed and who approved the revised proposal.

If a corrected invoice later changes supplier, amount, or service, the approval is no longer valid. The case returns to review. Keeping the old green check would preserve an action but lose the reason it was justified.

Traceability means that the path from source to decision remains understandable. It does not mean that every recorded decision was professionally correct.

What a reviewer must be able to do

Inspect

Open the original source, owner answer, relevant payment or payout, prepared calculation, proposal lines, and exception reason without reconstructing the case from separate inboxes.

Challenge

Change an extracted fact, reject a match, edit or return a proposal, request evidence, and explain why. Human oversight is weak if the only available action is confirmation.

Understand impact

See which later artifacts depend on the decision: settlement status, open items, period readiness, export package, or another approval. The reviewer should know whether a change will reopen those artifacts.

Act within authority

Identity alone is insufficient. Permissions and engagement scope determine whether a person may prepare, professionally approve, post, export, sign, or file.

Overrides and exceptions

An override should be rare enough to deserve a reason but possible when evidence supports it. Record:

• the original signal or blocking condition;
• the evidence considered;
• who overrode it and under what role;
• the reason and affected scope;
• any follow-up control;
• whether the override is one-time or changes future preparation.

Do not use an override to hide a missing source or bypass a professional decision. If the evidence is absent, the honest state is pending or held.

GoBD and AI control boundaries

German record-keeping principles emphasise traceability, completeness, correctness, timely and ordered recording, and the ability to understand changes in context. The EU AI Act contains human-oversight duties for systems within its high-risk scope. Whether a particular system or use falls into a legal category and which controls are sufficient requires qualified assessment.

This article therefore uses a conservative operational rule: preserve source, change, decision, actor, and downstream effect. Do not market an approval log, an AI signal, or a single product feature as proof of GoBD or AI Act compliance.

How DeinHans fits

DeinHans is designed to prepare evidence-linked cases, questions, matches, payout reconstructions, and booking proposals for human review. Where the workflow exposes source, proposal, exception, and reviewer action, it can support a more inspectable handoff than an unexplained automated result.

Availability and depth vary by workflow. DeinHans does not claim that every event layer is publicly visible, that an audit entry certifies compliance, or that a software action assumes professional responsibility. A qualified reviewer remains responsible for the decisions their role and engagement require.

Approval-quality checklist

• The exact approval object and version are named.
• Original evidence is available and unchanged.
• System inference and verified fact are distinct.
• Owner facts are attributable.
• Financial and workflow effect is visible.
• Open exceptions and limitations sit beside the decision.
• Reviewer identity, role, permission, time, action, and reason are recorded.
• Change, reject, return, and hold are real options.
• Material changes invalidate dependent approval.
• Downstream posting, export, signing, and filing require their own authority.
• The record can be understood without private implementation detail.
• Professional and legal review is obtained where required.

Approval becomes useful when it tells the next person exactly which evidence and judgement they may rely on—and where that reliance stops.