Mandatsakte, Fristenkalender, DMS

Jede Automatisierung in einer Kanzlei endet früher oder später an einem von drei Systemen: der Mandatsakte, dem Fristenkalender oder dem Dokumentenmanagement. Alles davor — Postfach abfragen, Dokument lesen, Zuordnung vorschlagen — ist der leichte Teil. Der Moment, in dem etwas in eines dieser drei Systeme hineingeschrieben wird, ist der, an dem Vorhaben scheitern oder Schaden anrichten.

Dieser Artikel sortiert die drei nach ihrem Charakter, benennt für jedes die Regel, die wir für nicht verhandelbar halten, und zeigt an einem laufenden Beispiel den Fehler, der beim Schreiben in ein DMS am häufigsten passiert — und den man erst bemerkt, wenn die Akte schon unbrauchbar ist.

Danach weißt du:

• worin sich Ablagesystem, Vorgangssystem und Kontrollsystem unterscheiden und warum das die Schreibregel bestimmt
• welche drei Wege in ein DMS führen und welcher davon den Wartungsvertrag verletzt
• warum ein Ablauf, der nicht zweimal laufen darf, nicht fertig ist, und wie ein Register über den Inhalt das löst
• wie man eine Akte findet, in der dasselbe Dokument schon dreimal liegt

Die drei sind nicht dasselbe

Das Dokumentenmanagement ist ein Ablagesystem. Es bewahrt auf, ordnet zu, macht auffindbar. Ein falsch abgelegtes Dokument ist ärgerlich und korrigierbar — solange jemand merkt, dass es falsch liegt. Von den drei Systemen ist es das zugänglichste und der natürliche erste Berührungspunkt.

Die Mandatsakte ist ein Vorgangssystem. Sie hält fest, was in einer Sache geschehen ist, und in vielen Kanzleien ist sie zugleich die Grundlage der Abrechnung. Wer hier hineinschreibt, verändert nicht eine Ablage, sondern einen Vorgang — und je nach Ausgestaltung eine Abrechnungsgrundlage.

Der Fristenkalender ist etwas grundsätzlich anderes, und das ist der wichtigste Satz in diesem Artikel. Er ist kein Kalender mit anwaltlichem Inhalt, sondern ein Kontrollsystem, an das die Rechtsprechung im Zusammenhang mit der Wiedereinsetzung sehr konkrete organisatorische Anforderungen stellt — Vorfristen, Ausgangskontrolle, die Behandlung von Einzelanweisungen, die Frage, wer eintragen und wer streichen darf. Diese Anforderungen sind über Jahrzehnte in Einzelfallentscheidungen entstanden und sie sind streng.

Die Regel für den Fristenkalender

Sie lautet: schreibend nie. Nicht als Vorsichtsmaßnahme für den Anfang, sondern als Bauentscheidung.

Der Grund ist nicht, dass eine Maschine schlechter rechnen würde als ein Mensch — im Gegenteil, das Zurückrechnen von Fristen ist etwas, das sie zuverlässig kann. Der Grund ist, dass das Kontrollsystem seinen Zweck aus der menschlichen Kontrolle bezieht. Eine automatische Eintragung, die niemand geprüft hat, sieht im Kalender genauso aus wie eine geprüfte. Genau diese Ununterscheidbarkeit ist das Problem: Sie entwertet die Kontrolle für alle Einträge, nicht nur für die automatischen.

Was stattdessen geht: eine Vorschlagsliste außerhalb des Kalenders. Ein Mensch sieht sie an, entscheidet, trägt ein. Die Maschine liefert den Vorschlag samt Fundstelle und Rechenweg, sie spart das Suchen und das Rückwärtsrechnen — und der Eintrag bleibt der Akt einer Person, die dafür einsteht. Wie so eine Vorschlagsliste aussieht, steht bei uns im Artikel über Fristen aus einem Vertragsstapel.

Lesend aus dem Fristenkalender ist dagegen unproblematisch und oft sehr nützlich: abgleichen, ob zu jedem erkannten Termin ein Eintrag existiert, und melden, wo keiner ist. Das stärkt die Kontrolle, statt sie zu verdünnen.

Drei Wege in ein DMS

