(Teil II) IFRS Strategy Guide: Real‑Time Settlement & Blockchain

Vom „Point‑in‑Time“ zum „Continuous Assurance“: Die Rekonstruktion des Audit‑Trails im Zeitalter der Real‑Time‑Economy

Zielgruppe: CFO/CAO, Group Accounting, Internal Audit/IKS, Wirtschaftsprüfer (Big 4), IT/CTO | Level: Einsteiger bis Fortgeschritten (BIG4‑Praxis) | Lesezeit: ~12–15 Min.

Kernthese: 

Real‑Time Settlement (RTS) in Blockchain‑basierten, permissioned Ledger‑Umgebungen transformiert die Finanzfunktion: Forderungen drehen schneller in Cash, Intercompany‑ Abstimmung wird automatisiert (Triple‑Entry), und Prüfungen wechseln von Stichproben zum Continuous Assurance.IFRS‑Nuance: RTS beschleunigt Derecognition von Forderungen und reduziert ECL‑Exposure, ändert aber nicht den Zeitpunkt der Revenue Recognition (IFRS 15:

Kontrollübergang). Audit‑Impuls: Prüfer bewegen sich vom Beleg zum Code: Smart‑Contract‑Auditing, Node‑Governance und Echtzeit‑Anomalieerkennung.

Einleitung

In unserem ersten Teil der Serie haben wir die Bewertungsebene von ESG-Faktoren im Rahmen von IFRS 9 analysiert. Doch die strategische Implementierung von „Green Pricing“ ist nur die halbe Miete. Die wahre Herausforderung für die Finanzfunktion 2026 liegt in der operativen Exzellenz der Abwicklung. Während die traditionelle Buchhaltung noch in T+2-Zyklen (oder länger) denkt, transformiert das Real-Time Settlement (RTS) auf Basis der Blockchain-Technologie die fundamentale Physik der Bilanzierung. Für CFOs, Group Accountants und die Prüfer der Big 4 bedeutet dies das Ende der „Archäologie der Daten“ und den Beginn der Continuous Finance.

Für Einsteiger (Hinweise):

• T+2 bedeutet: zwei Tage nach Transaktion wird abgerechnet/settled.

• Blockchain ist ein gemeinsames, fälschungssicheres Protokoll: alle Beteiligten sehen denselben, unveränderlichen Datensatz.

• Continuous Finance heißt: Buchhaltung, Datenabgleich und Prüfung passieren fortlaufend, nicht nur am Stichtag.

Für BIG4/Prüfungspraxis (Hinweise):

• RTS adressiert Operational Risk (Latenz, Rec‑Fehler, Cut‑off) und stärkt Control Reliability.

• Continuous Assurance benötigt Kontroll‑Designs (Pre‑/Post‑Trade Checks, Node‑Access, Segregation of Duties) und Evidenzketten (On‑Chain Hashes + Off‑Chain Support).

• 
  

Die Finanzfunktion 2026: Synergie aus Real-Time Settlement, Blockchain-basierter Governance und messbarer IFRS-Optimierung. Green-Pricing-Daten fließen über den Shared Ledger direkt in die Bilanzierung ein.

1. Das strukturelle Problem: Die Latenz als systemisches Risiko

In der klassischen Welt der Rechnungslegung ist eine Bilanz immer eine Momentaufnahme der Vergangenheit. Die Zeitverzögerung zwischen dem wirtschaftlichen Leistungsaustausch und dem finalen Settlement erzeugt massive Ineffizienzen: Liquiditätsbindung: Kapital ist in „Pending“-Status gefangen.Kontrahentenrisiko: In der Zeitspanne zwischen Transaktion und Settlement entstehen Kreditrisiken, die mühsam nach IFRS 9 (ECL) modelliert werden müssen.Abstimmungsaufwand: Manuelle Intercompany-Reconciliation bindet bis zu 30 % der Kapazitäten in der Abschlussphase.

Für Einsteiger (Hinweise):

• Kontrahentenrisiko = Risiko, dass der Geschäftspartner nicht zahlt.

