B. Strukturierte Daten im Austausch mit der Justiz

Wer in einer Kanzlei arbeitet, arbeitet den ganzen Tag mit Daten – auch wenn er es nicht so nennt. Der Name des Mandanten, das Aktenzeichen, das Datum der mündlichen Verhandlung, die Forderungshöhe, die Gegenseite, der zuständige Richter: All das sind Daten. Sie stecken in Schriftsätzen, in Ladungen, in Urteilen, in E-Mails, in Kalendereinträgen und in Handakten. Das war schon immer so. Was sich geändert hat, ist das Medium, in dem diese Daten übermittelt werden. Vom Brief zum Fax, vom Fax zur E-Mail, von der E-Mail zum beA. Geblieben ist eines: Die Daten selbst reisen meist als Fließtext – eingebettet in ein Dokument, das für das menschliche Auge gemacht ist.

Das ist kein Fehler. Schriftsätze sind Kommunikation, und Kommunikation braucht Sprache. Aber Sprache hat einen Preis: Sie muss gelesen, verstanden und manuell ausgewertet werden. Jede Information, die aus einem eingehenden Dokument in ein anderes System übertragen werden soll – in den Kalender, ins Fristenkontrollsystem, in die Kanzleisoftware – erfordert einen menschlichen Zwischenschritt. Und jeder menschliche Zwischenschritt ist eine potenzielle Fehlerquelle.

Dokumente wie Schriftsätze, Ladungen oder Urteile sind sogenannte unstrukturierte Daten. Das klingt nach einem technischen Begriff, beschreibt aber nichts anderes als das, womit Juristen täglich umgehen: Fließtext. Eine Ladung enthält das Verhandlungsdatum – aber es steht irgendwo im dritten Absatz, eingebettet in einen Satz wie „Der Termin zur mündlichen Verhandlung wird bestimmt auf Donnerstag, den …“. Eine Maschine kann diesen Satz lesen, aber sie versteht ihn nicht. Sie weiß nicht, dass „Donnerstag, den …“ ein Datum ist, das in einen Kalender gehört.

Das ist das Wesen unstrukturierter Daten: Die Information ist vorhanden, aber sie hat keine eindeutige, maschinenlesbare Form. Ob das Datum in Zeile drei oder Zeile zwölf steht, ob es als „15.10.2025“ oder als „der fünfzehnte Oktober zweitausendundfünfundzwanzig“ geschrieben wird – für den menschlichen Leser macht das keinen Unterschied. Für eine Maschine macht es jeden Unterschied.

Strukturierte Daten funktionieren nach einem anderen Prinzip. Statt Informationen in Fließtext zu verpacken, werden sie in einem definierten Format mit klar benannten Feldern und zugehörigen Werten abgelegt. Das Verhandlungsdatum steht nicht mehr im dritten Absatz eines Briefes – es steht in einem Feld namens „verhandlungsdatum“ mit dem Wert „2025–10–15“. Eine Maschine weiß sofort, was gemeint ist, und kann den Wert direkt weiterverarbeiten.

Die zwei in der Praxis verbreitetsten Formate für strukturierte Daten sind JSON und XML. Beide funktionieren nach demselben Grundgedanken: Jede Information bekommt einen eindeutigen Namen, eine sogenannte Bezeichnung oder ein „Feld“, und einen zugehörigen Wert. Die Ladung vom Amtsgericht Potsdam enthält in einem solchen Format nicht den Satz „Der Termin wird bestimmt auf Donnerstag, den 15.10.2025, 14:00 Uhr, Sitzungssaal 3“ – sie enthält die Felder „datum“, „uhrzeit“ und „saal“ mit den entsprechenden Werten. Der Unterschied ist nicht kosmetisch. Er ist der Unterschied zwischen einer Information, die gelesen werden muss, und einer Information, die direkt verarbeitet werden kann.

Was das konkret bedeutet, lässt sich an einem einfachen Beispiel zeigen. Eine Ladung des Amtsgerichts Potsdam enthält im PDF den Satz: „Der Termin zur Hauptverhandlung wird bestimmt auf Donnerstag, den 15.10.2025, 14:00 Uhr, Sitzungssaal 3.“ Dieselbe Information als strukturierter JSON-Datensatz sähe so aus: das Feld „datum“ mit dem Wert „2025–10–15“, das Feld „uhrzeit“ mit dem Wert „14:00“, das Feld „saal“ mit dem Wert „3“. Drei Felder, drei Werte – eindeutig, maschinenlesbar, direkt weiterverarbeitbar. Kein Satz, den jemand lesen muss. Kein Datum, das jemand abtippen muss. Kein Saal, der ins Falsche übertragen werden kann.

