Minimum Viable Audit (MVA)©

2. Warum MVA©? – Der Gap zwischen Papier‑IKS und wirksamer Kontrolle

Die Realität vieler Unternehmen: IKS existiert auf dem Papier, ist aber operativ nicht durchgängig wirksam. Kontrollen sind stichprobenbasiert, zeitverzögert und nicht manipulationsfest dokumentiert.

NextLevel MVA© schließt diese Lücke:

• Von Stichproben zu Vollabdeckung (ereignisnah statt retrospektiv).

• Von manueller Dokumentation zu automatischer Evidenz (Token‑Ketten, digitale Signaturen).

• Von Einmal‑Projekten zu kontinuierlicher Sicherheit (Streams, Alerts, KPIs).

• Von Datenschutz‑Sorgen zu Privacy‑by‑Design‑Lösungen (Hashing, Pseudonymisierung, RBAC).

3. Leitprinzipien des MVA©‑Frameworks

1. Minimal, aber wirksam: Starte mit dem kleinsten Set an High‑impact Use Cases.

2. Evidence‑by‑Design: Evidenz entsteht automatisch beim Prozessereignis.

3. Tokenisierung zuerst: Jeder Geschäftsvorfall erhält ein Token (Zeitstempel, Hash, Signaturen, Kontrollstatus).

4. Real‑Time‑Trigger: Regeln/Modelle lösen unmittelbar Alerts und Workflows aus.

5. Privacy by Design: Keine Rohdaten im Immutable Store; Hashes & Metadaten genügen.

6. Governance‑First: Versionierte Regeln, RBAC, SoD, Change‑Logs – prüfbar.

7. Iteratives Scaling: Von MVA©‑Stufe 1–3 in Wochen, Stufe 4–5 danach reifengerecht.

8. Open & Portable: Offene Schemas (Python), API‑First, Export‑Pfade.

4. Das NextLevel-MVA©‑Reifegradmodell (5 Stufen)

5. Tokenisierung – das MVA©‑Fundament

5.1 Was ist ein Token?

Ein prüfungsfestes, kryptografisch gesichertes, maschinenlesbares Ereignisobjekt mit:

• timestamp_utc (ISO 8601), source_system, event_type

• document_hash (z. B. SHA‑256 über PDF/Image)

• amount, counterparty, legal_entity

• controls (Status wichtiger Kontrollen)

• ifrs_hints (z. B. „IAS 36“, „IAS 38“)

• signatures (System / Verantwortliche)

• chain (Verkettung, prev_token_id, chain_hash)

5.2 Token‑Beispiel (vereinfachte Form)

# MVA© Token Repräsentation (Python Dictionary / Pydantic-Stil)

mva_token = {

"header": {

"token_id": "TXN-2026-CH-99821",

"timestamp": "2026-02-04T15:30:00Z",

"source": "SAP_S4_ERP"

},

"payload": {

"event": "CAPEX_RECOGNITION",

"amount": 12500.00,

"currency": "CHF",

"project_id": "RD-2026-04",

"counterparty": "Innovation Labs AG"

},

"compliance": {

"is_ias38_relevant": True,

"activation_criteria_met": "passed",

"control_hash": "sha256:e3b0c442..." # Beweis der Kontroll-Integrität

},

"signatures": [

{"role": "AI_AUDITOR", "status": "verified"},

{"role": "CFO_RELEASE", "sig_key": "rsa_4096_pk_..."}

],

"chain": {

"previous_hash": "8f3e2bb...f1", # Der unveränderbare Anker

"block_depth": 452

}

}

5.3 Warum Tokenisierung der Game Changer ist

• Evidence‑by‑Design: Beweis entsteht beim Ereignis, nicht im Nachgang.

• Manipulationsschutz: Chain‑Hash & Signaturen verhindern stilles Überschreiben.

• IFRS‑Operationalisierung: IAS‑/IFRS‑Hinweise sind maschinenlesbar.

• Privacy by Design: Hashes, keine Rohdaten in immutablen Speichern.

• Portabilität: Offenes Python‑Schema, API‑First, Interoperabilität.

6. Architektur (High Level)

1. Event‑Ingestion: APIs, Webhooks, ERP‑Events (SAP/Oracle/Dynamics), E‑Invoicing, Banking‑APIs.

2. Tokenization Engine: Hashing, Signaturen, Chain‑Hash, Schema‑Validierung, DSGVO‑Minimierung.

3. RTA/CA‑Engine: Regelbibliothek, IFRS‑Trigger (IAS 36/38), ML‑Anomalien, Risk Scoring.

4. Immutable Evidence Store (WORM): Nur Hashes & Metadaten, Export/Prüfpfade.

5. Alerting & Workflow: Microsoft Teams, E‑Mail, Tickets, Auto‑Freigaben/Sperren.

6. Analytics & KPIs: Dashboards, Drill‑downs, Audit‑Evidence‑Views.

7. Governance Layer: RBAC, Segregation of Duties (SoD), Versionierung, Change‑Logs.

7. IFRS‑Operationalisierung mit MVA©

7.1 IAS 36 (Wertminderung) – Echtzeit‑Indikatoren

Externe Signale: Preisverfall, Absatzrückgänge, Lieferantendistress, Rückläufer.

