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.
• Für jeden verwendeten Accounting-Export existiert ein gültiges Exportprofil. Bei der Regel explicit_mapping sind alle benötigten Export-Kontenzuordnungen für den Exportzeitraum vollständig und eindeutig.
• Der Commerce-Rechnungsbuchungsmodus des Standard-Buchungsprofils ist bewusst auf manual oder automatic gesetzt. Für automatic ist ein fachlich freigegebener Startzeitpunkt gepflegt.
• Für Commerce-Ausgangsrechnungen existieren genau ein gültiges Standard-Buchungsprofil, eine Forderungsrolle, passende Steuerbehandlungs-Mappings, ein offenes Geschäftsjahr, eine offene Periode und ein Accounting-Journal oder der Integrationsaufruf übergibt diese Ziele explizit.
• 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-Prüfung

Für einen ersten produktiven Einsatz in Deutschland dokumentieren Sie vor dem Start diese Gates. Diese Prüfung macht Produktfunktionen, Schnittstellen und Betriebsnachweise test- und einschätzbar; sie ist keine formale Anerkennung oder Zertifizierung durch Finanzamt, DATEV, ELSTER oder Behörden.

• Der Accounting-Export-Store ist tenantgebunden konfiguriert und DATEV-/GoBD- Läufe sowie freigegebene UStVA-Handoffs 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.
• Der repräsentative DATEV-Lauf verwendet ein geprüftes Exportprofil; bei expliziter Zuordnung wurden fehlende, abgelaufene und überlappende Export-Kontenzuordnungen als blockierende Fehler getestet.
• 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 geprüft und bestätigt.

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.

Go-live-Readiness prüfen

Nutzen Sie GET /accounting/readiness/go-live, um die technische Go-live- Evidenz eines Mandanten kompakt zu prüfen. Der Endpunkt benötigt den Scope accounting_readiness:read und verändert keine Accounting-Daten.

Die Antwort liefert status, checks, evidence, drilldowns, artifacts, evidenceLinks und permissionReview. ready bedeutet, dass die geprüften technischen Nachweise vorhanden sind. attention bedeutet, dass mindestens ein Nachweis fehlt oder der Drift-Check Befunde meldet. Die Checks verwenden stabile Codes und reasonKey-/detailKeys-Werte, damit Frontend, Runbooks und Prüfprotokolle die Hinweise lokalisiert oder regelbasiert auswerten können.

Nutzen Sie in der Oberfläche Finanzen > Buchhaltung > Arbeitsstatus. Die Go-live-Console zeigt dieselben Readiness-Checks mit Drilldown-Zielen, validierte DATEV-/GoBD-/Steuer-Handoff-Artefakte, Evidence-Links für Betriebsnachweise und die Abdeckung der kritischen Accounting-Scopes durch Mandantenrollen. Artefakt- und Evidence-Links verwenden den bestehenden Storage-Download-Vertrag; die Console zeigt nur geprüfte interne Download- Referenzen.

Der Readiness-Report prüft diese Nachweise:

Erkennen Sie Erfolg daran, dass status auf ready steht und jeder Check passed meldet. Verwenden Sie den Report als technische Prüfhilfe, nicht als Ersatz für Steuerberaterprüfung, Restore-Protokoll oder GoBD- Verfahrensdokumentation.

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?
• Welche Exportprofile gelten für die angebundenen Zielsysteme?
• Verwendet jedes Profil bewusst interne Kontonummern oder vollständig gepflegte Export-Kontenzuordnungen?

Exportprofile und Export-Kontenzuordnungen sind eigene tenantgebundene Konfigurationsressourcen. Pflegen Sie keine DATEV- oder Fremdsystemnummer am allgemeinen Konto. Vergeben Sie für die Konfiguration die separaten Scopes accounting_export_profiles:* und accounting_account_export_mappings:*; DATEV-Start und -Freigabe bleiben über die eigenen accounting_datev_exports:*-Scopes geschützt. Wer einen DATEV-Lauf startet, benötigt zusätzlich accounting_export_profiles:list, damit das auswählbare Profil autorisiert aufgelöst werden kann.

Für Deutschland können Sie über Finanzen > Buchhaltung > Konfiguration > 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.

Commerce-Ausgangsrechnungen buchen

Commerce-Ausgangsrechnungen werden nicht über Direktzugriff auf Journal- oder OPOS-Tabellen gebucht. Workspace nutzt die Commerce-Rechnungsprojektion als produktgebundenen Servicepfad. Die Rechnungsdetailansicht zeigt im Tab Accounting, ob die Rechnung buchbar ist und welche Voraussetzung fehlt.

