Art. 957a CO and AI bookings: audit trail, GeBüV, and 10-year retention

What does Art. 957a CO say?

Art. 957a of the Code of Obligations (CO, SR 220) governs the principles of proper bookkeeping in Switzerland. Introduced with the bookkeeping law revision on 1 January 2013, the article – together with Art. 957-963b – covers the entire field of commercial bookkeeping and financial reporting. It applies to all sole proprietorships subject to registration (turnover > CHF 500,000), to partnerships, to legal persons, and to associations and foundations subject to registration.

The article sets out five principles in paragraph 2: complete, truthful and systematic recording of business events and circumstances (point 1), documentary evidence for individual entries (point 2), clarity (point 3), fitness for purpose with regard to the nature and size of the company (point 4), traceability (point 5). These five principles sound abstract but have been concretised by the Business Records Ordinance (GeBüV, SR 221.431) and by EXPERTsuisse recommendations since 2013.

For AI-assisted bookkeeping, paragraph 2 point 5 – traceability – is the central anchor. Whoever sends a receipt through an OCR model + a language model + a booking suggestion must be able, in the end, to reconstruct: which receipt, which fields recognised, which suggestion, which model, which version, which human review – all repeatable for an auditor 10 years after the booking.

Why it is critical for AI bookings

Three risks make Art. 957a CO a mandatory discipline for AI projects.

First: auditability. Ordinary or limited audits under Art. 727 ff CO verify that bookkeeping complies with statutory rules and complementary standards (e.g. Swiss GAAP FER, IFRS). An AI-generated entry that cannot be traced leads to qualified audit reporting – in the worst case, refusal of the opinion. EXPERTsuisse in 2024, in the "recommendation on audit trail for automated bookings", formulated concrete duties: model identification, input snapshot, output snapshot, human approval.

Second: 10-year retention. Art. 958f CO requires 10 years of retention for the books, the booking vouchers, and the annual report. The period starts at the end of the fiscal year. For AI bookings, this is a pitfall: the language model used in 2026 will no longer exist in the same version in 2036. Model outputs are reconstructable only if model version + prompt + input are stored. That does not mean "keep the model itself", but: document the trace so that an audit today can reproduce the operation – even when the original model no longer responds.

Third: GeBüV conformity for electronic retention. Where bookkeeping and vouchers are kept electronically – the standard in 2026 – Art. 9 and 10 GeBüV apply: write-protected media or procedural measures (e.g. hash chains, blockchain anchors, signed logs) that record or prevent later alteration. Readability must be preserved throughout the retention period. Format lock-in is real: a proprietary LLM API logging format without an export path may no longer be readable in 5 years.

What must be in the audit trail

A defensible audit trail for AI-assisted bookings has seven fields per booking. These fields are derived from the EXPERTsuisse 2024 recommendation, the FINMA Operational Risks Circular, and GeBüV.

1. WHO triggered it. User ID of the operator or system identifier of the automated process. For batch processing: the cron job name and identification of the natural person who owns the automation.

2. WHAT was the input. The original receipt (PDF, image, email attachment) with a hash value (SHA-256 recommended). For pre-processing (OCR, image resize): also hash and reference the intermediate result.

3. WHEN – exactly. ISO-8601 timestamp in UTC, ideally with separate time-stamping by a trusted source (e.g. RFC 3161 Time-Stamp or blockchain anchor). Sequence counter per day for unambiguous ordering.

4. WITH WHAT – model version. Full identification: provider (OpenAI), model name (gpt-4o-2024-08-06), API version, temperature, max_tokens, all other parameters. For multi-LLM setups (see multi-llm-gateway): additionally the router decision and the actually queried model.

5. WHAT was the prompt. The full system prompt and user prompt. For templating: the template version + the inserted variables. Sensitive personal data may be hashed or pseudonymised before storage – but the audit trail must keep the pseudonymisation logic.

6. WHAT was the response. The full model output, before any post-processing. For tool-use or structured-output: the raw JSON.

7. WHO approved it. The human review. User ID, timestamp, changes to the model suggestion (diff). For fully automated booking without human review: explicit "auto-posted" marking and reference to the validation rule that permitted this without a human (e.g. threshold "suggestion < CHF 100 + confidence > 0.95").

The trail must be immutable (append-only) and exportable. Storage typically in (a) PostgreSQL with row versioning + triggers, (b) S3-compatible storage with object lock, or (c) WORM storage. Cloud provider logs alone are not enough – the client must own the data.

Audit trail setup in 7 steps

1. 01Inventory: which AI steps touch bookings directly or indirectly? Build the map.
2. 02Per step, decide: full trail (7 fields), reduced trail (3-4 fields), no trail.
3. 03Choose storage: PostgreSQL with append-only tables + triggers, or S3 with object lock, or WORM NAS. Cloud logs are not sufficient.
4. 04Define model identification: provider, model, version, all parameters – schema defined and versioned.
5. 05Version the prompt templates: each prompt has a version ID, changes are tracked in git.
6. 06Hash strategy: input receipt + output answer are SHA-256 hashed, hashes go into the trail. Optionally anchor a hash chain with RFC-3161 time-stamp.
7. 07Build the export path: the audit trail must be exportable to an open format (JSON, CSV, PDF), even when the LLM provider account is closed in 5 years.

When a full audit trail is mandatory

Mandatory in four cases. First: bookings within the meaning of Art. 957a CO – i.e. all that flow into the books, regardless of amount. Second: receipt capture with OCR and AI classification (account suggestion, VAT-code suggestion, cost-allocation suggestion). Third: reporting to tax authorities where AI was involved in preparation. Fourth: forensic cases – on suspicion of bookkeeping manipulation, the AI trace must be reconstructable to classify the AI as the source of the error or as an uninvolved auxiliary step.

Not mandatory but strongly recommended: any AI-assisted suggestion that could later become a booking. This includes client chatbot answers with a bookkeeping nexus ("which VAT rates apply for ...") – even where the answer itself triggers no booking, it can become evidence.

When the full trail is excessive

Not every LLM call needs a 7-field audit trail. Proportionality under Art. 957a para. 2 point 4 CO ("fitness for purpose with regard to nature and size") permits leaner solutions where the risk is low.

Reduced trail (3-4 fields) is acceptable for: (a) answers without booking nexus – internal guideline search, language check of email drafts, summary of client phone notes; (b) preparatory research without output use in the books; (c) test and evaluation phases before production use.

No trail needed for: purely internal brainstorming, code generation for tooling (not bookkeeping-related), marketing content creation.

Caution at the boundary: what starts as "no booking nexus" can drift into booking nexus over months as the workflow expands. Recommendation: when in doubt, activate the full trail and accept the storage cost – typically < CHF 0.01 per booking.

This is not legal advice. Audit-trail requirements are still in flux at auditors and tax authorities in 2025/2026. For your own setup, alignment with your own auditor is strongly recommended before going live with AI bookings.

Trade-offs

FAQ

Related topics

Sources

1. Obligationenrecht (OR, SR 220) – Art. 957a, Fedlex Volltext · 2024-01
2. Geschäftsbücherverordnung (GeBüV, SR 221.431) – Fedlex Volltext · 2024-01
3. EXPERTsuisse – Empfehlungen zu Art. 957a OR und Digitalisierung · 2024-09
4. FINMA-Rundschreiben 2008/21 Operationelle Risiken Banken · 2024-01
5. ESTV – Eidgenössische Steuerverwaltung, Hinweise zur Buchführung · 2026-03