Interne Signale: sinkende Cash‑Flows, Margenverschlechterung, Budget‑Gaps, Qualitätsmuster. MVA©‑Umsetzung: Regeln auf Token‑Daten (Streaming‑KPIs, Trigger‑Flags, Schwellenwerte), automatische „Impairment‑Hints“ mit Evidenz‑Link zum Token‑Trail.

7.2 IAS 38 (Immaterielle Vermögenswerte) – Projekt‑ und Aktivierungslogik

• F&E‑Abgrenzung (Forschung vs. Entwicklung) in Token‑Feldern abbilden.

• Milestones & Kostenkategorien tokenisieren (aktivierungsfähig vs. nicht aktivierungsfähig).

• Re‑Assessment‑Trigger (z. B. Verzögerung, Budget‑Overrun, Value‑At‑Risk).

• Verknüpfung zu IAS 36 (Wertminderungsanzeichen für intangibles) via Token‑Kette des Projekts.

8. Regulatorik & Governance – MVA© als Antwort

• IKS‑Pflichten & Governance‑Codes: MVA© erzeugt nachweisbare Kontrollereignisse und dokumentiert die Ausführung – nicht nur die Existenz.

• Continuous Auditing & Monitoring: Regelversionen und Ereignisprotokolle machen die Wirksamkeit prüfbar.

• Datenschutz (DSGVO/GDPR): Privacy by Design (Hashes statt Rohdaten), Privacy by Default (Minimaldaten), Rollenmodelle und Löschkonzepte.

9. KPIs & Value Case

Detection & Response

• MTTD/MTTR (Mean Time To Detect/Respond)

• Alert Precision/Recall

Qualität & Effizienz

• First‑Pass‑Yield (Transaktionen ohne Nacharbeit)

• Fehlerquote, Duplikat‑Rate, 3‑Way‑Match‑Quote

IKS & Abschluss

• Kontroll‑Durchgriff (% Transaktionen mit Key‑Controls)

• Days to Close (Schnellerer Abschluss)

• Audit‑Effort‑Reduktion (Substantive Testing ↓)

IFRS‑Wirksamkeit

• Anteil zeitnah erkannter IAS 36/38‑Indikatoren

• Durchlaufzeit Bewertungsentscheidung

• Dokumentationsvollständigkeit (Evidenzlinks)

10. Risiken & Gegenmaßnahmen

11. Praxisbeispiele (kompakt)

11.1 Eingangsrechnungen (Purchase‑to‑Pay)

Token bei Eingang → Duplikat‑Check, Sanktionsscreening, 3‑Way‑Match, Schwellenwerte → Auto‑Freigabe/Sperre, Evidenz im WORM‑Store.

11.2 IAS 36 Live‑Monitoring

Preisfall > x % bei > y % Umsatz + Cash‑Flow‑Trend –> automatischer „IAS 36‑Hint“, Review‑Ticket mit Token‑Trail.

11.3 IAS 38 Entwicklungsprojekt

Milestones tokenisiert; Aktivierungskriterien als Regeln; Delays/Overruns triggern Re‑Assessment; Link zu IAS 36 bei Wertzweifeln.

11.4 Continuous Auditing (SoD/IKS)

Automatisierte SoD‑Kontrollen (z. B. Anlage Lieferant ≠ Freigabe Rechnung), Regelversionierung, Audit‑Dashboard.

12. MVA©‑Implementierungspfad (hands‑on)

Phase A – Kick‑off (2–3 Wochen)

• Scope: 1–2 High‑Value Use Cases (z. B. Eingangsrechnungen)

• Token‑Schema (Minimalfelder)

• Datenschutz‑Design (Hash vs. Payload)

Phase B – MVP/MVA (4–8 Wochen)

• Event‑Ingestion (API/CSV/Konnektoren)

• Tokenization Engine (Hash, Signaturen, Chain)

• 2–3 Kernregeln (Duplikat, 3‑Way‑Match, Schwellen)

• WORM‑Evidence + Teams‑Alerting

Phase C – Scale (6–12 Wochen)

• IFRS‑Trigger (IAS 36/38)

• Dashboards, KPIs, Tuning

• Regel‑Governance & Versionierung

Phase D – Continuous (ongoing)

• ML‑Anomalien (Stufe 5 vorbereiten)

• Risk Scoring, Feedback‑Loop

• Roll‑out auf weitere Prozesse/Gesellschaften

13. Operating Model & Rollen

• Product Owner Audit Tech (verantwortet Backlog & Roadmap)

• Data/Integration Engineer (Ingestion, Tokenization)

• Control Designer (Fachregeln, IFRS‑Trigger)

• Privacy & Security Lead (DSGVO, Zugriff, Signaturen)

• Internal Audit / 2nd Line (Continuous Assurance, Trends)

• Business Owner (Finance/Procurement) (Prozessentscheidungen)

Governance‑Gremien: Regel‑Board (Freigaben), Datenschutz‑Review, Change Advisory.

14. Ausbildung & Zertifizierung (NextLevel)

• Certified MVA® Practitioner (Implementierung, Token‑Schema, Grundregeln)

• Certified MVA® Architect (Architektur, Governance, IFRS‑Operationalisierung)

• Certified MVA® Assessor (Maturity Assessment, KPI‑Review, Audit‑Readiness)

Didaktik: Praxislabs (Token bauen), Regel‑Design‑Workshops, IFRS‑Trigger‑Sprints.