Rollen & Berechtigungen

KanzleiSynchron hat zwei getrennte Rollen-Ebenen, und jeder Nutzer hat genau eine Rolle. Rollen auf der App-Ebene werden beim Einladen unter Einstellungen → Team (/settings/team) vergeben. Diese Seite erklärt, was jede Rolle darf — und was nicht.

Zwei Rollen-Ebenen — eine Rolle pro Nutzer

Ebene	Wo sie gilt	Rollen
Kunde / Mandant	die App (Importe, Einstellungen, Team, Perioden, Ausnahmen)	owner, merchant_admin (= Admin), accountant (= Mitglied), reviewer, viewer, pending
Ops	nur die mandantenübergreifende /ops-Konsole	super_admin, support, compliance_officer, read_only

Ein Nutzer hat genau eine Rolle auf genau einer Ebene. Um auf beiden Ebenen zu arbeiten, brauchen Sie zwei getrennte Konten.

super_admin ≠ merchant_admin

super_admin ist nur die /ops-Konsole — diese Rolle hat keine Upload- oder App-Fähigkeit. merchant_admin ist die App (Importe, Einstellungen, Team, Perioden, Ausnahmen). Sie sind nicht austauschbar; die eine zu vergeben gewährt nicht die andere.

Die App-Rollen (Mandanten-Ebene)

Die Rollen, die Sie unter Einstellungen → Team vergeben:

Rolle (Schlüssel)	Anzeigename	Wer das ist
merchant_admin	Kanzlei-Admin	Verantwortliche, die den Mandanten einrichten, das Team verwalten und die Einstellungen pflegen. Kanzlei-Admin / Eigentümer eines Mandanten.
reviewer	Sachbearbeiter	Mitarbeitende der Kanzlei, die die tägliche Arbeit machen: importieren, abstimmen, Ausnahmen klären.
viewer	Betrachter	Nur-Lese-Zugriff.
pending	Pending (wartet auf Freischaltung)	Ein frisch selbst registriertes Konto mit null Rechten, bis ein Admin es befördert (siehe Registrierung & Erststart).

Teammitglied statt „Nutzer“

Eine Person mit Zugang zu einem Mandanten heißt durchgängig Teammitglied. Der externe Steuerberater ist kein Teammitglied — er hat keinen KS-Login und empfängt nur das Übergabepaket.

Registrierung & Erststart (Pending-Konten)

KanzleiSynchron liefert keine Standard-Zugangsdaten aus. Nutzer registrieren sich selbst unter /sign-up.

• Bei einem frischen Deploy wird die erste Registrierung automatisch zu merchant_admin (Kanzlei-Admin) auf dem Standard-Mandanten befördert — so funktionieren Onboarding und App ohne jedes SQL sofort. Die erste Registrierung erhält nie automatisch super_admin.
• Jede spätere Registrierung startet als pending mit null Rechten. Ein Pending-Konto ist von allem außer /me und /auth ausgeschlossen und sieht einen 403: „Your account is awaiting activation by a tenant administrator.” Der Onboarding-Schritt Loslegen erfordert merchant_admin.

Einen Pending-Nutzer befördern

Zwei Wege, ein pending-Konto freizuschalten:

1. In der App — ein bestehender Admin öffnet Einstellungen → Team, findet die Person und setzt ihre Rolle (siehe Team verwalten).
2. Betreiber-Befehl (auf dem VPS):

   sudo ./ks-setup-helper.sh --grant-admin <email> [--grant-role merchant_admin|super_admin]

   Die Standardrolle ist merchant_admin (die App). Mit --grant-role super_admin wird stattdessen die /ops-Konsole gewährt. Mit --dry-run lässt sich die Änderung vorab anzeigen, ohne die Datenbank zu verändern.

Berechtigungsmatrix (App-Ebene)

Aufgabe	reviewer (Sachbearbeiter)	merchant_admin (Kanzlei-Admin)
Importe hochladen	✓	✓
Abstimmung & Ausnahmen klären	✓	✓
Berichte ansehen	✓	✓
Periode anlegen & abschließen	✓	✓
Übergabepaket erstellen & senden	✓	✓
Team verwalten (einladen, sperren, Rollen ändern)	—	✓
Mandanteneinstellungen ändern	—	✓
Steuerberater-Kanal konfigurieren	—	✓
Datenlöschung (DSGVO) auslösen	—	✓

Ein pending-Konto hat nichts davon, bis es befördert wird; ein viewer ist nur lesend.

Was der Sachbearbeiter nicht kann

Ein reviewer macht die gesamte tägliche Abschlussarbeit — aber er kann kein Team verwalten, keine Mandanteneinstellungen ändern und keine Datenlöschung auslösen. Diese Aufgaben sind dem merchant_admin vorbehalten.

Die /ops-Konsole (Ops-Ebene)

Die Ops-Ebene wird nur über die mandantenübergreifende /ops-Konsole erreicht und nie App-Nutzern zugewiesen. Keine dieser Rollen kann hochladen oder die App nutzen.

Rolle (Schlüssel)	Was es ist
super_admin	Vollständiger mandantenübergreifender Operator — nur die /ops-Konsole, keine App-Fähigkeit.
support	Mandantenübergreifend lesen plus Issue-Bearbeitung.
compliance_officer	Mandantenübergreifend lesen plus DPR-Akten und DSGVO-Löschung.
read_only	Mandantenübergreifend nur lesend.

(Die alte breite Rolle internal_ops bleibt nur aus Kompatibilitätsgründen erhalten.) Die technische Aufschlüsselung steht unter Rollen & Capabilities.

Warum zwei Personen für den Vier-Augen-Abschluss

Der Periodenabschluss läuft nach dem Vier-Augen-Prinzip. Der Abschluss-Assistent prüft drei Gates, bevor er eine Periode schließt:

1. Null offene Ausnahmen in der Periode.
2. ≥ 95 % Match-Abdeckung der Bewegungen.
3. Vier-Augen-Prinzip: Wer die Periode abschließt, darf sie nicht selbst angelegt haben (Ersteller ≠ Abschließender).

Das dritte Gate lässt sich nicht umgehen. Es ist unabhängig von der Rolle: Auch zwei reviewer erfüllen es, solange es zwei verschiedene Personen sind. Ein einzelnes Teammitglied — selbst ein merchant_admin — kann eine Periode, die es selbst angelegt hat, nicht abschließen.

Mindestens zwei aktive Teammitglieder

Hat ein Mandant nur eine Person mit Zugriff, lässt sich keine Periode abschließen — und damit kein DATEV-Export erzeugen. Laden Sie daher früh eine zweite Person ein. Details unter Team verwalten.

Verwandte Seiten

• Team verwalten — Teammitglieder einladen, sperren, Rollen ändern.
• Glossar — alle Begriffe und Rollenschlüssel im Überblick.
• GoBD & Periodenabschluss — der Abschluss-Assistent und seine Gates.