Wenn es eine dokumentierte Programmierschnittstelle gibt, nehmt sie. Sie kennt die Regeln des Systems — Pflichtfelder, Berechtigungen, Versionierung — und setzt sie durch. Das ist kein Komfort, sondern der Grund, sie zu nehmen: Was die Schnittstelle ablehnt, hättet ihr auf jedem anderen Weg kaputtgeschrieben.

Gibt es keine, ist ein überwachter Ordner der zweitbeste Weg. Euer Ablauf legt dort Dateien mit einem verabredeten Namensschema ab, das DMS holt sie ab. Das ist unspektakulär, robust und in mehr Häusern im Einsatz, als die Hersteller zugeben. Die Schwäche: Ihr bekommt keine Rückmeldung, ob die Übernahme geklappt hat — das müsst ihr separat prüfen. Wie das Namensschema aussieht, beschreibt der Beitrag zur Ordnerstruktur.

Der dritte Weg ist der direkte Zugriff auf die Datenbank des Systems. Er ist verlockend, weil er immer funktioniert und nie dokumentiert werden muss. Tut es nicht. Ihr umgeht damit sämtliche Prüfungen des Systems, ihr verliert bei jedem Update den Anschluss, und ihr habt in aller Regel den Wartungsvertrag verletzt. Lesend mit Bedacht — schreibend nie.

Die Zuordnung vor dem Schreiben

Bevor ein Ablauf irgendwo hineinschreibt, muss für jeden Dokumenttyp feststehen, in welches der drei Systeme er gehört und welche Angaben dafür vollständig sein müssen. Das steht bei uns in einer Datei, nicht im Code: Dokumenttyp, Zielsystem, Pflichtfelder, und als Nebenwirkung höchstens ein Fristvorschlag. Der Fristenkalender ist darin als Zielsystem gesperrt. Ein Prüfskript hält Eingangsdokumente dagegen, hier sechs aus dem Paket:

  ?         mail_wagner.txt              Pflichtfeld fehlt: aktenzeichen
  ?         notiz_telefonat.txt          Typ 'telefonnotiz' steht nicht im Regelwerk
  dms       rechnung_4711.txt            rechnung -> Dokumentenmanagement
  dms       rechnung_4712.txt            rechnung -> Dokumentenmanagement
  ?         scan_unbekannt.txt           keine Angaben zum Dokument (fehlende .json)
  akte      verfuegung_4_O_221-26.txt    gerichtspost -> Mandatsakte; Frist 2026-10-02 -> Vorschlagsliste, kein Eintrag

  2 dms, 1 akte, 3 pruefen  (nichts geschrieben)

Drei von sechs bleiben liegen: eine Mandantenmail ohne Aktenzeichen, eine Telefonnotiz, für die es keine Regel gibt, ein Scan ohne Begleitdaten. Das ist kein schlechtes Ergebnis, sondern die Stelle, an der jemand entscheidet, statt dass ein Ablauf rät. Und die Verfügung mit der Frist zum 2. Oktober geht in die Akte; die Frist selbst steht in der Zeile als Vorschlag, und nichts sonst.

Der Fehler, der die Akte unbrauchbar macht

Hier ein Ablauf, der Eingangsdokumente ablegt. Er ist sorgfältig gebaut: Wenn der Dateiname schon existiert, nummeriert er durch, damit nichts überschrieben wird und nichts verloren geht. Das klingt nach der vorsichtigen Variante.

--- Lauf 1 ---
abgelegt: dms/mandant_kessler/rechnung_4711.txt
abgelegt: dms/mandant_kessler/rechnung_4712.txt
--- Lauf 2 (Wiederholung nach Abbruch) ---
abgelegt: dms/mandant_kessler/rechnung_4711_1.txt
abgelegt: dms/mandant_kessler/rechnung_4712_1.txt
--- Lauf 3 ---
abgelegt: dms/mandant_kessler/rechnung_4711_2.txt
abgelegt: dms/mandant_kessler/rechnung_4712_2.txt

