Real‑Time Auditing & Continuous Auditing

Teil 1 – Warum sich Prüfung grundlegend verändern muss

1.1 Die Krise des traditionellen Prüfungsmodells

Das bisherige Modell erzeugt drei fundamentale Probleme:

1) Zeitverzögerung

Fehler, Fraud, Wertminderungsindikatoren oder Prozessbrüche werden zu spät entdeckt.

2) Stichproben statt Vollprüfung

3) Papier‑IKS statt wirksamer IKS

Regulatoren verlangen schon lange tatsächliche Wirksamkeit – faktisch erfüllen viele Unternehmen das nur auf dem Papier.

1.2 Regulatorische Treiber (FISG, SOX, UK‑Code, EU‑Regulierung)

🇩🇪 FISG – Finanzmarktintegritätsstärkungsgesetz

Nach Wirecard fordert das FISG:

• nachweisbar wirksame IKS

• risikoorientierte Kontrollen

• verstärkte Aufsicht

• dokumentierte Wirksamkeit der Kontrollen

Real‑Time Auditing schafft:

• unveränderliche Evidenz

• permanente Kontrolle

• Token‑basierte Nachweise

• automatische Prüfung der Kontrollausführung

🇺🇸 SOX (Sarbanes‑Oxley Act) modernisierte Anforderungen

SOX‑ICFR verlangt dokumentierte Wirksamkeit von Kontrollen.Echtzeit‑Kontrollen liefern genau das.

🇬🇧 UK Corporate Governance Code

„Ongoing assurance“ wird ausdrücklich gefordert.

🇪🇺 EU‑CSRD & EU‑AI‑Act

Nachvollziehbarkeit, Dokumentation & Datenintegrität sind verpflichtend.

🇨🇭 Schweizer regulatorische Treiber für Real‑Time Auditing

Die Schweiz verfügt über einen differenzierten, modernen und stark governance‑orientierten Regulierungsrahmen, der Real‑Time Auditing nicht nur ermöglicht, sondern in vielen Bereichen implizit verlangt.

Swiss Code of Best Practice for Corporate Governance (economiesuisse)

Der Swiss Code definiert das Interne Kontrollsystem (IKS) als Trilogie aus Risikomanagement, Compliance‑Management und Finanzüberwachung und wirkt als Soft‑Law massgeblich in die Unternehmenspraxis hinein. Er verlangt eine klar verständliche, transparente und wirksame Governance‑Struktur, inklusive laufender Kontrolle und Dokumentation der relevanten Prozesse.[swissaxis.ch]

Real‑Time Auditing unterstützt diese Anforderungen, indem Kontrollereignisse automatisch, unveränderbar und nachvollziehbar dokumentiert werden.

Schweizer Obligationenrecht (OR) – Interne Kontrolle als Revisionspflicht

Art. 728a OR verlangt im Rahmen der ordentlichen Revision den expliziten Nachweis, dass ein Internes Kontrollsystem existiert.Die Revision prüft heute nicht die Wirksamkeit, aber sie fordert eine nachweisbare, dokumentierte Struktur.[grantthornton.ch]

Real‑Time Auditing liefert hierfür:

• unveränderliche Token-Ketten

• vollständige Evidenz

• dokumentierte Kontrollausführung

• Prozess‑Transparenz auf Transaktionsebene

FINMA‑Rundschreiben 2017/1 – Bankenaufsicht & Governance

FINMA verlangt bei Finanzinstituten ein umfassendes Rahmenwerk für:

• Risikoidentifikation

• Risikoüberwachung

• internes Kontrollsystem

• Governance‑Strukturen

• Dokumentationspflichten

Diese Anforderungen sind ideal mit Real‑Time Auditing abbildbar, da die FINMA besonderen Wert auf Governance, Risikokontrolle und Nachvollziehbarkeit legt.[pwc.ch]

FINMA: Interne Kontrolle & Risikomanagement als Second Line of Defence

Die FINMA betont die Bedeutung eines wirksamen, datenbasierten Kontrollsystems, das operationelle Risiken früh erkennt und transparent dokumentiert.[finma.ch]

Tokenisierung + Echtzeit‑Prüfungen sind hier der logische nächste Schritt:

• permanente Risikoüberwachung

• automatische Alerting‑Mechanismen

• klare Verantwortlichkeiten durch digitale Signaturen

IKS‑Leitfäden & SwissIKS‑Frameworks

Schweizer Fachverbände wie veb.ch, swissaxis oder swissIKS liefern Leitlinien, die ein modernes IKS als prozessorientiertes, dokumentiertes und risikoorientiertes System definieren.[swissaccounting.org], [iks.ch]

