Progress and pitfalls – a look at electronic legal transactions

Electronic legal transactions are a first, and very important, step in the digitalisation of the judicial system. Electronic legal transactions allow everyone involved in the process to transmit artefacts electronically and in a legally compliant manner. The second phase of digitalisation imposes the obligation to keep digital records at the courts starting from 1 January 2026.

XJustice is the standard for electronic legal transactions. It takes into account a wide range of requirements from widely different fields of law. Electronic legal transactions unquestionably offer a number of advantages for all parties concerned.

In this blog post, I will present the main points based on almost three years of in-depth work on electronic legal transactions, explore the technical challenges at the moment and describe ways you can tackle them.

The history of electronic legal transactions

Electronic legal transactions entered into force on 1 January 2018 following the passage of several laws. As a result, documents can be transferred via a secure means of transmission pursuant to Section 130(a)4 of the Code of Civil Procedure (Zivilprozessordnung, or ZPO) since this date. The use of electronic legal transactions fulfils the written form requirement.

Professional submitters – be that a public authority, an institution under public law or a lawyer – are obliged to file by electronic means since 1 January 2022.

From a technical perspective, transmission is subject to double encryption via SMTP (Simple Mail Transfer Protocol). Documents are transferred as attachments to an e-mail. In addition, there is metadata contained in an XML file ‘xjustice_message.xml’. This data includes, among other things, the file number, the parties to the proceedings, the attorneys of record (where applicable) and descriptions of the transmitted documents.

The infrastructure is operated by the ITZBund, with intermediaries responsible for transport. All participating parties are registered centrally so that only trusted senders can send e-mails.

Electronic legal transactions – technical challenges for recipients

The parties involved are currently facing several challenges relating to electronic legal transactions. These pertain to asynchronous transmission (fire-and-forget) and inadequate implementation in the software solutions used in the judicial system. The data for the outgoing messages in question is not sufficiently validated. Invalid messages are not systematically rejected or returned in order not to antagonise the courts and other senders.

Here is a list of some of the main challenges based on my experience in no particular order and with no claim to completeness:

• Incorrect classification of documents
• Improper handling of signatures
• Invalid characters in file names
• Use of an out-of-date XJustice standard

Incorrect classification of documents

The XJustice dataset contains several properties to classify the transmitted documents. A document can consist of several PDF files and, where applicable, signatures applied to the PDFs. The classification properties are implemented using key value lists. While incorrect classification affects all classes of documents, it can be best illustrated using rulings passed down by a court as an example. The classification properties allow you to determine whether a document is a ruling, such as a verdict in a case. There are typically deadlines for lodging an appeal associated with court rulings, which means that the recipient of a ruling against him or her has a specific amount of time to react. As a result of incorrect classification, resubmissions (remits) for appeal deadlines cannot be generated automatically, among other things. In practice, there are documents that are classified as rulings that do not contain a ruling, as well as rulings that are given the non-descript classification as ‘Other/misc.’. Since it is not possible at this time to rely on classification properties, all incoming post must be visually examined in order to classify and prioritise them.

Improper handling of signatures

An external signature can be affixed (as a separate file) to the transmitted PDF files. The XJustice standard sets out several rules to this end:

• The signature files must have the same file name as the matching PDF file, supplemented by the file extension pkcs7 or p7s.
• The file name may not exceed 90 characters in total (this also applies to PDF files).
• The signatures are to be set as a child element within a document node.
• The classification property Component partmust be set to Signature file .
• The signature files must contain a reference to the accompanying PDF file in the XML file (as a separate XML element).

In practice, there will be discrepancies between file names primarily due to 90 characters being established as the maximum file name length. The length of the PDF file name is also set to 90 characters. As a result, as many characters are removed from the signature file name, starting from the beginning, in order to get the file name down to 90 characters (including the file extension).

Signatures whose file name does not allow any conclusion to be drawn regarding the nature of the transmitted files are also transmitted. This typically occurs when the attorney of record for the opposing party also signs his or her legal documents digitally. Furthermore, there may be combinations in which one of the files contains spaces (also see: Invalid characters in the file name).