• ECL (Expected Credit Loss) = erwarteter Kreditverlust; Unternehmen schätzen mögliche Verluste auf Forderungen.

• Intercompany‑Reconciliation = Abgleich zwischen Konzerngesellschaften (z. B. Tochter A verkauft an Tochter B: stimmen beide Bücher überein?).

Für BIG4/Prüfungspraxis (Hinweise):

• Latenz erhöht Exposure‑Zeit → wirkt auf PD/LGD in ECL‑Modellen.

• Rec‑Fehler zeigen sich oft in Cut‑off, FX‑Bewertung, In‑Transit‑Konten; RTS reduziert diese Fehlerquellen durch Atomisierung der Zahlungs‑ und Buchungsereignisse.

2. Real-Time Settlement: Die Verschmelzung von Nachricht und Wert

Im traditionellen Banking ist eine Zahlung lediglich eine Nachricht über eine beabsichtigte Wertverschiebung. Bei Blockchain-basiertem RTS verschmelzen Nachricht und Werttransfer zu einer Einheit (Atomic Settlement). Der Impact auf die Bilanz: Sobald eine Transaktion im Ledger bestätigt ist, gilt sie als final gesettelt. Das hat unmittelbare Auswirkungen auf den Zeitpunkt des Bilanzansatzes (Recognition) und das Ausbuchungsmanagement (Derecognition). Für den Group Accountant bedeutet das: Die Position „Forderungen aus Lieferungen und Leistungen“ nähert sich in Echtzeit dem tatsächlichen Cash-Bestand an.

Für Einsteiger (Hinweise):

• Atomic Settlement = „alles oder nichts“: Nachricht und Zahlung passieren gleichzeitig; es bleibt nichts „zwischen den Systemen“ hängen.

• Recognition/Derecognition = Zugang/Ausbuchung eines Vermögenswerts (z. B. Forderung entsteht und wird später ausgebucht, wenn bezahlt).

Für BIG4/Prüfungspraxis (Hinweise):

• Wichtige IFRS‑Nuance: Revenue Recognition folgt IFRS 15 (Kontrollübergang). RTS beeinflusst Forderungs‑Derecognition und Aging, nicht automatisch den Umsatzzeitpunkt.

• Prüfer fokussieren sich auf Posting‑Automatik, Cut‑off‑Integrität und Ledger‑Finality (z. B. Konsens‑Mechanismus, Reorg‑Risiken bei Public Chains vs. Finality Guarantees in Permissioned Ledgers).

3. Triple-Entry Accounting: Das Ende des Intercompany-Albtraums

Für Konzerne und deren Prüfer (PwC, EY, KPMG, Deloitte) ist die Intercompany-Abstimmung (IC-Rec) einer der schmerzhaftesten Prozesse im Periodenabschluss. Differenzen durch Währungsschwankungen, Zeitverzug (In-Transit) und manuelle Buchungsfehler führen oft zu erheblichen Korrekturbedarfen in letzter Sekunde. Die technologische Lösung: Blockchain führt das Prinzip des Triple-Entry Accounting ein. Neben Soll (Unternehmen A) und Haben (Unternehmen B) tritt der kryptografische Hash im Shared Ledger als dritte, unveränderliche Instanz hinzu. Single Source of Truth: Da beide Parteien auf denselben Datensatz zugreifen, können keine Differenzen entstehen.Wegfall der Saldenbestätigung: Der klassische Prozess der Einholung von Saldenbestätigungen wird technisch obsolet. Der Prüfer verifiziert nicht mehr die Kommunikation, sondern die mathematische Integrität des Protokolls.

Für Einsteiger (Hinweise):

• Hash = digitaler Fingerabdruck eines Datensatzes; klein, unveränderlich, beweist Integrität.

• Shared Ledger = gemeinsames Hauptbuch mehrerer Parteien; Änderungen sind nachvollziehbar und signiert.

Für BIG4/Prüfungspraxis (Hinweise):

• In permissioned Netzwerken kann die Saldenbestätigung stark reduziert werden, ersetzt durch On‑Chain Abgleich und Zugang zu Gegenparteien‑Einträgen.