Für die Kanzleipraxis bedeutet das: Strukturierte Daten sind kein Erkenntniswerk­zeug – sie ersetzen nicht das juristische Urteil und nicht den Schriftsatz. Sie sind ein Automatisierungswerkzeug. Wer das versteht, versteht auch, warum der nächste Schritt im elektronischen Rechtsverkehr nicht eine bessere PDF-Lösung sein wird, sondern eine strukturiertere.

Die xjustiz_nachricht.xml ist Teil des bundesweit einheitlichen xJustiz-Standards – eines XML-Datenstandards, der den Austausch strukturierter Informationen zwischen Justiz, Anwaltschaft und Behörden regeln soll. Über diesen Standard werden heute bereits Metadaten wie Aktenzeichen, Rubrum und Gerichtskennzeichen maschinenlesbar übertragen. Kanzleisoftware, die diesen Standard unterstützt, kann eingehende Nachrichten automatisch dem richtigen Mandat zuordnen, ohne dass jemand das Aktenzeichen manuell abtippen muss.

Auch das elektronische Empfangsbekenntnis – das eEB – ist ein Beispiel für strukturierte Daten im Rechtsverkehr. Das Zustelldatum wird dabei nicht nur im Fließtext einer Benachrichtigung mitgeteilt, sondern als strukturierter Datenpunkt in der xjustiz_nachricht.xml hinterlegt. Dass dieser Datenpunkt für die Fristberechnung maßgeblich ist und nicht etwa das Speicherdatum einer Datei, hat der BGH in jüngerer Rechtsprechung ausdrücklich klargestellt (vgl. BGH, Beschl. v. 29.5.2024 – I ZB 84/23).

In der Praxis bedeutet das: Wer heute in seiner Kanzleisoftware eine eingehende beA-Nachricht öffnet und das Aktenzeichen automatisch vorausgefüllt sieht, profitiert bereits von xJustiz – ohne es zu wissen. Produkte wie RA-MICRO, DATEV Anwalt oder Advoware lesen die xjustiz_nachricht.xml aus und übernehmen Metadaten automatisch. Das ist kein Komfortfeature. Es ist der erste konkrete Schritt in Richtung eines vollständig strukturierten Rechtsverkehrs. Und er funktioniert bereits heute – zumindest für die Metadaten.

So weit, so gut – und doch bleibt der Austausch strukturierter Daten heute auf wenige Metadaten beschränkt. Was in der xjustiz_nachricht.xml steht, sind Angaben über das Dokument – nicht der Inhalt des Dokuments selbst. Der eigentliche Inhalt: die Anträge, der Tenor, die Fristen, die Kostenentscheidung – all das steckt nach wie vor im angehängten PDF. Die Infrastruktur ist vorhanden. Der Inhalt fehlt noch.

Die Konsequenz für den Kanzleialltag ist ernüchternd. Trotz beA, trotz elektronischer Akte, trotz xJustiz-Standard tippt die Mitarbeiterin das Verhandlungsdatum manuell ab. Nicht weil die Technik es nicht besser könnte – sondern weil der Inhalt noch nicht im richtigen Format übermittelt wird. Der Kanal ist digital. Die Daten sind es noch nicht.

xJustiz ist kein neues Phänomen. Der Standard existiert seit Jahren und wird von Bund und Ländern gemeinsam gepflegt und weiterentwickelt. Er definiert, welche Datenfelder in welchem Format zwischen den verschiedenen Akteuren im Rechtsverkehr ausgetauscht werden – von der Kanzlei über das Gericht bis hin zu Behörden und Gerichtsvollziehern. Wer das beA nutzt, arbeitet bereits mit xJustiz, ohne es zu merken: Die xjustiz_nachricht.xml in jeder gesendeten Nachricht ist ein xJustiz-Dokument.

Der Standard deckt heute vor allem den Bereich der Verfahrensmetadaten ab – also Informationen darüber, wer mit wem worüber kommuniziert. Was er noch nicht leistet, ist die vollständige strukturierte Abbildung von Verfahrensinhalten: Anträge, Entscheidungstenor, Fristen, Kostenentscheidungen. Genau hier liegt das Potenzial der nächsten Entwicklungsstufe. Die Arbeiten daran laufen – sowohl auf Ebene der Justizministerkonferenz als auch im Rahmen der Reformkommission „Zivilprozess der Zukunft“, die eine deutlich stärkere Nutzung digitaler Werkzeuge im Zivilprozess empfiehlt (vgl. Biallaß, Elektronischer Rechtsverkehr Ausgabe 3/2025, Rn 9 ff.).

