Dokumenttyp: Referenz/Prüfkatalog.
Dieser Prüfkatalog richtet sich an Administratoren, Buchhaltung, Steuerberatung und Prüfer. Er ordnet die wichtigsten GoBD- und IKS-Prüffälle dem aktuellen Accounting-Produktstand zu. Nach dem Lesen sehen Sie, welche Punkte technisch erfüllt sind, welche Punkte noch Folgearbeit brauchen und wo eine externe fachliche Prüfung nötig bleibt.
Der Katalog ersetzt keine Steuerberatung und keine rechtliche Freigabe. Er ergänzt die Betriebsseite Accounting-Betrieb und Compliance und die fachliche Accounting-Übersicht Accounting verstehen.
| Status | Bedeutung |
|---|
Erfüllt | Der aktuelle Produktstand enthält einen prüfbaren technischen Vertrag für diesen Punkt. |
Teilweise | Der Produktstand enthält Bausteine, aber Abdeckung, Bedienpfad, Testpfad oder Dokumentation sind noch nicht vollständig. |
Offen | Der Punkt ist als Produkt- oder Prozesslücke bekannt. |
Externe Prüfung nötig | Workspace kann Nachweise vorbereiten, aber Steuerberatung, Prüfer oder Betreiber müssen den Punkt fachlich abnehmen. |
| Testfall | Prüfung | Soll-Ergebnis | Produktstand | Status |
|---|
| 1.1 Festschreibung | Kann eine Buchung oder Rechnung nach festgeschrieben oder abgeschlossen noch geändert oder gelöscht werden? | Nein. Änderungen laufen nur über Storno oder Ergänzung. | Gebuchte Journal Entries werden über Posting-Engine und Statusmodell geführt; Journal Lines blockieren direkte Updates und Storno in offener Korrekturperiode ist vorhanden. Rechnungs-/Dokument-Endzustände und alle Bedienpfade brauchen noch vollständige Go-live-Abdeckung. | Teilweise |
| 1.2 Lückenlose Belegnummernvergabe | Werden Rechnungs- oder Buchungsnummern sequentiell und ohne manuelles Überspringen vergeben? | Ja. Manuelles Freihalten oder Überspringen ist technisch ausgeschlossen. | Journal Entries erhalten entryNo serverseitig je Journal und Geschäftsjahr. Rechnungsnummernkreise und PostgreSQL-Contract-Sweep bleiben für die Gesamtfreigabe zu prüfen. | Teilweise |
| 1.3 Audit Trail | Wird protokolliert, wer wann kritische Werte geändert hat? | Ja. Der Audit Trail zeigt Akteur, Zeitpunkt, alten und neuen Wert. | Accounting protokolliert Buchungen, Stornos, Archivierung, Exporte, Steuerreport-Freigaben und Periodenlocks mit Payload-Hash. Vollständige Stammdaten-Alt/Neu-Historie bleibt IKS-Prüfpunkt. | Teilweise |
| 1.4 Löschsperre für Bewegungsdaten | Können Administratoren über das Frontend Perioden, Buchungen oder Einzelbelege physisch löschen? | Nein. Daten bleiben erhalten; höchstens Statuswechsel mit Historie. | Accounting-Ressourcen bieten keine normalen Delete-Pfade für diese Flüsse; revisionsrelevante Accounting-Datensätze blockieren zusätzlich GORM-Deletes mit einem typed error. Direkte Datenbank-Administrationsrechte bleiben Betriebsverantwortung. | Erfüllt |
| Testfall | Prüfung | Soll-Ergebnis | Produktstand | Status |
|---|
| 2.1 Login- und Berechtigungskonzept | Haben Benutzer eindeutige IDs und rollenbasierte Rechte, etwa Erfasser und Buchhalter mit Freigaberecht? | Ja. Aktionen sind einer Person zuordenbar; Sammel-Logins sind ausgeschlossen. | Workspace arbeitet mit Identitäten, Rollen und Scopes. Die konkrete Rollenvergabe und das Verbot von Sammel-Logins müssen pro Tenant organisatorisch geprüft werden. | Teilweise |
| 2.2 System-Logbuch | Werden kritische Ereignisse wie Backups, Updates und Fehllogins protokolliert? | Ja. Normale User können diese Logs nicht manipulieren oder löschen. | Accounting- und System-Auditlogs existieren für Produktaktionen. Backup-, Update- und Infrastrukturereignisse sind Betriebs- und Ops-Nachweise und nicht vollständig durch Accounting allein belegt. | Teilweise |
| 2.3 Periodenabschluss | Können nach endgültigem Monats- oder Jahresabschluss noch Buchungen in diese Periode einfließen? | Nein. Die Periode ist hart gesperrt; Wiederöffnung wird speziell protokolliert. | Periodenstatus hard_locked blockiert Buchungen; Steuerreport-Freigabe kann soft-locken. Eine vollständige Reopen-Prozedur ist nicht freigegeben und bleibt eigener Architektur-/Betriebsschnitt. | Teilweise |
| Testfall | Prüfung | Soll-Ergebnis | Produktstand | Status |
|---|
| 3.1 Belegverknüpfung | Ist jede Buchung untrennbar mit dem zugrundeliegenden Beleg verknüpft? | Ja. Der Beleg ist aus dem Buchungskontext aufrufbar. | Journal Entries können Accounting-Belege referenzieren; strukturierte Rechnungsdateien benötigen beim Accounting-Beleg gültige E-Rechnungsvalidierung. GoBD-Export nimmt Belege, Belegdateien und Validierungsbefunde auf. Nicht jeder manuelle Buchungspfad erzwingt heute bereits einen Beleg. | Teilweise |
| 3.2 Rechnerische Richtigkeit | Rechnet das System Netto, Umsatzsteuer und Brutto inklusive Rundungen korrekt? | Ja. Summen- und Rundungsfehler sind ausgeschlossen. | Geldwerte verwenden Dezimaltypen und Buchungszeilen müssen balancieren. Massendaten-, Steuer- und Rundungs-Golden-Tests bleiben für die Freigabe zu ergänzen. | Teilweise |
| 3.3 Währungsumrechnungen | Werden Fremdwährungsbelege mit historischem Kurs zum Buchungszeitpunkt fixiert? | Ja. Spätere Kursänderungen verändern historische Werte nicht. | Journal Lines speichern Währung und Basiswährungsbetrag; Buchungen müssen auch in Basiswährung ausgeglichen sein. Ein vollständiger historischer FX-Kursvertrag mit Kursquelle und Kursversion ist noch nicht umgesetzt. | Teilweise |
| Testfall | Prüfung | Soll-Ergebnis | Produktstand | Status |
|---|
| 4.1 Betriebsprüfer-Export | Können steuerlich relevante Daten über eine Standardschnittstelle exportiert werden? | Ja. Der Export liefert Daten und Strukturbeschreibung ohne Datenverlust. | GoBD-Export erzeugt wahlweise ein reproduzierbares JSON-Paket oder ein ZIP-Evidenzpaket mit index.xml, CSV-Tabellen, Manifest, Feldbeschreibung, Journal, Konten, Belegen, Belegdateien, E-Rechnungsvalidierungen, Audit-Events und Hash-Lineage. DATEV kann zusätzlich ein EXTF-CSV-Evidenzartefakt mit Belegobjektverweis erzeugen. Freigegebene DE-UStVA-Reports erzeugen ein hashbares JSON-Handoff im Export-Store; ERiC/ELSTER-Übermittlung ist nicht enthalten. DATEV-Testimport und GoBD-Prüflesbarkeit sind noch nicht extern abgenommen. | Teilweise |
| 4.2 Backup und Recovery | Sichert das System Daten, Anhänge und Logs konsistent und ist Restore nachweisbar? | Ja. Ein Restore-Protokoll belegt die Wiederherstellung. | Die Produktdoku verlangt gemeinsamen Restore für Datenbank und Storage. Der konkrete Restore-Nachweis entsteht im Betreiber-Testsystem. | Externe Prüfung nötig |
| 4.3 Unveränderte Belegarchivierung | Bleiben hochgeladene Originalbelege exakt erhalten? | Ja. Keine verschlechternde Konvertierung und keine unbemerkte Veränderung. | Accounting-Dateien speichern StorageObject-ID, MIME-Type, Größe und SHA-256. Drift-Checks prüfen Storage-Verträge. Storage-Retention und reale Archivprozesse brauchen Betreiberprüfung. | Teilweise |
| Testfall | Prüfung | Soll-Ergebnis | Produktstand | Status |
|---|
| 5.1 Systemdokumentation | Gibt es eine aktuelle technische Beschreibung von Tabellen, Datenflüssen und Architektur? | Ja. Architektur und Datenflüsse sind nachvollziehbar dokumentiert. | ADRs, Work-Orders, API-Doku und Public Docs beschreiben die Accounting-Architektur. Eine vollständige prüferfertige Tabellen- und Datenflussdokumentation bleibt zu finalisieren. | Teilweise |
| 5.2 Anwenderhandbuch | Gibt es eine verständliche Anleitung für GoBD-konforme Bedienung? | Ja. Nutzer wissen, wie sie korrekt arbeiten. | Die Accounting-Nutzer- und Betriebsseiten erklären die wichtigsten Flüsse. Ein vollständiges GoBD-Anwenderhandbuch mit Rollen, Tagesgeschäft und Fehlerbehandlung bleibt Folgearbeit. | Teilweise |
| 5.3 Muster-Verfahrensdokumentation | Liefert die Software eine Vorlage für Belegeingang bis Archivierung? | Ja. Kunden können daraus ihre eigene Verfahrensdokumentation ableiten. | Die Vorlage Accounting-Muster-Verfahrensdokumentation beschreibt Belegeingang, Buchung, Archivierung, Exporte und Kontrollen. Kunden müssen sie tenant-spezifisch ausfüllen und extern prüfen lassen. | Teilweise |
Der Prüfkatalog ist bereit für einen Go-live-Review, wenn jeder Eintrag einen Nachweisort, eine verantwortliche Rolle und einen aktuellen Status hat. Für Deutschland müssen DATEV-Testimport, GoBD-Prüflesbarkeit, Verfahrensdokumentation, Backup/Restore und IKS-Kontrollen extern geprüft oder als offene Blocker dokumentiert sein.