Accounting-Betrieb und Compliance

Diese Betriebsseite richtet sich an Administratoren und fachliche Betreiber. Nach dem Lesen wissen Sie, welche Konfiguration Accounting benötigt, welche workerbasierten Läufe Sie überwachen und welche Nachweise für GoBD-nahe Prozesse relevant sind.

Workspace führt Accounting als tenantgebundenes Hauptbuch mit Belegarchiv, Perioden, Steuerkennzeichen, Exportläufen und Drift-Checks. Die technische Plattform schützt diese Daten über Berechtigungen, StorageObject-Bindung, Taskstream-Jobs und nachvollziehbare Hashes.

Voraussetzungen

Prüfen Sie vor dem produktiven Einsatz:

Mandant, Währung und steuerliches Profil sind fachlich geklärt.
Geschäftsjahr und Buchungsperioden sind angelegt.
Kontenrahmen, Konten und Steuerkennzeichen sind geprüft.
Buchungsprofil und Buchungsprofil-Rollen sind geprüft und aktiv.
Dokument- und Storage-Kontexte für Accounting-Belege sind vorbereitet.
Rollen enthalten nur die nötigen Accounting-Scopes.
Taskstream läuft und verarbeitet Jobs.
Backup und Restore wurden für Datenbank und Storage getestet.

Go-live-DE-Abnahme

Für einen ersten produktiven Einsatz in Deutschland dokumentieren Sie vor dem Start diese Gates:

Der Accounting-Export-Store ist tenantgebunden konfiguriert und DATEV-/GoBD- Läufe erzeugen retained StorageObjects im Kontext accounting_export.
Mindestens ein repräsentativer Belegpfad wurde von StorageObject über Journalbuchung, DATEV-Export, GoBD-Export, Steuerreport-Freigabe und Drift-Check ohne Befund geprüft.
DATEV-Exportdateien wurden mit der Steuerberatung gegen einen echten Import getestet.
GoBD-Exportpakete und die Verfahrensdokumentation wurden mit Steuerberatung oder Prüfer abgestimmt.
Backup und Restore wurden gemeinsam für Datenbank und Storage in einer isolierten Umgebung wiederhergestellt.
Periodensperren, Rollen und kritische Scopes wurden mit den realen Verantwortlichen abgenommen.

Buchungen mit Kostenstellen oder Projekten benötigen ein explizites DATEV-Mapping. Solange dieses Mapping nicht umgesetzt ist, bricht der DATEV-Export für solche Buchungen ab, statt die Dimensionen still auszulassen.

Kontenrahmen und Buchungsprofile

Der produktive Kontenrahmen ist tenantgebunden konfigurierbar. Workspace legt keinen globalen SKR04-Zwang in den Ledger-Kern. Automatische Buchungen verwenden Buchungsprofile, die stabile fachliche Rollen auf konkrete Konten und optional Steuerkennzeichen abbilden.

Prüfen Sie vor Go-live:

Welcher Kontenrahmen gilt für Mandant, Land und Währung?
Ist genau ein aktives Standard-Buchungsprofil für diese Kombination gesetzt?
Sind Rollen für Forderungen, Verbindlichkeiten, Bank, Erlöse, Steuer, Bestand, WE/RE, Preisabweichung, Wareneinsatz und Retouren gepflegt?
Stimmen Gültigkeitszeiträume der Rollen zum geplanten Buchungsstart?

Für Deutschland können Sie über Finanzen > Buchhaltung > Buchungsprofile die Aktion SKR04-Starter anlegen ausführen. Die Aktion legt ein idempotentes Template DE SKR04 Starter 2026 mit Konten, Steuerkennzeichen, Buchungsprofil und Rollen an und kann es als Standard setzen. Verwenden Sie diesen Starter nur als geprüfte Vorlage. Stimmen Sie Konten, Steuerkennzeichen und Rollen mit der Steuerberatung ab, bevor Sie produktive Buchungen zulassen.

PostgreSQL verhindert, dass mehrere aktive Standard-Buchungsprofile für denselben Tenant, dasselbe Land und dieselbe Währung parallel existieren. Wenn diese Invariante verletzt würde, schlägt die Speicherung fehl; reparieren Sie dann die Konfiguration statt Projektionen auf Ersatzkonten umzuleiten.

Berechtigungen

Trennen Sie Rollen nach Aufgabe:

Rolle	Typische Rechte
Buchhaltung	Belege prüfen, Kontierung vorbereiten, Buchungen und OPOS prüfen.
Freigeber	fachliche Freigaben und Zahlungsfreigaben ausführen.
Geschäftsführung	Berichte, Periodenstatus und kritische Freigaben prüfen.
Steuerberater	Journal, Belege, DATEV-/GoBD-Läufe und Steuerreports lesen.
Prüfer	read-only Zugriff und Exportnachweise prüfen.
Admin	Stammdaten, Kontenrahmen, Rollen und technische Konfiguration pflegen.