The signature files are often included as a separate document node instead of entering them as a child element. Likewise, the ‘Component part’ property is often not correct.

The element for the reference to the PDF file is missing in some cases. Beyond that, some courts apply an electronic signature for each judge in the case of rulings involving multiple judges. At the moment, the software only includes a reference node for one of the signatures. In real-world use, any combination of the errors listed above can be observed.

There are a number of consequences if signatures are not handled properly. For example, the input data can often not be validated, it is not possible – or not always possible – to automatically check the validity of the signatures applied to the documents and archiving is not possible.

Invalid characters in file names

The XJustice standard set outs a file naming convention that does not allow spaces to be used in the file name, among other things. And as the saying goes, anything that can go wrong will go wrong. There will be some that contain spaces if the PDFs and signatures are not automatically checked.

Use of an out-of-date XJustice standard

The XJustice standard is updated each year on 31 October. On this day, a new standard enters into force, at which time the version that will apply in one year’s time is also published. That means that software vendors and users have one year to update their systems. This is enough time for the vast majority of them, and every court observes the update cycle. However, there are a few vendors whose software is used outside of courts that send XJustice messages in out-of-date standards.

If the input data is checked to determine whether it is in the standard valid at the time, the messages cannot be processed if this is not the case.

Recommendations on ways to mitigate the challenges

The issues described above occur to varying degrees, depending on which vendor provides the software used by the sender. The majority of messages that are sent are error-free. For obvious reasons, the problems that have been identified should primarily be solved in the software in use at the party who sends XJustice messages.

Recommendations for document classification

In the author’s humble opinion, classification should be rule-based and automatic. The following generic recommendations can be made:

• Wherever possible, classification properties should already be linked to the corresponding document templates used to generate correspondence. By doing so, the decision regarding classification would not have to be made by the clerk. Instead, this would not be done until the template is created.
• When a lawyer forwards documents, for example, the existing classification properties can be applied as default values.
• Signatures should automatically be affixed with the appropriate classification (also see: Recommendations on how to handle signatures).
• Information on classification should be provided to legal clerks to raise awareness of the issue. In practice, one and the same person has been observed to classify the same type of document in different ways on different occasions.

Recommendations on how to handle signatures

Signatures can largely be automatically handled. The following recommendations can be made:

• Self-signed documents, such as rulings signed by judges, should ideally be signed in a workflow in the administrative software and properly affixed to the XJustice record.
• If this is not possible or if an external signature must be sent together with a document, there should be an easy way for the user to link the signature to the document.
• The maximum file name length of 90 characters should be checked starting from the signature and, if necessary, both file names should be shortened automatically.
• Classification of signatures should be done automatically on the basis of the file extension.

Recommendations for valid values in the file name

The file names of the PDFs as well as the file names of the signatures should be checked automatically for compliance with the file naming convention. Along with that, the file names should also be changed if necessary.

Recommendations on the use of a valid XJustice standard

There may be many reasons why an out-of-date XJustice standard is used, which could include: the manufacturer did not provide an update in time, the customers did not promptly update their software or the software was being used incorrectly.

When it comes to sending message, one recommendation would be for the user to receive a warning if he or she is using an invalid standard. On the recipient side, older versions should also be accepted as part of the validation process. If this were not the case, it would not be possible to process certain messages.

Outlook

The German states that already use an integrated software solution for digital record keeping and participation in electronic legal transactions send messages that are of an overall higher quality and contain fewer validation errors. As such, the obligation to maintain records in digital form represents an opportunity to increase data quality through the use of an integrated software solution.

Conclusion

Electronic legal transactions are a highly successful digitalisation project by the German government. In practice, certain details (still) need to be worked out, but these issues can be ironed out relatively easily. adesso would be more than happy to support you here.

Would you like to learn more about other exciting topics from the adesso world? Then take a look at our blog posts published so far.