• Vollständiger Wegfall hängt von Rechtsrahmen, Vertragsgestaltung, Node‑Governance und Audit‑Rights ab. Prüfer benötigen Reliance‑Kriterien (z. B. SOC‑Reports, Protokoll‑Zertifizierungen).

4. Deep‑Dive für Wirtschaftsprüfer: Continuous Assurance & der „Auditing Node“

Die Big 4 bewegen sich weg vom stichtagsbezogenen Audit hin zur Continuous Assurance. In einem Blockchain-Ökosystem fungiert die Prüfungsgesellschaft idealerweise als Observing Node. Real-Time Audit Trail: Statt am Jahresende Stichproben zu ziehen, ermöglicht RTS eine 100%-Prüfung der Grundgesamtheit in Echtzeit. Algorithmen identifizieren Anomalien, wie ungewöhnliche Transaktionsmuster oder Verstöße gegen Smart Contract Governance, unmittelbar bei Entstehung. Vom Beleg zum Code: Die Excellence des Prüfers verlagert sich von der Prüfung einzelner Rechnungen hin zur Code-Verifikation (Smart Contract Auditing). Bevor ein automatisierter Prozess (z.B. ein ESG-basiertes Bonusprogramm) live geht, zertifiziert der Prüfer die Logik des Codes.

Für Einsteiger (Hinweise):

• Observing/Auditing Node = Lesezugriff für Prüfer auf das Ledger, um Transaktionen und Regeln fortlaufend zu prüfen.

• Anomalieerkennung = Algorithmen finden „Ausreißer“ oder Regelverstöße automatisch.

Für BIG4/Prüfungspraxis (Hinweise):

• Continuous Assurance verlangt kontinuierliche Kontrollen, Exception‑Management, Alerting‑Workflows und Evidence Preservation (On‑Chain + Off‑Chain).

• Smart‑Contract‑Audit umfasst: Code‑Review, Policy‑Mapping (IFRS/IKS), Test‑Cases (inkl. Negativ‑Tests), On‑Chain Access Controls, Change‑Management und Deployment‑Sign‑off.

5. IFRS 9 & Amortized Cost: Revolution der Risikomodelle

Unter IFRS 9 ist das Expected Credit Loss (ECL) Modell oft eine Schätzung auf Basis historischer Daten und makroökonomischer Prognosen. RTS liefert eine neue Daten-Granularität: Echtzeit-Impairment: Durch Blockchain-Explorer erhalten Prüfer Zugriff auf unveränderbare Zeitstempel. Das „Aging“ von Forderungen wird sekundengenau. Reduktion des ECL: Wenn Lieferungen und Leistungen simultan über Smart Contracts abgerechnet werden, sinkt das Ausfallrisiko für diesen Zeitraum auf ein technisches Minimum. Dies setzt regulatorisches Kapital frei und optimiert die Bilanzstruktur.

Für Einsteiger (Hinweise):

• Amortized Cost = Bewertung zum fortgeführten Buchwert (Kredite/Forderungen).

• Aging = Einteilung von Forderungen nach „wie lange überfällig“.

Für BIG4/Prüfungspraxis (Hinweise):

• RTS verbessert ECL‑Inputdaten (Zeitstempel, Exposure‑Dauer, Zahlungsevents).

• SICR (Significant Increase in Credit Risk) kann mit Echtzeit‑Signalen objektiver erkennbar werden; dennoch bleibt ECL vorwärtsgerichtet und makroabhängig.

• Kapitalentlastung ist modell‑ und aufsichtsspezifisch; saubere Governance und Backtesting sind entscheidend.

6. Standortvorteil Zug: Wo Theorie auf Code trifft