Real‑Time Auditing operationalisiert diese Prinzipien durch:

• durchgehende Prozessüberwachung

• dokumentierte Kontrollketten

• Transparenz für Management, Revision und Prüfer

Teil 2 – Tokenisierung als neues Fundament der Prüfung

2.1 Was ist Tokenisierung?

Tokenisierung ist die Transformation einer Transaktion in ein standardisiertes, kryptografisch gesichertes, unveränderbares Token.

Ein Token enthält:

• Timestamp

• Dokumenten-Hash

• Metadaten

• digitale Signaturen

• Kontrollstatus

• IAS/IFRS‑Relevanz

• Verkettungsreferenzen (Chain Hash)

Token sind damit die kleinsten auditierbaren Einheiten eines Unternehmens.

2.2 Beispiel eines audit‑fähigen Tokens im Python‑Code: Tokenisierung einer Transaktion mit Hashing, Signature & Chain

(keine externen Libraries, damit es überall läuft — Signaturen als Demo!)

Hinweis: Und somit ersichtlich, dass dass es keine Raketen-Wissenschaft sein muss ... und hier kommt der Token:

import json

import hashlib

from datetime import datetime, timezone

def hash_document(document_bytes):

return hashlib.sha256(document_bytes).hexdigest()

def create_token(event_type, amount, counterparty, previous_token=None):

timestamp_utc = datetime.now(timezone.utc).isoformat()

# Demo-Signaturen

system_signature = hashlib.sha256(f"sys-{timestamp_utc}".encode()).hexdigest()

owner_signature = hashlib.sha256(f"owner-{timestamp_utc}".encode()).hexdigest()

token = {

"token_id": f"txn_{timestamp_utc}",

"timestamp_utc": timestamp_utc,

"event_type": event_type,

"document_hash": hash_document(b"original_beleg_inhalt"),

"amount": amount,

"counterparty": counterparty,

"controls": {"three_way_match": "passed", "compliance_checked": True},

"ifrs_relevance": ["IAS 36", "IAS 38"],

"signatures": [

{"role": "system_auto", "sig": system_signature},

{"role": "cfo_release", "sig": owner_signature}

]

}

if previous_token:

# Hier passiert die magische Verkettung

prev_token_serialized = json.dumps(previous_token, sort_keys=True).encode()

chain_hash = hashlib.sha256(prev_token_serialized).hexdigest()

token["chain"] = {

"prev_token_id": previous_token["token_id"],

"chain_hash": chain_hash

}

return token # WICHTIG: Rückgabe außerhalb des if-Blocks

# --- Simulation ---

t1 = create_token("RECHNUNG_EINGANG", {"net": 5000, "curr": "EUR"}, {"vendor": "TechCorp"})

t2 = create_token("RECHNUNG_FREIGABE", {"net": 5000, "curr": "EUR"}, {"vendor": "TechCorp"}, previous_token=t1)

print(json.dumps(t2, indent=2))

Der „CFO-Check“: Was Sie in diesem Code sehen

Keine Sorge, Sie müssen kein IT-Experte sein, um die strategische Kraft dieser Architektur zu verstehen. Hier sind die drei entscheidenden Mechanismen, die dieses Modell sicherer machen als jedes klassische System:

• 1. Der digitale Fingerabdruck (document_hash): Statt Kopien von Belegen zu speichern, erzeugt das System einen eindeutigen „Hash“. Ändert jemand nachträglich auch nur einen Cent in der zugrunde liegenden PDF-Rechnung, passt der Hash nicht mehr zum Token. Das System schlägt sofort Alarm. Ergebnis: Absolute Integrität der Originalbelege.

• 2. Die manipulationssichere Verkettung (chain_hash): Jedes neue Token (z. B. die Freigabe) enthält den verschlüsselten Code des vorherigen Tokens (z. B. den Rechnungseingang). Das ist das Blockchain-Prinzip: Man kann keine Transaktion aus der Vergangenheit löschen oder verändern, ohne die gesamte Kette nach vorne hin zu zerstören. Ergebnis: Ein lückenloser, unveränderbarer Audit Trail.

• 3. Die digitale Verantwortlichkeit (signatures): Im Code sehen Sie Rollen wie system_auto und cfo_release. Jede Aktivität wird kryptografisch signiert. Damit ist jederzeit nachweisbar, wer (oder welches System) wann welche Prüfung durchgeführt hat. Ergebnis: Gerichtsfeste Dokumentation der IKS-Wirksamkeit (FISG-konform).