Vergeben Sie Schreibrechte für kritische Konfigurationen nicht breit. Wer eine Eingangsrechnung freigibt, sollte nicht dieselbe Zahlung ohne weitere Prüfung freigeben. Kritische Aktionen müssen über Workflow, Taskstream oder servicegebundene Aktionen laufen, nicht über direkte Datenänderung.

Storage und Belegarchiv

Accounting-Belege referenzieren StorageObjects. Accounting speichert keine freien Dateipfade als Wahrheit. Beim Binden einer Datei prüft der Service Mandant, Kontext, Hash, Scanstatus und Retention.

Prüfen Sie bei Archivfragen:

Ist das StorageObject im passenden Tenant?
Gehört der Kontext zu accounting_document oder einem zulässigen Exportkontext?
Ist ein Hash vorhanden?
Ist der Scanstatus sauber, übersprungen oder fachlich erlaubt leer?
Deckt die Storage-Retention die Accounting-Aufbewahrung ab?

Originale werden nicht überschrieben. Eine neue Fassung entsteht als neue Dateireferenz. Bei E-Rechnungen ist der strukturierte XML-Anteil der führende Nachweis für maschinenlesbare Verarbeitung.

Worker und Monitoring

Accounting-Jobs laufen über Taskstream. Prüfen Sie Jobs unter Automatisierung > Taskstream > Jobs.

Runnable	Zweck
`accounting.bank.match_open_items`	Bankumsätze gegen offene Posten matchen.
`accounting.datev.export`	DATEV-Grundexport erzeugen.
`accounting.gobd.export`	GoBD-Prüfexport mit Manifest und Hash-Lineage erzeugen.
`accounting.tax_report.prepare`	Steuerreport-Snapshot vorbereiten.
`accounting.drift.check`	Journal-Balancing und OPOS-Konsistenz prüfen.

Ein Job muss tenantgebunden sein. Tenant-Mismatches schlagen fail-closed fehl. Wiederholen Sie fehlgeschlagene Jobs erst, nachdem Ursache, Zeitraum und Payload geprüft sind.

Perioden und Sperren

Perioden steuern, ob Buchungen in einem Zeitraum zulässig sind. Nach Steuerreport-Freigabe sollte die Periode mindestens weich gesperrt sein. Nach Jahresabschluss wird sie hart gesperrt.

Korrigieren Sie gesperrte Zeiträume nicht durch direkte Datenänderung. Nutzen Sie Storno- und Korrekturbuchungen in einer offenen Periode. So bleiben ursprünglicher Vorgang, Korrektur und Belegkette nachvollziehbar.

DATEV, GoBD und Steuerreports

DATEV- und GoBD-Läufe erzeugen reproduzierbare Exportläufe mit Status, Zeitraum, Zählern, Artefakt-Metadaten und Payload-Hash. Steuerreports speichern Reporttyp, Land und Profilversion. Deutschland ist das erste Profil; weitere Länder sollen über neue Profile ergänzt werden, nicht über deutsche Sonderlogik im Grundvertrag.

Die Steuerreport-Freigabe ist eine kritische Aktion. Sie benötigt einen eigenen Scope, prüft den Snapshot-Hash und sperrt die Periode weich, wenn die Freigabe erfolgreich ist. Bei Drift bleibt die Periode unverändert und der Report muss neu vorbereitet werden.

Prüfen Sie vor Übergabe an Steuerberatung oder Prüfung:

Zeitraum und Geschäftsjahr stimmen.
Journalbuchungen sind vollständig und balanciert.
Beleg- und Datei-Referenzen sind vorhanden.
Exportlauf ist erfolgreich abgeschlossen.
Payload-Hash und Artefakt-Metadaten sind gespeichert.
Der Exportlauf ist archiviert und später reproduzierbar.

Backup und Restore

Backup ist nur belastbar, wenn Datenbank und Storage gemeinsam wiederhergestellt werden können. Testen Sie Restore regelmäßig mit einem isolierten Tenant oder einer Testumgebung.

Nach einem Restore prüfen Sie:

Die Accounting-Tabellen sind vorhanden.
Belegdateien lassen sich über StorageObjects wiederfinden.
Hashes stimmen mit den gespeicherten Metadaten überein.
Journal und Buchungszeilen sind vollständig.
Exportläufe behalten Artefakt- und Payload-Hashes.
Taskstream-Jobs starten nicht ungewollt alte Läufe neu.

Erfolg erkennen

Der Betrieb ist bereit, wenn ein sachkundiger Dritter die Geschäftsvorfälle über Journal, Konto, Buchung, Beleg und Originaldatei nachvollziehen kann. Zusätzlich müssen Rollen, Periodensperren, Worker-Läufe, Backup/Restore und Exportnachweise geprüft und dokumentiert sein.

Nächste Schritte

Lesen Sie die Nutzerübersicht Accounting verstehen.
Prüfen Sie Automatisierung mit Automatisierung, Workflows und Reporting.
Prüfen Sie Compliance-Nachweise mit Compliance verwalten.