Akte dms/mandant_kessler: 6 Dateien, 2 verschiedene Inhalte
  MEHRFACH   gleicher Inhalt 3-mal: rechnung_4711.txt, rechnung_4711_1.txt, rechnung_4711_2.txt
  MEHRFACH   gleicher Inhalt 3-mal: rechnung_4712.txt, rechnung_4712_1.txt, rechnung_4712_2.txt
  2 Dokumente gehoeren in diese Akte, 6 liegen darin. Nichts verändert; die Bereinigung ist Handarbeit.

So sieht dasselbe mit einem Register über die Inhalte aus; der dritte Lauf bekommt die korrigierte Fassung von Rechnung 4711 unter demselben Dateinamen:

--- Lauf 1 ---
neu abgelegt     dms/mandant_kessler/rechnung_4711.txt
neu abgelegt     dms/mandant_kessler/rechnung_4712.txt
2 neu, 0 uebersprungen, 0 Konflikte

--- Lauf 2 (Wiederholung) ---
schon vorhanden  dms/mandant_kessler/rechnung_4711.txt
schon vorhanden  dms/mandant_kessler/rechnung_4712.txt
0 neu, 2 uebersprungen, 0 Konflikte

--- Lauf 3: gleicher Name, anderer Inhalt ---
KONFLIKT         dms/mandant_kessler/rechnung_4711.txt -- gleicher Name, anderer Inhalt
0 neu, 0 uebersprungen, 1 Konflikte

def lege_ab(pfad, mandant, register, dms, anwenden):
    fp = fingerabdruck(pfad)              # sha256 ueber den Inhalt
    if fp in register:
        return None, register[fp]["ziel"]  # schon da, nichts tun
    ziel = os.path.join(dms, "mandant_" + mandant, os.path.basename(pfad))
    if os.path.exists(ziel):
        # gleicher Name, anderer Inhalt -- das ist ein echter Konflikt
        # und keine Wiederholung. Nicht ueberschreiben, melden.
        return "KONFLIKT", ziel
    if anwenden:
        os.makedirs(os.path.dirname(ziel), exist_ok=True)
        shutil.copy(pfad, ziel)
        register[fp] = {"quelle": pfad, "ziel": ziel}
    return "NEU", ziel

Ohne den Schalter anwenden sagt die Funktion nur, was sie tun würde; das ist der Trockenlauf, mit dem jeder Lauf beginnt. Ein Detail noch, das nichts kostet und viel rettet: Das Register wird erst daneben geschrieben und dann umbenannt. Ein Abbruch mitten im Schreiben hinterlässt sonst ein halbes Register — und ein halbes Register ist schlimmer als keins, weil der nächste Lauf dann einen Teil der Dokumente für neu hält.

Die Akte, die schon kaputt ist

Wer den ersten Fehler schon ein Jahr lang gemacht hat, braucht vor allem eine Antwort auf die Frage, in welchen Akten er steckt. Die Prüfung dafür ist dieselbe wie im Register: Prüfsumme über den Inhalt, dann zählen. Der Befund oben („6 Dateien, 2 verschiedene Inhalte“) stammt von diesem Prüfschritt, und er verändert nichts. Zwei Zeilen unterscheidet er: MEHRFACH heißt, derselbe Inhalt liegt unter mehreren Namen, und das kann ein Skript aufräumen. KONFLIKT heißt, unter einem Namen liegen verschiedene Fassungen, und welche gilt, muss ein Mensch entscheiden. Wenn man diese Prüfung einmal über alle Akten laufen lässt, weiß man, wie groß der Schaden ist, bevor man ihn anfasst.

Die Regel, die alles davon zusammenfasst

Schreibend an genau einer Stelle. Ein Ablauf, der in das DMS schreibt, schreibt nicht auch in die Akte und nicht auch in den Kalender. Der Grund ist nicht Ordnungsliebe, sondern die Frage, was bei einem Abbruch mittendrin passiert: Wenn drei Systeme beteiligt sind, gibt es einen Zustand, in dem eines geschrieben hat und zwei nicht — und den wieder geradezurücken, ist erheblich schwieriger, als den Ablauf dreimal zu bauen.

Praktisch heißt das: Ablegen ist ein Ablauf. Vermerk in der Akte ist ein zweiter. Fristvorschlag ist ein dritter, und der schreibt ohnehin nicht. Jeder mit eigenem Protokoll, jeder für sich wiederholbar. Das Prüfskript im Paket legt deshalb nur die DMS-Dokumente ab und lässt die Verfügung liegen, obwohl es weiß, wohin sie gehört.