Warum das für Sie wichtig ist:

Klassische ERP-Datenbanken können von Administratoren theoretisch „von hinten“ manipuliert werden. Diese Token-Architektur macht das letztlich unmöglich. Sie wechseln von einem System, dem Sie vertrauen müssen, zu einem System, das Sie mathematisch beweisen können.

Teil 3 – IAS 36 und IAS 38 in Echtzeit

3.1 IAS 36 – Wertminderung in Echtzeit überwachen

IAS 36 verlangt:

externe und interne Indikatoren für Wertminderung müssen kontinuierlich beobachtet werden.

Mit Tokenisierung entsteht:

🔹 Externe Indikatoren

• Absatzrückgänge

• Preisverfall

• Rückläuferquote

• Kundeninsolvenzen

• Lieferantendistress

🔹 Interne Indikatoren

• sinkende Cash‑Flows

• Budgetabweichungen

• Qualitätsprobleme

• Prozessineffizienzen

Alle Indikatoren lassen sich triggerbasiert erkennen.

3.2 IAS 38 – Immaterielle Vermögenswerte

IAS 38 ist ideal für Real‑Time Auditing, weil:

• Entwicklungsprojekte haben Milestones, Kostenkategorien und Entscheidungsknoten.

• Fehlklassifikationen (CapEx vs. OpEx) können per Tokenisierung verhindert werden.

• Projektrisiken (Zeit, Budget, Value‑At‑Risk) lassen sich datengetrieben überwachen.

• Aktivierungskriterien werden laufend geprüft.

Beispiele für Token‑basierte IAS 38‑Trigger:

• Entwicklungsprojekt ‑> abweichende Kostenstruktur → Prüfhinweis

• Aktivierungswürdige Kosten steigen über Schwelle → Hinweis „Re‑Assessment erforderlich“

• Änderung der wirtschaftlichen Nutzbarkeit → Hinweis auf Wertminderung IAS 36

Teil 4 – Datenschutz: Privacy by Design / DSGVO

Viele Unternehmen haben Angst vor:

❗ “Wir dürfen keine Echtdaten in ein unveränderliches System schreiben!”

Lösung: Wir speichern NICHT die Daten — nur Hashes.

DSGVO‑konforme Umsetzung:

• Rohdaten bleiben im ERP

• Token enthält nur Hash

• Token speichert minimale Metadaten

• Token ist manipulationssicher, aber nicht personenbeziehbar

• Privacy by Design ist erfüllt

• Privacy by Default ist erfüllt

• Vollständige Löschung möglich, weil Token unpersonifiziert ist

Teil 5 – Architektur einer Real‑Time Audit Plattform

1. Event‑Ingestion Layer

2. Tokenization Engine

3. Real‑Time Control Engine

4. Immutable Evidence Store (DSGVO‑konform)

5. Alerting Workflow

6. Audit Analytics Layer

7. Governance Layer

Teil 6 – Future of Audit 2030 (NextLevel Positionierung)

Das neue Rollenprofil: Auditor 2030+

• Data‑Prozess‑Architekt

• Kontrolle‑Designer

• Streaming‑Analyst

• IFRS‑Mechaniker

• Ethics & AI‑Steward

• „Real‑Time‑Controller“

Teil 7 – Implementierungs-Roadmap (NextLevel Maturity Model)

Ein typisches Implementierungsprojekt bewegt sich – je nach Datenqualität und Systemlandschaft – zwischen 8 und 24 Wochen für die ersten drei Stufen (Token Ready → IFRS Real‑Time Monitoring). Die Kosten sind stark abhängig vom Umfang, beginnen in der Regel jedoch bei CHF 20’000–50’000 für ein Minimal‑Szenario (Tokenisierung + Grundkontrollen) und können bei komplexen Gruppenstrukturen oder SAP‑/Oracle‑Integrationen auf CHF 80’000–150’000 ansteigen.

Der Schritt von Continuous Auditing (Stufe 4) zu Autonomous Assurance (Stufe 5) ist weniger technisch als organisatorisch anspruchsvoll und benötigt typischerweise 4–12 Monate, da Rollen, Prozesse und Governance angepasst werden müssen. Insgesamt profitieren Unternehmen am meisten, wenn sie den Aufbau inkrementell, risikoorientiert und mit klar priorisierten Use‑Cases angehen.

Für die meisten Organisationen rechnet sich die Investition bereits ab Stufe 3, weil IFRS‑ und IKS‑relevante Risiken frühzeitig erkannt werden und die Dokumentation für Revision und Management signifikant effizienter wird.