Ab Version 3.0 ist Receipts Space für den GoBD-konformen Gebrauch ausgelegt (Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form sowie zum Daten- zugriff (GoBD), Stand 14. Juli 2025)
Unterstützung durch die Benutzeroberfläche
Ist “Revisionskonformität” aktiviert, werden Einträge mit der Bestätigung “abgeschlossen” und somit besonders geschützt. Die “Revisionskonformität” unterstützt dich bei der ordnungsgmäßen Ablage von Dokumenten, wie sie in Deutschland in den GoBD beschrieben sind.
Ist die Funktion aktiviert, genießen bestätigte Einträge besonderen Schutz: Bis auf Schlagwörter, Notizen und Markierungen werden alle Felder schreibgeschützt, um versehentliche oder unerwünschte Änderungen zu verhindern. Soll ein Eintrag dennoch bearbeitet werden, muss der Schreibschutz explizit aufgehoben werden – ein Schritt, der automatisch protokolliert wird.
Zu jedem Eintrag kann jederzeit eine Historie eingesehen und exportiert werden. Diese enthält eine verständliche, chronologische Auflistung aller relevanten Änderungen. Auch frühere Versionen der Daten bleiben so nachvollziehbar.
Über diverse Exportformate lässt sich der gesamte Datenbestand ausgeben – inklusive der unveränderten Originaldokumente, wie sie ursprünglich importiert wurden.
Technische Umsetzung der Anforderungen
Die Architektur von Receipts nutzt einen manipulationssicheren Local-First-Ansatz, der die zentralen Anforderungen der GoBD technisch untermauert:
1. Unveränderbarkeit
Jede Änderung an Daten wird als Transaktion in einem fortlaufenden Log gespeichert (Append-Only). Ein einfaches “Überschreiben” ist systembedingt nicht möglich.
- Transaktions-Verkettung: Jede Transaktionsdatei enthält den SHA256-Hash ihrer Vorgängerdatei (Feld
p). Dies erzeugt eine kryptografisch gesicherte Kette. - Integritätsschutz: Eine nachträgliche Manipulation alter Transaktionen (z.B. im Dateisystem) würde den Hash-Wert verändern und die Kette brechen. Dies wird bei der Integritätsprüfung vom System erkannt.
2. Nachvollziehbarkeit und Nachprüfbarkeit
- Lückenloses Journal: Jeder Geschäftsvorfall (Erstellung, Bearbeitung, Löschung) erzeugt einen neuen Eintrag im Transaktionslog mit Zeitstempel (
t) und Versionsnummer (_v). - Historie: Der Zustand eines Datensatzes kann theoretisch zu jedem beliebigen Zeitpunkt rekonstruiert werden (progressive und retrograde Prüfbarkeit).
- Protokollierung: Wird ein bereits “festgeschriebener” (
confirmed) Eintrag nachträglich bearbeitet, erzeugt dies einen neuen Log-Eintrag, der die Änderung transparent dokumentiert.
3. Maschinelle Auswertbarkeit und Datensicherheit
- Asset-Integrität: Dateianhänge (Belege) werden unveränderlich gespeichert (Content-Addressable Storage). Die Integrität wird durch SHA256-Prüfsummen in der Referenz sichergestellt.
- Format: Die Daten liegen im offenen, dokumentierten JSON/JSONL-Format vor. Dies sichert die langfristige Lesbarkeit und ermöglicht den Datenzugriff auch unabhängig von der Applikation (Z3-Zugriff).
- Verschlüsselung: Optional können Workspaces vollständig verschlüsselt werden (AES-256-GCM), wobei die prüfbare Verkettung der Transaktionen auch im verschlüsselten Zustand erhalten bleibt.
Einschränkungen und Nutzerpflichten
Software allein kann niemals vollständig “GoBD-konform” sein, sie ist lediglich ein Werkzeug zur Erfüllung der Anforderungen. Die rechtssichere Einhaltung der GoBD obliegt stets dem Steuerpflichtigen und erfordert organisatorische Maßnahmen. Folgende Punkte sind vom Nutzer besonders zu beachten:
- Verfahrensdokumentation: Der Nutzer muss eine eigene Verfahrensdokumentation erstellen, die beschreibt, wie Belege im Unternehmen empfangen, digitalisiert, verarbeitet und archiviert werden (vgl. Rz. 151 ff. GoBD). Die hier vorliegende technische Dokumentation kann als technischer Teil (Anlage) dazu dienen, ersetzt aber nicht die Beschreibung der betrieblichen Abläufe.
- Internes Kontrollsystem (IKS): Es liegt in der Verantwortung des Nutzers, Zugriffsrechte und Zuständigkeiten organisatorisch zu regeln und Kontrollmechanismen zu etablieren (z.B. 4-Augen-Prinzip), um Fehler oder Manipulationen zu verhindern.
- Datensicherung: Da Receipts Space nach dem “Local-First”-Prinzip arbeitet, werden Daten primär auf den Geräten des Nutzers gespeichert. Die Verantwortung für regelmäßige, revisionssichere Backups und die Sicherstellung der langfristigen Verfügbarkeit der Daten/Hardware liegt beim Nutzer. Eine reine Synchronisation ersetzt kein unabhängiges Backup-Konzept gegen Datenverlust (z.B. durch Ransomware).
- Zeitgerechte Erfassung: Die technische Protokollierung dokumentiert lediglich den Zeitpunkt der Erfassung im System. Sie kann nicht heilen, wenn Belege erst verspätet (d.h. nicht zeitnah nach Entstehung/Eingang) digitalisiert werden. Die organisatorischen Abläufe müssen die Zeitgerechtigkeit sicherstellen (vgl. Rz. 45 ff. GoBD).
- Abhängigkeit von der Systemzeit: Die Protokollierung der Zeitstempel in den Transaktionen beruht auf der Systemzeit des erfassenden Geräts. Da im “Local-First”-Ansatz keine zentrale Server-Instanz die Zeit hoheitlich vorgibt, stützt sich die Nachvollziehbarkeit auf die korrekte Einstellung der Endgeräte. Eine bewusste Manipulation der Systemzeit durch den Benutzer kann softwareseitig nicht vollständig unterbunden werden und muss durch administrative Restriktionen am Betriebssystem verhindert werden.
- Benutzerzuordnung: In kollaborativen Umgebungen identifiziert das Protokoll die ändernde Instanz über eine eindeutige
clientId(Geräte-ID). Um der Anforderung nach Feststellung des verantwortlichen Bearbeiters (Rz. 100 GoBD) zu genügen, muss der Nutzer organisatorisch sicherstellen, dass eine eindeutige Zuordnung von Geräten bzw. Benutzerprofilen zu natürlichen Personen besteht (z.B. durch personalisierte Windows/macOS-Benutzerkonten).
Rechtlicher Hinweis und Gewährleistungsausschluss
Die in Receipts Space implementierten Funktionen unterstützen den Anwender bestmöglich bei der Einhaltung der GoBD-Vorgaben. Die finale Verantwortung für die ordnungsmäßige Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen liegt jedoch gemäß § 146 AO allein beim Steuerpflichtigen.
Wir übernehmen ausdrücklich keine Gewähr für die vollständige Erfüllung aller gesetzlichen Anforderungen im konkreten Einzelfall und haften nicht für steuerliche Nachteile, Hinzuschätzungen oder Bußgelder, die aus der Nutzung der Software, einer fehlerhaften Konfiguration oder mangelhaften organisatorischen Begleitmaßnahmen resultieren. Eine offizielle behördliche Zertifizierung der Software existiert nicht, da die Finanzverwaltung selbst keine Software-Zertifikate vergibt und Bescheinigungen Dritter keine Bindungswirkung entfalten (vgl. Abschnitt 12 GoBD). Wir empfehlen dringend, die konkrete Einsatzweise der Software und die erstellte Verfahrensdokumentation mit einem steuerlichen Berater abzustimmen.