Kanzleien · Wie Practice-Management- und Document-Management-Systeme tatsächlich zusammenhängen

Ein neuer Mandant ruft an einem Montagmorgen bei einer mittelgroßen Kanzlei an. Bis Dienstag hat ein Partner ein Mandat angelegt, eine Paralegal einen Ordner erstellt, und ein Associate verschickt bereits den Entwurf eines NDA per E-Mail. Drei Systeme sind gerade nacheinander angesprungen: Practice Management, Document Management und E-Mail. Wenn die im ersten System erzeugte Mandatsnummer nicht mit dem übereinstimmt, was im zweiten auftaucht, hat die Kanzlei ein Ablageproblem, das achtzehn Monate später bei einem Haftpflicht-Audit oder einem Abrechnungsstreit mit dem Mandanten sichtbar wird. Diese Lektion zeigt genau, wo diese Übergabe funktioniert und wo sie unbemerkt bricht.

Die Kernsysteme, definiert

Bevor wir dem Ablauf folgen, das Vokabular festlegen:

• PMS (Practice Management System): das System of Record für Mandate, Mandanten, Conflicts Checks und oft auch die Abrechnung. Beispiele: Elite 3E, Aderant, Clio (kleinere Kanzleien), Intapp.
• DMS (Document Management System): dort liegen Dokumente und E-Mails tatsächlich, versioniert und indexiert. Beispiele: iManage, NetDocuments, OpenText.
• Mandatsnummer: die eindeutige Kennung für ein Stück Mandantenarbeit, meist strukturiert als Mandantencode plus Mandatscode (z. B. 10234-0007).
• ACL (Access Control List): die Berechtigungsstruktur, die festlegt, wer eine Datei oder einen Ordner sehen darf. In Kanzleien werden darüber Ethical Walls (Informationsbarrieren, die erforderlich sind, wenn ein Anwalt einen Interessenkonflikt hat) technisch durchgesetzt.

Die Mandatseröffnung Schritt für Schritt

Schritt 1: Intake und Conflicts. Eine neue Mandatsanfrage geht ins PMS oder in ein eigenes Conflicts- und Intake-Modul (oft Teil von Intapp oder ein eigenständiges Tool wie Elites Conflicts Manager). Das löst einen Conflicts Check gegen die historische Mandanten- und Gegnerdatenbank der Kanzlei aus, ein Prozess, der von berufsrechtlichen Regeln wie der ABA Model Rule 1.7 zu Interessenkonflikten bestimmt wird.

Schritt 2: Vergabe der Mandatsnummer. Nach Freigabe erzeugt das PMS die Mandatsnummer. Diese Nummer ist das Rückgrat des gesamten Tech-Stacks: Abrechnungscodes, Zeiterfassungseinträge und Dokumentenordner hängen alle an ihr.

Schritt 3: Anlegen des DMS-Ordners. Hier liegt die erste echte Weggabelung. In einem gut integrierten Stack hört das DMS über eine APIAPIApplication Programming Interface: eine standardisierte Schnittstelle, über die Anwendungen kommunizieren und Daten austauschen, ohne die interne Funktionsweise der jeweils anderen zu kennen.Vollständige Definition ansehen → oder einen Middleware-Connector auf Neu-Mandat-Events aus dem PMS (gängige Anbieter: BigHand, Litera oder Eigenentwicklungen auf Basis der REST-API von iManage) und legt automatisch einen passenden Workspace an, mit der identischen Mandatsnummer als Ordner-ID.

In einem schlecht integrierten Stack legt eine Paralegal den DMS-Ordner manuell an und tippt die Mandatsnummer von Hand ein. Tippfehler passieren. Ein Ordner wird als 10234-007 statt 10234-0007 angelegt. Suche, Abrechnungsabgleich und E-Discovery-Sammlung für dieses Mandat übersehen ab jetzt stillschweigend die Dokumente im falsch getippten Ordner.

Schritt 4: Zugriffsrechte werden vererbt (oder nicht). Das PMS weiß, wer auf dem Mandat eingesetzt ist und ob eine Ethical Wall gilt. Bei echter Integration wird diese Staffing-Liste ins DMS gepusht und setzt die Ordner-ACL automatisch. Wenn nicht, muss jemand die Berechtigungsliste von Hand in einem zweiten System nachbauen, und „von Hand“ ist genau die Stelle, an der Informationsbarrieren versagen.