Und DATEV

In vielen Kanzleien und den meisten Steuerkanzleien führt kein Weg daran vorbei. Der Zugang ist niedriger, als sein Ruf vermuten lässt: Anmeldung am Developer Portal, Organisation anlegen, App anlegen, API-Produkt abonnieren — damit ist die Sandbox freigeschaltet. Eine vorhandene Beraternummer ist dafür keine Voraussetzung, und eine Partnerschaft auch nicht. Für Belege ist accounting:documents die einschlägige Schnittstelle.

Was den Aufbau bestimmt, ist nicht der Zugang, sondern die Anmeldung: Authorization Code Flow mit PKCE, ein Access Token für 15 Minuten, ein Refresh Token für höchstens 11 Stunden. Ein nächtlicher Lauf ohne anwesenden Menschen geht damit nur über einen langlebigen Token, der an genau einen Mandanten gebunden ist. Das und die Fehler beim Bauen stehen ausführlich im Artikel über die Belegübergabe an DATEV.

Wo wir anfangen würden

• Lesen vor Schreiben. Ein Ablauf, der nur liest und eine Liste erzeugt, bringt oft schon den halben Nutzen und kann nichts kaputtmachen. Fangt dort an, auch wenn es sich nach dem kleineren Schritt anfühlt.
• Ablage vor Vorgang. Das DMS verzeiht mehr als die Mandatsakte, und ein falsch abgelegtes Dokument lässt sich verschieben.
• Der Fristenkalender kommt nicht dran. Er bekommt Vorschläge, keine Einträge.
• Vor dem ersten Schreiben: Was passiert, wenn dieser Lauf zweimal läuft? Wenn darauf keine Antwort kommt, die nicht „dann steht es doppelt drin“ lautet, ist der Ablauf nicht fertig.

Zum Nachbauen

Das Paket zu diesem Beitrag enthält das Regelwerk, die Zuordnung, das Prüfskript und die Testdaten, mit denen alle drei Ausgaben oben entstanden sind. Entpacken, dann die Befehle aus der README in dieser Reihenfolge laufen lassen:

• regelwerk.md: die fünf Regeln für die drei Systeme und die Reihenfolge beim Einführen
• zuordnung.json: Dokumenttyp, Zielsystem, Pflichtfelder, Nebenwirkung; der Fristenkalender ist als Zielsystem gesperrt
• pruefe_zuordnung.py: plan prüft die Zuordnung und schreibt nichts; ablegen legt mit Register ab, Standard Trockenlauf, mit --naiv als Vorführung der ersten Fassung; akte meldet Mehrfachablagen und Konflikte
• testdaten/eingang/: sechs Dokumente mit Begleitdaten, darunter zwei Rechnungen, eine Verfügung mit Frist und drei Fälle für die Prüfliste
• testdaten/eingang_korrektur/: die korrigierte Rechnung 4711, gleicher Name, anderer Inhalt

Stand dieses Artikels

Das gezeigte DMS ist ein Ordner mit einem Register, kein echtes Dokumentenmanagementsystem. Alle drei Ausgaben sind echt und stammen vom 18. September 2026 aus dem Prüfskript im Paket mit Python 3.12.2, nur Standardbibliothek; die doppelten Ablagen aus dem ersten Beispiel sind tatsächlich entstanden. Ein echtes System verhält sich in diesem Punkt nicht grundsätzlich anders: Es nimmt an, was man ihm schickt. Gegen eine Kanzleisoftware oder ein DMS mit Schnittstelle ist nichts davon geprüft; die Stelle, an der man sie anschließt, ist die Funktion lege_ab.

Zu DATEV haben wir den Zugangsweg und die Schnittstellen aus dem Developer Portal ausgewertet und einen Client gegen eine Attrappe gebaut, die die dokumentierten Regeln durchsetzt — einen eigenen Entwicklerzugang haben wir nicht, und es steht in keinem unserer Artikel ein Aufruf gegen einen DATEV-Server. Was wir belegen können und was nicht, steht dort ausdrücklich dabei.

Häufige Fragen