Warum Ihr ERP Rechnungen erzeugt, aber keine Nachweise
ERP- und Buchhaltungssoftware ist bemerkenswert gut in der Aufgabe, für die sie entwickelt wurde: Transaktionen in großem Umfang verarbeiten, Freigabe-Workflows durchsetzen und strukturierte Ausgaben erzeugen, die andere Systeme weiterverarbeiten können. Millionen von Rechnungen entstehen so jeden Tag ohne Zwischenfall.
Es gibt aber eine separate Aufgabe, für die ERP-Software nie entwickelt wurde, und dieser Unterschied zählt, wenn eine Steuerbehörde, ein Gericht oder eine Aufsichtsbehörde eine schwierigere Frage stellt als “Zeigen Sie mir die Rechnung”.
Die Frage, die die meiste Software nicht beantworten kann
Wird eine gewöhnliche Rechnung bestritten, reicht es meist, das PDF vorzulegen. Der Käufer erkennt es, der Verkäufer bestätigt es, und die Sache ist erledigt. Auf genau diesen Ablauf ist ERP-Software optimiert.
Eine schwierigere Frage sieht so aus: “Beweisen Sie, dass diese Rechnung an diesem Datum in genau dieser Form existierte, dass sie seitdem nicht verändert wurde und dass die Person, die angibt, sie versandt zu haben, sie tatsächlich über Ihr System versandt hat.”
Das ist keine Dokumentfrage. Es ist eine Beweisfrage. Und Beweise stellen andere Anforderungen als Dokumente.
Ein Dokument ist eine Aufzeichnung einer Transaktion. Ein Beweis ist eine verifizierbare Aufzeichnung, die einer unabhängigen Prüfung standhält, auch der Prüfung durch jemanden, der sie aktiv anzufechten versucht.
Was ERP-Software leistet
Um die Lücke präzise zu beschreiben, hilft es, klar zu sagen, was ERP-Software gut macht.
Die meisten modernen ERP-Systeme bieten:
Strukturierte Rechnungsdaten. Rechnungen werden in einer Datenbank mit klaren Beziehungen zwischen Käufern, Verkäufern, Positionen, Summen und Daten gespeichert. Das macht sie abfragbar, über die eigene Oberfläche des ERP prüfbar und in standardisierten Formaten wie UBL- oder CII-XML exportierbar.
Freigabe- und Audit-Protokolle. Die meisten ERP-Systeme protokollieren, wer was wann freigegeben hat. Diese Protokolle sind für interne Kontrollprüfungen nützlich und können belegen, dass der vorgesehene Prozess eingehalten wurde.
Formatkonformität. Für Factur-X-, ZUGFeRD-, XRechnung- und Peppol-Ausgaben erzeugt moderne ERP-Software XML, das gegen das jeweilige Schema validiert. Das deckt die Formatanforderung der EU-Vorgaben zur E-Rechnung ab.
Export und Portabilität. Rechnungen lassen sich in der Regel in großen Mengen exportieren, als XML, als PDF oder beides. Das deckt den Anwendungsfall der Datenportabilität ab.
Nichts davon ist trivial. Formatkonformität ist ein echtes technisches Problem, in dessen Lösung ERP-Anbieter erheblichen Aufwand investiert haben. Es geht nicht darum, dass ERP-Software mangelhaft wäre. Es geht darum, dass Formatkonformität für einen rechtlichen Nachweis notwendig, aber nicht hinreichend ist.
Was ERP-Software nicht leistet
Die Lücke zeigt sich, wenn Sie eine unabhängige Verifizierung von drei Dingen verlangen, die Gerichtsverfahren häufig erfordern.
Nachweis der Existenz zu einem bestimmten Zeitpunkt. Ein Zeitstempel, der in Ihrem eigenen System gespeichert ist, ist nur so vertrauenswürdig wie Ihr System. Wenn Sie das System kontrollieren, kann eine Gegenpartei argumentieren, dass Sie auch den Zeitstempel kontrolliert haben. Ein RFC 3161-Zeitstempel von einer unabhängigen Time Stamping Authority ist von einem Dritten kryptografisch signiert und kann nicht rückwirkend gefälscht werden, ohne die Signatur ungültig zu machen. Die meisten ERP-Systeme stellen keine RFC 3161-Zeitstempel aus und speichern auch keine.
Nachweis der Integrität seit diesem Zeitpunkt. Eine PDF- oder XML-Datei in einer Datenbank kann verändert werden. Ein Datenbankeintrag kann aktualisiert werden. Ohne ein unabhängiges Hash-Commitment, also einen kryptografischen Fingerabdruck, der zum Zeitpunkt der Erstellung erzeugt und an einem Ort außerhalb Ihrer Kontrolle gespeichert wird, können Sie nicht beweisen, dass das Dokument seitdem nicht verändert wurde. Die meisten ERP-Systeme erzeugen oder speichern keine kryptografischen Hash-Commitments, die an ihre Datensätze gebunden sind.
Eine unabhängige Chain of Custody. Zu wissen, dass ein Dokument heute in einem bestimmten Zustand existiert, ist etwas anderes, als zu wissen, wie es in diesen Zustand gelangt ist. Eine Chain of Custody erfasst jede Aktion an einem Dokument (wer darauf zugegriffen hat, was getan wurde und in welcher Reihenfolge) in einem manipulationsresistenten Protokoll. Das ist in Gerichts- und Behördenverfahren Standard, entspricht aber typischerweise nicht der Art, wie ERP-Audit-Protokolle implementiert sind.
Wann das in der Praxis zählt
Die Lücke zwischen Dokument und Nachweis ist nicht akademisch. Das sind die Situationen, in denen sie zutage tritt.
Ermittlungen von Steuerbehörden. In mehreren EU-Rechtsordnungen können Steuerbehörden von Unternehmen verlangen, die Integrität ihrer elektronischen Rechnungsunterlagen nachzuweisen. Ein Unternehmen, das Rechnungen vorlegen, aber nicht belegen kann, dass sie seit der Ausstellung nicht verändert wurden, ist in einer schwächeren Position als eines, das neben der Rechnung einen kryptografischen Integritätsnachweis vorlegen kann.
Handelsstreitigkeiten. Bestreitet ein Käufer eine Rechnung, etwa mit der Behauptung, sie sei nachträglich geändert worden oder die Beträge entsprächen nicht der Vereinbarung, muss der Verkäufer nachweisen, dass das Dokument echt und unverändert ist. Ein RFC 3161-Zeitstempel und eine Hash-Kette liefern diesen Nachweis. Ein PDF aus einem ERP-System ohne unabhängige Verifizierung tut das nicht.
Aufsichtsrechtliche Prüfungen in der Finanzbranche. Unternehmen, die MiFID II, Solvency II oder vergleichbaren Regelwerken unterliegen, müssen Aufzeichnungen so führen, dass Integrität und Authentizität nachweisbar sind. Die konkreten Anforderungen variieren, aber die allgemeine Erwartung ist, dass Aufzeichnungen nicht unbemerkt verändert werden können. Das ist eine höhere Hürde als typische ERP-Speicherung.
Vertragsstreitigkeiten mit langen Aufbewahrungsfristen. Die Aufbewahrungsanforderungen für Rechnungen in der EU reichen von 7 Jahren (dem gängigen Standard für Umsatzsteuerrechnungen) bis zu 20 Jahren für bestimmte Unterlagen des öffentlichen Sektors nach niederländischem Recht. Über ein Zeitfenster von 7 Jahren kann sich viel ändern: Das ERP-System kann ersetzt, die Datenbank migriert, die PDF-Dateien neu exportiert werden. Ohne einen Zeitstempel und eine Hash-Kette, die zum Zeitpunkt der Erstellung verankert wurden, wird es schwierig zu beweisen, dass eine 7 Jahre alte Rechnung nicht verändert wurde.
Das Missverständnis der Formatkonformität
Eine verbreitete Annahme lautet: Ist eine Rechnung Factur-X- oder Peppol-konform, ist sie vor Gericht verwertbar. Formatkonformität bedeutet, dass die Rechnung gegen das Schema validiert und die Pflichtfelder enthält. Sie sagt nichts darüber aus, wann das Dokument erstellt wurde, ob es verändert wurde oder ob die Aufzeichnung unabhängig verifiziert werden kann.
Factur-X ist ein Dateiformat. RFC 3161 ist ein Beweisprotokoll. Sie arbeiten auf unterschiedlichen Ebenen des Compliance-Stacks, und das eine ersetzt nicht das andere.
Eine physische Analogie: Ein notariell beglaubigtes Dokument und ein gedrucktes Dokument sind beide Dokumente. Die Beglaubigung fügt eine Ebene unabhängiger Verifizierung hinzu: Ein vertrauenswürdiger Dritter bestätigt, wann und von wem das Dokument unterzeichnet wurde. Formatkonformität ist näher am Drucken als an der Beglaubigung.
Was die Nachweisebene tatsächlich erfordert
Einen verifizierbaren Nachweis für ein digitales Dokument zu erbringen, erfordert mindestens drei Dinge.
Einen vertrauenswürdigen Zeitstempel. Ein RFC 3161-Zeitstempel einer Time Stamping Authority liefert einen kryptografischen Nachweis der Existenz zu einem bestimmten Zeitpunkt. Die TSA ist eine unabhängige Partei, deren Signatur jeder mit Standardwerkzeugen verifizieren kann. Der Zeitstempel kann im Nachhinein nicht gefälscht werden, ohne die Signaturkette ungültig zu machen.
Ein Hash-Commitment. Bevor das Dokument einen Zeitstempel erhält, wird sein Inhalt gehasht. SealDoc berechnet sowohl einen SHA-256-Digest, auf den die RFC 3161-Anfrage die Time Stamping Authority festlegt, als auch einen SHA-384-Digest, der den Datensatz im Evidence Ledger identifiziert. Der Hash ist ein Fingerabdruck des Inhalts. Ändert sich nach der Berechnung des Hashes ein Byte des Dokuments, stimmt der Fingerabdruck nicht mehr überein. Der Hash wird unabhängig vom Dokument gespeichert, sodass Dokument und Fingerabdruck jederzeit in der Zukunft gegeneinander geprüft werden können.
Ein Chain-of-Custody-Nachweis. Jede Aktion am Dokument nach der Erstellung wird protokolliert (Zugriff, Konvertierung, Archivierung, Abruf), mit der Identität des Handelnden, Zeitstempel und IP-Adresse, und in ein manipulationsresistentes Audit-Protokoll geschrieben.
Zusammen beantworten diese drei Elemente die Fragen, die Gerichtsverfahren stellen: Existierte dieses Dokument zu diesem Zeitpunkt in dieser Form, wurde es seitdem verändert, und wer hatte es in der Hand.
Die praktische Frage
Am stärksten zählt die Frage unter diesen Umständen: regulierte Branchen, Transaktionen mit hohem Wert, lange Aufbewahrungsfristen, bestrittene Rechnungen oder jeder Kontext, in dem eine Gegenpartei einen Anreiz haben könnte, die Integrität Ihrer Aufzeichnungen anzufechten.
Für diese Anwendungsfälle ist die Lücke zwischen “wir haben die Rechnung” und “wir können beweisen, dass die Rechnung echt ist” real, und Formatkonformität allein schließt sie nicht.
Der praktikabelste Ansatz ist, die Nachweisebene bei der Dokumenterstellung einzubauen statt rückwirkend. Ein RFC 3161-Zeitstempel und eine Hash-Kette, die zum Zeitpunkt der Erzeugung hinzugefügt werden, kosten bei der Prüfung nichts. Sie rückwirkend hinzuzufügen oder zu argumentieren, dass vorhandene Aufzeichnungen ohne sie ausreichen, ist schwieriger.
SealDoc ergänzt jedes Dokument, das die Pipeline durchläuft, um die Nachweisebene: einen RFC 3161-Zeitstempel, standardmäßig bei einer unabhängigen EU-Time-Stamping-Authority angefordert, eine SHA-256-Chain-of-Custody über die Verarbeitungsschritte, ein SHA-384-Evidence-Ledger über den Datensatz und, auf Anfrage, ein Legal Evidence Pack, das beides in einem einzigen prüfbaren Archiv bündelt.