Warum treibt das NextLevel College dieses Thema so massiv voran? Weil wir im Kanton Zug (Blockchain Valley) an der Quelle sitzen. Hier erleben wir täglich, wie die großen Advisory-Häuser ihre Digital-Audit-Zentren ansiedeln. Unsere Ausbildungsprogramme im Bereich IT, Wirtschaftsinformatik und Finance nutzen diesen Standortvorteil. Excellence bedeutet für uns, dass unsere Absolventen nicht nur wissen, was ein Buchungssatz ist, sondern wie man einen Hash im Kontext von IFRS-Compliance interpretiert. Wir schulen die Schnittstellen-Kompetenz, die notwendig ist, um die Brücke zwischen dem Chief Accounting Officer (CAO) und dem CTO zu schlagen.

Für Einsteiger (Hinweise):

• Schnittstellen‑Kompetenz = Fähigkeit, Accounting‑Regeln mit IT‑Implementierung zu verbinden.

• CAO vs. CTO = Rechnungslegung/Compliance vs. Technologie/Implementierung.

Für BIG4/Prüfungspraxis (Hinweise):

• Curriculum‑Elemente: Ledger‑Architektur, IKS‑Pattern, Smart‑Contract‑Policy‑Checks, Audit‑Analytics, ZKP/Privacy‑Designs.

7. Die Synergie: Green Pricing trifft Real-Time Settlement

Schließen wir den Kreis zu Teil I der Serie. Ein „Green Premium“ ist nur dann am Kapitalmarkt glaubwürdig, wenn die Herkunft der Nachhaltigkeitsdaten (z. B. Scope-3-Emissionen) über eine Blockchain lückenlos mit der Zahlung verknüpft ist. RTS liefert den finalen Beweis: Die Zahlung wird erst dann durch den Smart Contract ausgelöst, wenn die ESG-Compliance-Daten (z. B. CO2-Zertifikate) verifiziert wurden. Das ist Automated Governance auf höchstem Niveau.

Für Einsteiger (Hinweise):

• Scope‑3 = Emissionen in der Lieferkette (z. B. bei Zulieferern).

• Automated Governance = Regeln sind im Code; Zahlungen folgen nur, wenn Bedingungen erfüllt sind.

Für BIG4/Prüfungspraxis (Hinweise):

• ESG‑Trigger im Contract → Kontrollziele (Vollständigkeit, Genauigkeit, Berechtigungen) vor Go‑Live auditieren; Datenquellen und Zertifikats‑Integrität prüfen (On‑/Off‑Chain).

Kritische Prüfungsfragen für die Praxis (Assurance Check)

Governance: Wer trägt die Verantwortung, wenn ein Smart Contract eine IFRS-widrige Buchung autonom auslöst? Ist Ihr Kontrollsystem (IKS) auf algorithmische Fehler vorbereitet? Datenhoheit: Wie stellen Sie sicher, dass bei einem Shared Ledger die Vertraulichkeit nach DSGVO gewahrt bleibt, während die Transparenz für den Wirtschaftsprüfer maximiert wird? (Stichwort: Zero-Knowledge Proofs).Bewertung: Wie gehen Sie mit der Volatilität von digitalen Assets um, die als Settlement-Medium dienen? Entstehen hier neue Währungsrisiken nach IAS 21?

Für Einsteiger (Hinweise):

• IKS = Internes Kontrollsystem; schützt vor Fehlern und Betrug.

• Zero‑Knowledge Proofs (ZKP) = Beweisverfahren: man zeigt, dass etwas stimmt, ohne die Daten offenzulegen.

Für BIG4/Prüfungspraxis (Hinweise):

• Governance: Owner der Policy‑Engine, Change‑Controls, Rollbacks und Override‑Prozeduren definieren.

• Datenschutz: Permissioned Ledger, Role‑Based Access, Off‑Chain Storage + On‑Chain Hash und ZKP für selektive Offenlegung.

• Bewertung/FX: Settlement‑Token je nach Ausgestaltung (stable/volatil) → IAS 21 FX‑Effekte, IFRS 9 (finanzielle Vermögenswerte) oder IAS 38 (intangible) prüfen.

Fazit