Die Readiness-Prüfung blockiert fail-closed, wenn eine dieser Voraussetzungen nicht eindeutig ist:

• Die Rechnung ist nicht finalisiert oder fachlich nicht projektierbar.
• Es gibt kein genau passendes aktives Standard-Buchungsprofil für Land, Währung und Rechnungsdatum oder der Aufruf übergibt kein explizites Profil.
• Die Forderungsrolle oder die Steuerbehandlungs-Mappings fehlen.
• Geschäftsjahr oder Periode decken das Rechnungsdatum nicht offen ab.
• Das Journal ist nicht eindeutig oder nicht explizit übergeben.
• Die Rechnung wurde bereits projiziert; dann zeigt Workspace die bestehende Projektion statt eine zweite Buchung anzulegen.

Beheben Sie Blocker in den jeweiligen Stammdaten. Legen Sie keine Ersatzbuchungen direkt im Journal an, wenn die Projektion wegen fehlender Konfiguration blockiert.

Automatische Projektion aktivieren

Der Standardwert manual erhält den bisherigen manuellen Projektionspfad. Aktivieren Sie automatic erst, wenn Buchungsprofil-Rollen, Steuerbehandlungs-Mappings, Perioden und Journal mit repräsentativen Rechnungen geprüft sind. Setzen Sie commerceInvoiceAutomaticFrom auf den freigegebenen Cutover-Zeitpunkt. Workspace nimmt nur Rechnungen auf, die ab diesem Zeitpunkt finalisiert werden; Altbelege werden nicht still nachverarbeitet.

Die Finalisierung und der Accounting-Lauf bleiben getrennt. Workspace schreibt den Automatikstatus und das persistente Ereignis gemeinsam mit der Rechnungstransition. Fachliche Readiness-Blocker erhalten den Status blocked; technische Fehler werden begrenzt wiederholt und enden bei ausbleibendem Erfolg als failed. Prüfen Sie den Lauf, beheben Sie die konkrete Ursache und nutzen Sie danach die Retry-Aktion. Eine bereits bestehende Projektion bleibt idempotent und erzeugt keine Doppelbuchung.

Beim Storno erzeugt Workspace eine Gegenbuchung und löscht die ursprüngliche Buchung nicht. Ein teilweise oder vollständig ausgeglichener Debitoren-OPOS blockiert das Storno. Ein noch nicht ausgeführter Automatiklauf wird beim Storno beendet, damit er keine veraltete Projektion erzeugt.

Historische Rechnungen prüfen

Nutzen Sie den historischen Prüfpfad ausschließlich für offene Rechnungen vor dem Automatik-Startzeitpunkt, deren Beträge konsistent sind und deren Steuerklassifikation fehlt oder ausdrücklich als Altbestand markiert ist. Workspace verändert weder Rechnung noch Rechnungspositionen.

Gehen Sie so vor:

1. Legen Sie die Prüfung mit Begründung, optionalem Evidenzverweis und genau einem Steuerbehandlungs-Mapping pro Rechnungsposition an.
2. Prüfen Sie den gespeicherten Source-Fingerprint und die Mapping-Snapshots und reichen Sie die Prüfung ein.
3. Lassen Sie eine andere Finance-Person die Prüfung freigeben. Die Person, die angelegt oder eingereicht hat, darf nicht freigeben.
4. Führen Sie Freigabe und Projektion mit approve-and-project atomar aus.

Nach dem Einreichen bleibt die Revision unveränderlich. Erstellen Sie nach einer Ablehnung eine neue Revision, statt die alte zu überschreiben. Wenn sich die Quellrechnung zwischenzeitlich ändert oder ein Mapping nicht mehr passt, blockiert Workspace die Freigabe. Sie erkennen Erfolg am Status approved, dem verknüpften Projektionsdatensatz sowie an Accounting-Beleg, Journalbuchung und Debitoren-OPOS.

Fremdwährungen

Erfassen Sie Fremdwährungsbuchungen immer mit Basiswährung, Basisbetrag, historischem Kurs, Kursquelle und Kursstichtag. Workspace speichert diese Werte als Journal-Line-Snapshot und ändert sie nach dem Buchen nicht automatisch.

Alternativ referenzieren Buchungszeilen einen gepflegten Tenant-Wechselkurs über tenantExchangeRateId. Workspace prüft dann Tenant, Aktivstatus, Gültigkeitsfenster und Währungspaar und übernimmt Kurs, Quelle, Kursstichtag und Basisbetrag als unveränderlichen Snapshot in die Journal Line.