Nirgendwo wird das Potenzial strukturierter Daten greifbarer als bei der Einreichung einer Klage. Eine Klageschrift enthält eine Vielzahl von Informationen, die auf beiden Seiten – in der Kanzlei des Klägers, beim Gericht und in der Kanzlei des Beklagten – manuell erfasst und weiterverarbeitet werden müssen: die Parteien, ihre Rollen, die Prozessbevollmächtigten, das angerufene Gericht, die Klageart, der Streitwert, die einzelnen Anträge. All das sind strukturierbare Informationen. Sie könnten als definierte Felder übermittelt werden, statt als Fließtext in einem PDF.

Das Gericht könnte eingehende Klagen automatisch dem richtigen Spruchkörper zuweisen, das Rubrum automatisch befüllen und Fristen automatisch berechnen. Die Kanzlei auf der Gegenseite könnte die Parteidaten direkt in ihre Kanzleisoftware übernehmen, ohne sie abtippen zu müssen. Was heute einen Nachmittag Verwaltungsarbeit kostet, würde sich auf Sekunden reduzieren.

Das ist keine ferne Utopie. Eine normale arbeitsrechtliche Klage lässt sich vollständig in ein strukturiertes JSON-Dokument übersetzen: Gericht, Absender, Parteien, Rollen, Antragsart und Antragsinhalt als klar benannte Felder mit eindeutigen Werten. Das Dokument existiert bereits – es wird nur noch nicht übermittelt.

Hinzu kommt der Aspekt der Nachvollziehbarkeit. Wer einen strukturierten Datensatz übermittelt, schafft zugleich eine prüfbare, maschinenlesbare Grundlage für alle weiteren Verfahrensschritte. Fehler bei der Parteibezeichnung, beim Streitwert oder bei der Klageart fallen sofort auf – nicht erst, wenn das Gericht nachfragt.

Was für die Klageeinreichung gilt, gilt spiegelbildlich für den Rückweg: die Ladung. Heute trifft eine Terminsladung als PDF im beA-Postfach ein. Die Mitarbeiterin öffnet das Dokument, sucht das Datum, die Uhrzeit, den Saal und die Information zur Erscheinungspflicht – und trägt alles manuell ein. Dabei sind diese Informationen bereits digital vorhanden. Sie stecken nur im falschen Format.

Eine strukturiert übermittelte Ladung würde diesen Zwischenschritt überflüssig machen. Verhandlungsdatum, Uhrzeit, Ort und Erscheinungspflicht kämen als definierte Felder an – und könnten von der Kanzleisoftware direkt in den Kalender übernommen, die Frist zur Vorbereitung automatisch berechnet und der Mandant automatisch informiert werden. Der Mensch würde nicht aus dem Prozess herausgenommen – aber er würde dort eingesetzt, wo er gebraucht wird: beim juristischen Urteil, nicht beim Abtippen.

Auch Verlegungsanträge ließen sich strukturiert übermitteln. Statt eines formlosen Schriftsatzes könnten Kanzleien einen standardisierten Datensatz senden, der Verfahrensnummer, gewünschten neuen Termin und Verlegungsgrund als Felder enthält. Das Gericht könnte den Antrag automatisiert vorprüfen und – bei Routinefällen – ohne manuellen Eingriff bescheiden.

Kaum ein Thema beschäftigt die Rechtsprechung zum elektronischen Rechtsverkehr so beständig wie Fristversäumnisse. Der BGH hat in einer Reihe von Entscheidungen klargestellt, welche organisatorischen Anforderungen Kanzleien bei der Fristenüberwachung einhalten müssen – und wie leicht es schiefgehen kann, wenn das Zustelldatum aus dem falschen Dokument abgelesen, falsch übertragen oder schlicht übersehen wird (vgl. BGH, Beschl. v. 29.5.2024 – I ZB 84/23; BGH, Beschl. v. 31.7.2024 – XII ZB 573/23).