Der Übergang zur Real-Time-Economy ist keine Option, sondern eine Notwendigkeit für Unternehmen, die Excellence und Nachhaltigkeit ernst nehmen. Das NextLevel College versteht sich hierbei als Ihre Bildungsmanufaktur und Ihr Ökosystem für nachhaltige Transformation. Wir laden Sie ein, die Grenzen der klassischen Rechnungslegung zu sprengen und die Finanzfunktion der Zukunft aktiv mitzugestalten.

NextLevel‑Stellungnahme

Als Bildungsmanufaktur im DACH‑Raum und mit Standortvorteil Zug setzen wir bewusst auf die Brücke zwischen IFRS und Technologie und insbesondere auf das Thema Blockchain, Tokens und Smart-Contracts. Unsere Position:

1. Prüfungsfeste Innovation: RTS und Smart‑Contracts werden nur mit klaren IKS‑Kontrollzielen, Policy‑Mapping (IFRS/ESG) und Auditing Nodes nachhaltig.

2. Praxis vor Hype: Wir priorisieren permissioned Ledger mit Governance, Zugriffssteuerung und Audit‑Rights, statt unkontrollierter Public‑Netze.

3. Skills‑Transfer: Absolvent:innen lernen, Code‑Logik im Lichte von IFRS zu verstehen und Privacy by Design umzusetzen (ZKP, Off‑Chain Hashing).

4. Messbare Wirkung:

   Wir betrachten RTS nicht als Selbstzweck, sondern als Effizienz-Treiber. Basierend auf aktuellen Case-Studies sind folgende Optimierungen im Zielkorridor:

   • Beschleunigung:  −70 % Rec-Zeit: Drastische Reduktion des manuellen Abstimmungsaufwands durch Triple-Entry-Logik.

     • −40 % Close-Time: Ein schnellerer „Hard Close“ durch kontinuierliche Datenvalidierung.

   • Risiko-Optimierung:

     • −10 bis 25 % ECL-Delta: Geringere Risikovorsorge nach IFRS 9, da die „Exposure-Latenz“ (die Zeit, in der Kapital ungesichert im Feuer steht) minimiert wird.

   • Compliance-Qualität:

     • −30 % Audit Findings: Weniger Feststellungen durch Wirtschaftsprüfer dank präventiver Kontrollen (Policy-as-Code).

Aussicht 2026–2030: Wo geht die Reise hin?

• 2026–2027: Breiter Rollout von Auditing Nodes in Konzernen; Smart‑Contract‑Controls werden Teil des IKS‑Standards.

• 2027–2028: Erste Regulatory Frameworks konkretisieren Ledger‑Reliance im Audit; Tokenisierte Cash‑Äquivalente (z. B. bank‑issued Stablecoins) etablieren sich als Settlement‑Medium.

• 2028–2029: Continuous Assurance wird marktüblich; ERP‑Connectoren liefern Near‑Zero Reconciliation für IC‑Prozesse.

• 2029–2030: IFRS‑Datenmodelle und Digital Reporting (XBRL‑Erweiterungen) adressieren Echtzeit‑Evidenz; Privacy‑Tech (ZKP) ist Standard bei Shared Ledgers.

Implikation: Organisationen mit CAO–CTO‑Brücke und Policy‑as‑Code gewinnen massiv an Effizienz und Prüfungsreife.

Blueprint: Continuous Finance – Die 6 Bausteine Ihrer Transformation

Stellen Sie sich diesen Blueprint als das Betriebssystem für Ihre Finanzfunktion vor. Es geht nicht darum, das ERP-System zu ersetzen, sondern es "intelligent" zu vernetzen.

• 1. Architektur: Das „Tresor-Prinzip“ (Hybrid-Setup)

  Wir nutzen ein Permissioned Ledger (eine geschlossene Business-Blockchain) als gemeinsame Wahrheit. Aber: Sensible Daten bleiben in Ihrem DMS (Dokumentenmanagement). Nur der digitale Fingerabdruck (Hash) wandert auf die Chain. Mittels ZKP (Zero-Knowledge Proofs) beweisen wir dem Prüfer, dass eine Rechnung korrekt ist, ohne dass er die Details Ihrer Lieferantenverträge lesen muss. Das ist Datenschutz nach DSGVO im High-End-Bereich.