Für Buchungen in der Basiswährung reicht der Betrag in Basiswährung. Für Fremdwährungen lehnt der Posting-Service Buchungen ohne vollständigen Kurs-Snapshot oder gültige tenantExchangeRateId ab. Automatische Kursbeschaffung, implizite Kursauswahl, Neubewertung und Kursdifferenzbuchungen gehören nicht zum aktuellen MVP.

Berechtigungen

Trennen Sie Rollen nach Aufgabe:

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.

E-Rechnungsvalidierungen prüfen

Prüfen Sie strukturierte Rechnungen über Finanzen > Buchhaltung > E-Rechnungsvalidierungen. Die Liste zeigt Status, Format, Profil, Validator, Regelwerk und Validierungszeitpunkt. Öffnen Sie den Befund, wenn ein Beleg in der Go-live-Console oder im Drift-Check auffällig ist.

Ein Beleg ist technisch belastbar archiviert, wenn diese Punkte stimmen:

• Der Beleg verweist auf ein StorageObject im Tenant.
• Der Hash im StorageObject stimmt mit dem Hash im Validierungsbefund überein.
• Status ist valid oder fachlich akzeptiert warning.
• Format und Profil passen zum erwarteten Belegtyp, zum Beispiel XRechnung/UBL oder ZUGFeRD/CII.
• Der Befund nennt Validator-Version, Regelwerk und Validierungszeitpunkt.

Workspace blockiert strukturierte Rechnungen im Accounting-Archiv, wenn ein erforderlicher E-Rechnungsbefund fehlt oder ungültig ist. Korrigieren Sie dann den Beleg oder validieren Sie den strukturierten XML-Anteil erneut; ändern Sie nicht den archivierten Originalbeleg.

Restore-Protokoll als Evidence hinterlegen

Hinterlegen Sie das Restore-Protokoll als Evidence zum Compliance-Check accounting.backup_restore. Die Go-live-Console wertet diesen Nachweis als eigenen Check aus und verlinkt die Evidence-Datei.

Das Protokoll sollte mindestens enthalten:

• Zeitpunkt, Umgebung und verantwortliche Person des Restore-Tests.
• Datenbank-Backup, Storage-Backup und Log-/Audit-Backup mit Hash oder Artefaktreferenz.
• Wiederhergestellte Tenant-ID und geprüfter Zeitraum.
• Stichproben für Belege: StorageObject-ID, Dateiname, Hash, Größe, Retention, Scanstatus und E-Rechnungsbefund.
• Stichproben für Exporte: DATEV-, GoBD- und Steuer-Handoff-Artefakte mit Payload-Hash und Downloadprüfung.
• Ergebnis der technischen Nachprüfung: Belege lesbar, Hashes unverändert, Validierungsbefunde vorhanden, Audit-Events vorhanden.

Erkennen Sie Erfolg daran, dass die Go-live-Console den Backup-/Restore-Check als passed zeigt und die Evidence-Datei direkt aus dem Readiness-Bereich erreichbar ist.

Worker und Monitoring

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

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.

Schließen Sie eine Periode über die servicegebundene Aktion POST /accounting/periods/{id}/close. Die Aktion benötigt den Scope accounting_periods:close, erwartet eine weich gesperrte Periode, blockiert Entwurfsbuchungen und prüft Ledger- sowie Drift-Befunde. Bei Erfolg setzt sie hard_locked, aktualisiert den Workflow-Snapshot und schreibt ein Audit-Event. Direkte Statusänderungen auf hard_locked sind nicht der zulässige Abschlussweg.

Öffnen Sie eine hart gesperrte Periode kontrolliert über POST /accounting/periods/{id}/reopen. Die Aktion benötigt den Scope accounting_periods:reopen, erwartet hard_locked und setzt die Periode nur auf soft_locked zurück. Bei bereits geschlossenem Geschäftsjahr ist Reopen gesperrt. Workspace verändert dabei keine gebuchten Journalbuchungen und schreibt einen Audit- sowie Workflow-Nachweis.

Schließen Sie ein Geschäftsjahr über POST /accounting/fiscal-years/{id}/close. Die Aktion benötigt den Scope accounting_fiscal_years:close, erwartet den Status closing, verlangt mindestens eine Periode und blockiert, solange nicht alle Perioden hart gesperrt sind. Entwurfsbuchungen und blockierende Drift-Befunde verhindern den Abschluss. Bei Erfolg setzt Workspace das Geschäftsjahr auf closed und schreibt ein Audit-Event.