Wo Drift tatsächlich entsteht

Drei Fehlermuster tauchen in realen Kanzleiumgebungen immer wieder auf:

1. Zeitversatz. Das PMS-Mandat wird montags ererDas Verhältnis von Interaktionen (Likes, Kommentare, Shares) zur Reichweite eines Inhalts. Zeigt, wie stark die Zielgruppe reagiert, gemessen an der Zahl der Personen, die den Inhalt gesehen haben.Vollständige Definition ansehen →öffnet; der DMS-Integrationsjob läuft nachts im Batch und synchronisiert erst dienstags. Wer am Montagnachmittag ein Dokument entwirft, speichert es in einem generischen „unfiled“-Ordner, der danach nie abgeglichen wird.
2. Umbenennungen und Übertragungen. Ein Mandat bekommt nach einem Wechsel der abrechnenden Mandantengesellschaft eine neue Nummer oder wird in ein anderes Büro übertragen. Das PMS aktualisiert die Nummer. DMS-Ordner, besonders ältere, behalten oft die alte ID, weil das Umbenennen eines Ordners mit Tausenden verschachtelten Dokumenten und erhaltenen Versionshistorien operativ riskant ist, weshalb IT-Teams häufig darauf verzichten.
3. Permission Creep. Ein Anwalt scheidet aus einem Mandat aus. Der Staffing-Eintrag im PMS wird sofort aktualisiert (es ist nur eine Datenbankzeile). Die DMS-Zugriffsliste wird oft nicht im gleichen Takt entzogen, weil das Entfernen von DMS-Zugriffen einen separaten Workflow erfordert, manchmal ein manuelles Ticket an die IT. Ergebnis: Ehemalige Teammitglieder behalten monatelang Dokumentenzugriff.

Warum das mehr ist als Ordnungsliebe

Hier geht es nicht um Ablagehygiene um ihrer selbst willen. Zugriffskontrolle auf Mandatsebene ist der Weg, über den Kanzleien Privilege (der rechtliche Schutz vor Offenlegung der Kommunikation zwischen Anwalt und Mandant) und Ethical Walls operativ umsetzen. Eine abgedriftete Berechtigung ist ein potenzieller Conflicts-Verstoß, und sie ist im Verfahren zugänglich: Die Gegenseite kann Zugriffsprotokolle per Subpoena anfordern, um zu zeigen, wer wann privilegiertes Material einsehen konnte.

Es bricht auch die Abrechnung. Zeiteinträge im Zeiterfassungssystem (oft im PMS eingebaut oder als Add-on wie Intapp Time) werden mit der Mandatsnummer getaggt. Liegt ein Dokument unter einer abweichenden Ordner-ID, finden E-Discovery-Exporte oder nach Mandat durchgeführte Abrechnungs-Audits es schlicht nicht, und die Kanzlei kann Arbeitsergebnisse nicht abrechnen, die sie nicht lokalisieren kann.

Eine einfache technische Sicht auf die Synchronisation

Die meisten PMS-DMS-Integrationen laufen heute als event-getriebene Webhooks statt als nächtliche Batch-Jobs, wobei Batch in kleineren Kanzleien weiterhin existiert. Ein vereinfachter Event-Payload sieht so aus:

{
  "event": "matter.opened",
  "matter_number": "10234-0007",
  "client_id": "10234",
  "staffed_attorneys": ["j.smith", "a.chen"],
  "ethical_wall": false,
  "billing_type": "hourly"
}

Der DMS-Connector hört auf matter.opened, legt den Workspace mit matter_number als Ordnerschlüssel an und wendet eine aus staffed_attorneys gebaute ACL an. Ist ethical_wall gleich true, schließt er zusätzlich benannte Personen unabhängig vom Staffing aus. Die Integrität des Gesamtsystems hängt davon ab, dass dieser Payload zuverlässig ausgelöst wird und dass beide Systeme matter_number als unveränderlichen Primärschlüssel behandeln, was, wie oben erwähnt, in der Praxis bei Umnummerierungen häufig verletzt wird.

AML, Conflicts und Abrechnung: die Systeme rund um die beiden Kernsysteme