Strukturierte Daten könnten einen erheblichen Teil dieser Fehlerquellen beseitigen. Wenn das Zustelldatum nicht mehr als Text in einem PDF steht, sondern als definiertes Feld in einem strukturierten Datensatz übermittelt wird, gibt es nichts mehr abzutippen und nichts mehr zu interpretieren. Die Kanzleisoftware empfängt den Wert, berechnet die Frist und trägt sie ein – ohne menschlichen Zwischenschritt, ohne Übertragungsfehler.

Die BGH-Rechtsprechung der letzten Jahre zeigt dabei ein wiederkehrendes Muster. In nahezu allen Fällen, in denen Fristen versäumt wurden, lag das Problem nicht beim Transport des Dokuments – das beA hat funktioniert – sondern beim Übergang vom digitalen Dokument in den analogen Kanzleiprozess. Das Zustelldatum wurde aus dem falschen Dokument abgelesen, die Frist falsch berechnet, der Eintrag in den Kalender versäumt. Strukturierte Daten würden genau diesen Übergang überbrücken: Das fristauslösende Datum käme nicht mehr als Text in einem PDF, sondern als Wert in einem Feld – direkt übernehmbar, nicht interpretierbar, nicht übertragbar in der falschen Weise.

Das gilt nicht nur für Zustelldaten. Auch Rechtsmittelfristen, Begründungsfristen und Einspruchsfristen könnten strukturiert übermittelt werden – direkt aus dem Urteil oder Beschluss, der sie auslöst. Der Gedanke, dass ein Urteil nicht nur den Tenor enthält, sondern auch maschinenlesbar mitteilt, welche Frist ab welchem Datum läuft, ist technisch ohne weiteres umsetzbar. Er erfordert keine neue Infrastruktur – nur die Bereitschaft, den vorhandenen Standard konsequent zu nutzen.

Am Ende eines Verfahrens steht eine Entscheidung – und auch sie enthält eine Vielzahl von Informationen, die strukturiert übermittelt werden könnten. Entscheidungstyp, Tenor, Kostenentscheidung, vorläufige Vollstreckbarkeit, Berufungsfrist: All das sind diskrete Datenpunkte, die heute im Fließtext eines PDF vergraben sind und auf der Empfängerseite manuell herausgelesen werden müssen.

Ein strukturiert übermitteltes Urteil würde nicht nur den Arbeitsaufwand in der Kanzlei reduzieren. Es würde auch die Fehlerquote senken. Wer die Berufungsfrist aus einem strukturierten Datensatz berechnet, kann sich nicht verlesen. Wer die Kostenentscheidung als Feld empfängt, muss sie nicht aus einem dreiseitigen Urteilstext herausfiltern. Und wer die vorläufige Vollstreckbarkeit als booleschen Wert – also als einfaches Ja oder Nein – übermittelt bekommt, weiß sofort, ob Sicherheitsleistung erforderlich ist.

Der Leitgedanke ist dabei immer derselbe: Das PDF bleibt – als lesbares Dokument, als Ausfertigung, als Urkunde. Aber es wird zur Beilage. Der eigentliche Informationsträger ist der strukturierte Datensatz, der die relevanten Felder maschinenlesbar enthält und auf beiden Seiten direkt weiterverarbeitet werden kann. Wer diesen Gedanken konsequent zu Ende denkt, versteht, was mit dem Satz gemeint ist: Das PDF wird Beilage, nicht mehr Träger der Informationen.

Für die Zwangsvollstreckung gilt dasselbe. Vollstreckungstitel, Gläubiger, Schuldner, Forderungshöhe und Zinsen könnten strukturiert übermittelt werden – direkt an den Gerichtsvollzieher, ohne Medienbruch. Dass gerade hier Fehler bei der Übermittlung erhebliche praktische Folgen haben können, hat die Rechtsprechung zuletzt anschaulich gezeigt (vgl. Cosack, Elektronischer Rechtsverkehr Ausgabe 3/2025, Rn 89 ff.).

Der offensichtlichste Vorteil strukturierter Daten ist die Automatisierbarkeit. Was als definiertes Feld ankommt, muss nicht mehr gelesen, interpretiert oder abgetippt werden. Aktenzeichen, Fristen, Parteien, Termindaten – all das kann direkt in die Kanzleisoftware übernommen werden. Der manuelle Zwischenschritt entfällt, und mit ihm ein erheblicher Teil der alltäglichen Fehlerquellen.

Eng damit verbunden ist die Eindeutigkeit. Unstrukturierter Text lässt Spielraum – ein Datum kann auf zwanzig verschiedene Arten geschrieben werden, ein Aktenzeichen kann an unterschiedlichen Stellen im Dokument auftauchen. Strukturierte Daten kennen diesen Spielraum nicht. Ein Feld hat einen Wert. Dieser Wert ist eindeutig, validierbar und reproduzierbar.