• 2. IKS/Controls: Der „digitale Türsteher“ (Policy-as-Code)

  Statt Fehler im Nachgang mühsam zu korrigieren, verhindern wir sie. Pre-Trade Validations prüfen schon vor der Buchung: Ist das Budget da? Stimmt die Berechtigung? Smart Contracts erzwingen die Funktionstrennung (Segregation of Duties) im Code. Wenn die Regeln nicht erfüllt sind, findet keine Transaktion statt. Keine Fehlbuchung = keine Korrektur.

• 3. Data & Auditability: Das „Endlos-Logbuch“ (Immutable Trail)

  Jedes Ereignis bekommt einen unveränderbaren Zeitstempel. Wir installieren einen Auditing Node, durch den der Prüfer live auf die Daten schaut, statt am Jahresende Stichproben in staubigen Ordnern zu ziehen. Bei Anomalien (z. B. Buchungen am Sonntagabend um 22 Uhr) schlägt das System sofort Alarm. Vom Beleg-Sammeln zur Echtzeit-Überwachung.

• 4. IFRS-Mapping: Die „intelligente Bilanz“ (Real-Time Accounting)

  Das System weiß sekundengenau, wie lange eine Forderung offen ist (Echtzeit-Aging). Diese Daten fließen direkt in Ihr ECL-Modell (IFRS 9). Sobald das Geld eintrifft, wird die Forderung vollautomatisch ausgebucht (Derecognition). Währungseffekte (IAS 21) werden nicht mehr geschätzt, sondern bei jedem Event präzise bewertet. Ihre Bilanz ist kein Standbild mehr, sondern ein Livestream.

• 5. Org/Skills: Die „CAO-CTO-Allianz“ (Bridging the Gap)

  Technik ist nur das Werkzeug. Die wahre Magie passiert an der Schnittstelle. Der Chief Accounting Officer definiert die fachlichen Regeln, der CTO gießt sie in Code. Wir schulen Ihre Teams darin, diese „Code-Sprache“ zu verstehen. Finance-Experten der Zukunft verstehen Algorithmen genauso gut wie Abschreibungstabellen.

• 6. KPIs: Die „Erfolgsmessung“ (Impact)

  Wir messen den Erfolg an harten Fakten: Wie stark sinkt die Zeit für die Intercompany-Abstimmung (Rec-Zeit)? Wie viele Tage sparen wir beim Abschluss (Close-Time)? Ziel ist eine Automationsquote, die manuelle Eingriffe zur absoluten Ausnahme macht.

Maturity Model: Wo steht Ihre Finanzfunktion?

Nutzen Sie dieses Self-Assessment, um Ihre Roadmap für 2026 zu definieren.

Level	Status Quo	Das Erlebnis	Nächster Schritt
Level 1	Batch-Accounting	„Wir buchen in Stapeln, gleichen IC-Salden manuell per Excel ab und brauchen Wochen für den Abschluss.“	Starten Sie einen Pilot mit einem einzelnen Intercompany-Prozess.
Level 2	Connected Finance	„Unsere Systeme reden via APIs miteinander. Wir sind schneller, aber die Kontrolle passiert noch manuell.“	Zentralisieren Sie Ihre Kontrollregeln und führen Sie strukturierte Workflows ein.
Level 3	Smart Governance	„Smart Contracts verhindern Fehler vorab. Der Prüfer hat einen Lese-Zugriff (Auditing Node) auf unser Ledger.“	Implementieren Sie Echtzeit-Risikomodelle (ECL) und härten Sie das Change-Management.
Level 4	Continuous Finance	„Accounting passiert in Echtzeit. Prüfung ist ein fortlaufender Prozess. Wir steuern den Konzern per Knopfdruck.“	Skalieren Sie das Modell auf globale Einheiten und komplexe ESG-Reporting-Ketten.

FAQ (praxisnah)

1. Brauche ich Public Blockchain? Nein. Für Unternehmens‑Accounting eignet sich permissioned (zugangsbeschränkt) mit Governance und Audit‑Zugriff besser.