Erstellen Sie notwendige Abschlussbuchungen vor dem Perioden-Hard-Lock über POST /accounting/fiscal-years/{id}/closing-entry. Die Aktion benötigt den Scope accounting_fiscal_years:closing_entry, erwartet ein Geschäftsjahr im Status closing, bucht ausschließlich in die letzte offene Periode dieses Geschäftsjahrs und erzeugt genau eine Abschlussbuchung je Geschäftsjahr. Übergeben Sie entweder explizite Buchungszeilen oder ein resultAllocation- Objekt. resultAllocation kann entweder ein gepflegtes Ergebnisverwendungsprofil über profileId referenzieren oder GuV- Abschlusskonto und Ergebnisvortragskonto explizit angeben. Workspace berechnet dann die GuV-Salden aus geposteten Journalzeilen des Geschäftsjahrs, gleicht Erlös- und Aufwandskonten aus und überträgt den Saldo auf das angegebene Ergebnisvortragskonto. Workspace macht im MVP keine landesspezifischen Kontenvorschläge.

Erstellen Sie die Eröffnungsbilanz des Folgejahrs über POST /accounting/fiscal-years/{id}/opening-balance. Die Aktion benötigt den Scope accounting_fiscal_years:opening_balance, bucht ausschließlich in die erste offene Periode des Zielgeschäftsjahrs und erzeugt genau eine Eröffnungsbilanz je Geschäftsjahr. Optional kann sie auf ein bereits geschlossenes Quellgeschäftsjahr verweisen. Workspace erzeugt keine automatische Abschlusskette und öffnet Perioden nicht automatisch wieder.

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. Österreich ist aktuell als posting_template-Profil für Konten-/Rollen-Mapping sichtbar. Ein österreichischer Steuerreport oder GoBD-ähnlicher Audit-Export ist dadurch nicht freigeschaltet und bleibt bis zu einem eigenen Profil fail-closed.

DATEV- und GoBD-Exportantworten enthalten artifactDownloadUrl, wenn das Artefakt als StorageObject im Tenant, im Kontext accounting_export und mit der Context-ID des Exportlaufs vorliegt. Freigegebene Steuerreport-Läufe enthalten handoffDownloadUrl für das UStVA-Handoff-Artefakt, wenn dieselbe Storage-Bindung gültig ist. Der Download läuft über den bestehenden Storage-Endpunkt und verwendet dessen Berechtigungs- und Audit-Prüfungen. Die Operator-Listen zeigen dann eine kompakte Aktion Download. Fehlt die geprüfte Storage-Bindung, bleibt die Aktion leer statt einen unsicheren oder falschen Link anzubieten.

DATEV- und GoBD-Exportläufe haben eine eigene Freigabeaktion: POST /accounting/datev-exports/{id}/approve und POST /accounting/gobd-exports/{id}/approve. Die Aktionen benötigen eigene Scopes, akzeptieren nur Läufe im Status created, prüfen das tenantgebundene Storage-Artefakt samt Payload-Hash und setzen den Lauf danach auf approved. Bei fehlendem Artefakt, falschem Storage-Kontext oder Hash-Drift bleibt der Status unverändert. Erfolgreiche Freigaben aktualisieren die Workflow-Instanz und schreiben ein Audit-Event mit Actor, Artefaktreferenz und Hashdaten.

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.

Für deutsche UStVA-Reports erzeugt die Freigabe zusätzlich ein JSON-Handoff im Accounting-Export-Store. Dieses Artefakt enthält Manifest, Felder, Drilldown- Zeilen, Snapshot-Hash und den expliziten Status ericSubmissionStatus: not_configured. Workspace übermittelt diese Daten derzeit nicht elektronisch an ELSTER/ERiC; die Übergabe an Steuerberatung oder ein externes Meldeverfahren bleibt ein betrieblicher Schritt.

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

1. Zeitraum und Geschäftsjahr stimmen.
2. Journalbuchungen sind vollständig und balanciert.
3. Beleg- und Datei-Referenzen sind vorhanden.
4. Exportlauf ist erfolgreich abgeschlossen und freigegeben.
5. Payload-Hash und Artefakt-Metadaten sind gespeichert.
6. Der Exportlauf ist archiviert und später reproduzierbar.
7. Bei UStVA ist das Handoff-Artefakt vorhanden und der ERiC-Status bewusst als nicht konfiguriert dokumentiert.

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.