Schließlich eröffnen strukturierte Daten ganz neue Möglichkeiten der Weiterverarbeitung. Wer Verfahrensdaten strukturiert empfängt, kann sie auswerten, aggregieren und analysieren – über Mandate hinweg, über Gerichte hinweg, über Zeit hinweg. Für größere Kanzleien und Legal-Tech-Anwendungen ist das ein erheblicher Mehrwert. Aber auch die kleinere Kanzlei profitiert: von weniger Tippfehlern, weniger Nachfragen und weniger Fristversäumnissen.

Besonders deutlich wird dieser Vorteil bei Massenverfahren. Wer hunderte von gleichartigen Klagen bearbeitet – etwa im Bereich Verbraucherschutz, Mietrecht oder Kapitalanlagerecht – weiß, wie viel Zeit allein für die manuelle Erfassung von Parteidaten, Aktenzeichen und Fristen draufgeht. Strukturierte Daten würden diesen Aufwand auf ein Minimum reduzieren: Ein eingehender Datensatz wird automatisch verarbeitet, das Mandat angelegt, die Frist berechnet. Was bei hundert Verfahren einen halben Tag spart, spart bei tausend Verfahren eine ganze Woche. Die Reformkommission „Zivilprozess der Zukunft“ hat die Problematik von Massenverfahren ausdrücklich adressiert – strukturierte Daten wären ein wesentlicher Baustein ihrer Lösung (vgl. Bialłaß, Elektronischer Rechtsverkehr Ausgabe 3/2025, Rn 37).

So überzeugend die Vorteile klingen – strukturierte Daten haben ihren Preis. Der erste und gewichtigste Nachteil ist der Initialaufwand. Bevor strukturierte Daten fließen können, müssen Standards definiert, Schnittstellen entwickelt und Softwaresysteme angepasst werden. Das kostet Zeit, Geld und vor allem Koordination – zwischen Bund und Ländern, zwischen Justiz und Anwaltschaft, zwischen Softwareanbietern und Kanzleien. Wer die Geschichte des beA kennt, weiß, wie mühsam solche Koordinationsprozesse sein können.

Der zweite Nachteil ist die Standardabhängigkeit. Strukturierte Daten funktionieren nur, wenn beide Seiten dieselbe Sprache sprechen – dasselbe Format, dieselben Feldnamen, dieselben Wertekonventionen. Ein JSON-Dokument, das die Kanzleisoftware in einem Format erzeugt, das die Gerichtssoftware nicht versteht, ist wertlos. Das setzt voraus, dass sich alle Beteiligten auf einen gemeinsamen Standard einigen – und diesen Standard auch konsequent einhalten. Abweichungen, Sonderformate und Insellösungen sind der Tod jedes strukturierten Datenaustauschs.

Schließlich sind strukturierte Daten von Natur aus kontextarm. Sie transportieren Fakten – aber keine Argumentation, keine Nuancen, keine rechtliche Würdigung. Eine Klage besteht nicht nur aus Feldern und Werten. Sie enthält eine Geschichte, eine Argumentation, einen Antrag. Dieser Teil wird immer im Dokument bleiben – im Schriftsatz, im Urteil, im Beschluss. Strukturierte Daten sind das Skelett. Das Fleisch ist und bleibt der Text.

Die Abwägung fällt eindeutig aus – nicht, weil die Nachteile klein wären, sondern weil sie lösbar sind. Der Initialaufwand ist eine einmalige Investition. Die Standardabhängigkeit ist kein strukturelles Problem, sondern eine Frage des politischen Willens – und dieser Wille ist, wie die Aktivitäten rund um xJustiz, die Justizcloud und die Reformkommission zeigen, vorhanden. Die Kontextarmut schließlich ist kein Mangel, der behoben werden muss. Sie ist die Natur des Werkzeugs.

Strukturierte Daten werden den Schriftsatz nicht ersetzen. Sie werden die juristische Argumentation nicht automatisieren. Sie werden die Entscheidung des Richters nicht übernehmen. Was sie tun werden: den Verwaltungsaufwand rund um das Verfahren drastisch reduzieren – und damit Kapazitäten freisetzen für das, was wirklich zählt. Die Frage ist nicht, ob das erstrebenswert ist. Die Frage ist nur, wie schnell es gelingt.