2. Ersetzt RTS meine ERP‑Systeme? Nein. RTS ergänzt ERP via Connectoren (Events → Buchungen). ERP bleibt „System of Record“ für Abschlüsse.

3. Wie starten wir ohne Großprojekt? Beginnen Sie mit IC‑Use‑Case (zwei Gesellschaften), kleinem Volumen, klaren Kontrollzielen und Auditing Node.

4. Was bedeutet Policy‑as‑Code? Rechnungslegungs‑/ESG‑Regeln werden formalisiert und im Smart Contract abgebildet; Vorab‑Audit ist Pflicht.

5. Wie wirkt RTS auf ECL? Exposure‑Zeit sinkt, Daten werden granularer → ECL‑Modelle werden präziser, aber bleiben makrosensitiv (Vorwärtsblick).

6. ZKP und DSGVO – wie passt das zusammen? ZKP ermöglicht Nachweis ohne Offenlegung; sensible Daten bleiben off‑chain, nur Hash/Beweis sind on‑chain.

7. Saldenbestätigung wirklich obsolet? Technisch weitgehend ersetzbar, prüfungsrechtlich oft reduzierbar statt vollständig entbehrlich – abhängig von Governance/Verträgen.

8. Welche Token gelten als Cash‑Äquivalent? Nur stabile, rechtlich geprüfte Instrumente (z. B. bank‑issued Stablecoins) können je nach Ausgestaltung cash‑nah sein; Accounting‑Behandlung prüfen.

9. Wie verhindern wir Fehlbuchungen durch Code?Change‑Management, Vier‑Augen‑Prinzip, Test‑Suiten, Staging‑Deployments, Auditor Sign‑off vor Go‑Live.

10. Was kostet das? Projektgrößen variieren: Pilot (3–6 Monate) mit vorhandenen Tools/Connectoren; ROI entsteht v. a. durch Rec‑Zeit‑Reduktion und Fehlervermeidung.

Glossar (ausgewählte Begriffe)

• Atomic Settlement: Gleichzeitige, unteilbare Abwicklung von Nachricht und Zahlung.

• Auditing/Observing Node: Prüfer‑Knoten mit Lesezugriff auf das Ledger.

• Derecognition: Ausbuchung eines Vermögenswerts (z. B. Forderung bei Zahlung).

• ECL (Expected Credit Loss): Erwarteter Kreditverlust; IFRS 9‑Modell zur Risikovorsorge.

• IFRS 15 (Revenue Recognition): Umsatzrealisierung orientiert sich am Kontrollübergang.

• IAS 21 (FX): Behandlung von Fremdwährungseffekten und Umrechnung.

• IKS: Internes Kontrollsystem.

• Permissioned Ledger: Zugangs‑/rollenbeschränktes Blockchain‑Netzwerk.

• Policy‑as‑Code: Formale Abbildung von Regeln im Programmcode (Smart Contract).

• SICR: Significant Increase in Credit Risk – deutlich erhöhter Kreditrisiko‑Status.

• Triple‑Entry Accounting: Soll/Haben + kryptografischer Hash im gemeinsamen Ledger.

• Zero‑Knowledge Proof (ZKP): Beweis eines Sachverhalts ohne Offenlegung der zugrunde liegenden Daten.

Abkürzungsverzeichnis

• CAO: Chief Accounting Officer

• CTO: Chief Technology Officer

• DSGVO: Datenschutz‑Grundverordnung

• ECL: Expected Credit Loss

• ERP: Enterprise Resource Planning

• FX: Foreign Exchange (Fremdwährung)

• IC‑Rec: Intercompany‑Reconciliation

• IFRS: International Financial Reporting Standards

• IKS: Internes Kontrollsystem

• LGD/PD: Loss Given Default / Probability of Default

• RTS: Real‑Time Settlement

• ZKP: Zero‑Knowledge Proof

Weiter zum Teil III (Teil III) IFRS Strategy Guide 2026 – PPAs: Wetterbericht für die Bilanzabteilung