PMS und DMS arbeiten nicht allein. Zwei weitere Systeme hängen sich üblicherweise an dieselbe Mandatsnummer:

• AML- (Anti-Money Laundering) und KYC-Prüfungen (Know Your Customer): in vielen Jurisdiktionen vor dem Client Onboarding vorgeschrieben, insbesondere nach den Anti-Geldwäsche-Richtlinien der EU und in den USA nach den Vorgaben der State Bars sowie Pflichten aus dem Bank Secrecy Act für bestimmte transaktionsbezogene Arbeit. Diese Prüfungen laufen typischerweise im Intake-Modul, bevor die Mandatsnummer überhaupt vergeben wird.
• Abrechnungssysteme, mal dasselbe PMS-Modul, mal separat (z. B. die Billing Engine von Aderant), ziehen Zeiteinträge und Auslagen nach Mandatsnummer, um Rechnungen zu erzeugen, oft formatiert nach E-Billing-Standards wie LEDES (Legal Electronic Data Exchange Standard) für Unternehmensmandanten, die strukturierte Rechnungsdaten verlangen.

Jedes dieser Systeme setzt voraus, dass die Mandatsnummer stabil und eindeutig ist. Driftet sie zwischen PMS und DMS auseinander, wird der Abgleich über alle vier Systeme (Intake, DMS, Zeit, Abrechnung) zu einer manuellen, fehleranfälligen Übung, die meist erst auffällt, wenn ein Mandanten-Auditor oder das Due-Diligence-Team eines Lateral Partners nachschaut.

Wo ein Data WarehouseData WarehouseEin zentrales Repository, das Daten aus vielen Quellsystemen in einem strukturierten, abfrageoptimierten Speicher zusammenführt, ausgelegt für Analytics, Reporting und Business Intelligence.Vollständige Definition ansehen → hineinpasst, ohne Privilege zu brechen

Moderne Kanzleien ziehen zunehmend PMS-Daten, DMS-Metadaten (nicht den vollständigen Dokumenteninhalt) und Abrechnungsdaten in ein zentrales Warehouse oder LakehouseLakehouseEine hybride Architektur, die die Flexibilität eines Data Lake mit den analytischen Fähigkeiten eines Data Warehouse auf einer einzigen Storage-Schicht verbindet.Vollständige Definition ansehen → für Analytics, Profitabilitätsreporting und Pricing-Entscheidungen. Die entscheidende Designvorgabe: Dokumenten*inhalte* wandern wegen des Privilege-Risikos selten in die Warehouse-Schicht; üblicherweise nur strukturierte Metadaten (Mandatsnummer, Stunden, Practice Group, Realization Rate). Row-Level Security im Warehouse muss die Ethical-Wall-Logik des Quell-PMS trotzdem abbilden, sonst wird die Analytics-Schicht zum schwachen Glied, das durchsickern lässt, wer woran arbeitet.

Key Takeaways

• Die Mandatsnummer ist die eine Kennung, die über PMS, DMS, Zeit und Abrechnung hinweg synchron bleiben muss; behandeln Sie jede Umnummerierung als Hochrisiko-Operation, die manuelle Verifizierung erfordert.
• Eine Echtzeit-Integration über API oder Webhook zwischen PMS und DMS (statt nächtlichem Batch oder manuellem Ordneranlegen) verhindert, dass Mandatsnummern und Ordnerstrukturen auseinanderdriften.
• Im PMS gesetzte Zugriffsrechte und Ethical Walls müssen im selben Takt wie Staffing-Änderungen in die DMS-ACLs propagieren; verzögerter Entzug ist ein echtes Conflicts- und Privilege-Risiko, nicht bloß eine Frage der IT-Hygiene.
• AML/KYC- und Conflicts-Prüfungen laufen der Vergabe der Mandatsnummer vor und steuern den gesamten nachgelagerten Ablauf; die nachgelagerten Abrechnungssysteme hängen davon ab, dass dieselbe Nummer intakt bleibt.
• Warehouse- und Lakehouse-Schichten auf diesem Stack sollten ausschließlich strukturierte Metadaten führen, mit Row-Level Security, die die Ethical Walls der Quellsysteme repliziert, sodass privilegierte Dokumenteninhalte vollständig außerhalb der Analytics-Schicht bleiben.