beA automation: intake, approval and delivery checks

This guide describes a possible workflow for German law firms. Legal and technical sources were checked on 26 September 2026. It does not determine an individual deadline, service event or representative’s authority. The examples below are proposed acceptance scenarios, rather than results from a completed client implementation.

Message path. Map the complete incoming path: detect a message, identify the matter, preserve documents, assign an appropriate reviewer, check deadlines and prepare any necessary response. Outgoing work adds recipient selection, document version, the applicable formal requirements, dispatch and receipt checks. Different people and applications may own these steps.

Duty to take notice. The obligation to maintain the necessary technical facilities and take notice of service and communications through the mailbox appears in section 31a(6) BRAO. Configuring message retrieval therefore does not replace an operating process that gets relevant messages reviewed. Assign an owner, cover during absence and a visible list of outstanding work.

Where time is lost. Measure where time is currently lost. Typical candidates for investigation include ambiguous matter references, duplicated attachment filing, unassigned messages and time spent finding delivery evidence. A project addressing specific tasks is easier to specify than a general promise of an “AI lawyer.” It should fit the existing deadline register and practice-management system.

Permissions. The official beA permissions manual distinguishes opening, exporting, creating drafts, sending messages and sending electronic acknowledgments of service. If you have permission to create a draft, that alone does not allow you to send it. Confidential messages and certain role-dependent permissions require separate attention.

Permission matrix. Create a small permission matrix using the actual accounts that will operate the process. Someone matching documents to matters does not automatically need every sending or administration permission. Representatives and professional-practice entities have specific roles; the official role directory explains their technical distinctions. Legal authority must also be established for the intended action.

Certificates and PINs. Personal certificates and PINs should not become a shared automation account. Their secure use is governed by section 26 RAVPV. Ask the supplier which supported identity its connection uses and what that identity can do. An unclear answer is an unresolved implementation requirement, not something to leave until after installation.

An initial workflow can register new messages, propose matter assignments and make the complete message available for review. Use a stable message identifier so repeated retrieval does not generate duplicate tasks. Preserve the relationship between the original message, its attachments and the working record in the practice system.

The table shows, for five observations in beA message intake, the possible preparation and the decision still required.

Poor extraction must not quietly become “no action required.” An unreadable attachment, conflicting reference or missing page should remain visible. The unresolved queue needs a named owner and cover, otherwise the automation has simply created a second mailbox that nobody reliably monitors.

Candidates. A language model can highlight dates and possible deadline references. It should show the relevant message and exact passage alongside each candidate. A binding deadline calculation depends on the proceeding and facts. Receipt, service, awareness and a date mentioned in the document are not interchangeable events.

Synthetic acceptance case. A synthetic acceptance case contains three dates: the date of the letter, a stated appointment and a passage discussing a deadline. The expected output is an understandable account of these candidates, rather than an unchecked choice of the earliest or latest number. The appropriate professional confirms the meaning, starting event and entry in the authoritative deadline register.

Corrections. Specify how corrections feed back into the workflow. If a proposal is rejected, that decision should close the task visibly. If an approved deadline changes, retrieving the original document again must not overwrite it with the older model suggestion. Mixing suggested values with confirmed entries makes later checking substantially harder.

Evidence of service. Under section 173(3) ZPO, the electronic acknowledgment of service provides evidence of electronic service. It is therefore not an ordinary intake checkbox that a model should set from the retrieval timestamp. The firm must define who is responsible for the declaration and how the correct date is determined.

Sending by staff. It would also be too broad to say that staff can never perform the technical sending step. The Hamburg Bar Association’s FAQ expressly describes a representation scenario in which the lawyer acting as representative applies a qualified electronic signature and an employee can then send the eEB. The necessary permissions and other prerequisites must be met.

Automation boundary. A useful automation boundary is therefore preparation of a complete decision record, followed by whatever technical processing is permitted in that specific configuration. The work instruction should distinguish the decision to acknowledge service, date, responsible person, signing procedure and transmission route. A single field labelled “approved” would conceal these separate questions.

Signature and transmission route. Section 130a(3) ZPO distinguishes a qualified electronic signature by the responsible person from signing and submission through a secure transmission route. The firm must establish which person and mailbox may act in its particular scenario. A software permission to press Send does not by itself answer that legal question.

Version binding. Before connecting an application, examine how it binds approval to the document version. If an attachment is replaced after review, the earlier assessment of its contents does not automatically apply to the replacement file. The intended signing and sending sequence must therefore operate on the exact final document package.

Acceptance test. A meaningful acceptance test deliberately changes a file after approval. The expected behaviour is renewed review or an effective block on unnoticed replacement. Also record how the recipient, matter reference and attachment list are checked. These business characteristics matter more than the number of clicks removed from the interface.

Receipt versus signature. Court receipt must be distinguished from a successful signature check. The Federal Administrative Court made this distinction explicit for a time-sensitive pleading in its decision of 16 May 2025, 5 B 8.25. A signature record documents the signing process; it does not replace checking the court’s confirmation of receipt.

Delivery evidence. The beA support explanation of delivery evidence describes the intermediary receipt information and full delivery response. Ask the supplier to demonstrate exactly which data the chosen practice software retrieves. A dashboard should display only the state supported by the evidence actually available.

Exception queue. For the proposed automation, connect each outgoing record to its corresponding confirmation and place missing or conflicting evidence in an exception queue. Define who acts on that exception within the required time window. Sending an alert to an unattended shared inbox does not establish a functioning escalation process.

Export package. The official message export creates a ZIP file containing the message and associated information, including records, structured data and available attachments or signature files. An automatically generated summary or a single PDF is therefore not equivalent to the full export package.

Storage. Specify where that original package is stored and how a readable working view remains connected to it. An export failure must not silently become an “archived” status. Use a test export to check that an authorised reviewer can subsequently find and open the message, attachments and relevant evidence in the destination system.

AI summary. Additional processing may be useful for an AI summary. Document which content reaches which service, who can access it and when working copies are removed. The fact that the original is held in beA does not answer those questions for an additional provider or an independently maintained search index.

Have the integration demonstrated in the intended version of your practice software. Check retrieval, export and returned status independently. Support for reading does not establish permission for a writing operation. Record unresolved manufacturer questions in the proposal and require an understandable configuration handover. If suppliers change, matter relationships and preserved evidence must remain available; a fresh import should not reopen every completed task.

The table sets out three failure cases to rehearse before a beA automation goes live, each with its test setup and expected outcome.

Outages. For temporary technical inability to submit electronically, section 130d ZPO sets conditions for alternative submission and substantiation. This is not blanket permission to choose any alternative channel whenever software shows an error. The responsible lawyer must assess the circumstances; the system should make timestamps, errors and attempted actions available for that assessment.

Acceptance. Start practical acceptance with approved sample data and a bounded set of mailboxes. Measure correct assignments, unresolved exceptions, time spent locating evidence and the review work that remains. Compare these observations with the previous process. Less manual work is useful only when responsibility and the supporting records remain at least as clear.

Deliverable. The deliverable should be an understandable operating process: individual identities, bounded permissions, complete originals, reviewed decisions and checked transmissions. The draft and sign-off approach and our law-firm guide help define the steps for your team. The document-processing acceptance guide adds relevant extraction and document-handling failures.

These pages continue the planning of beA workflows in a law firm:

• AI automation: tasks, selection and implementation
• AI automation for law firms
• AI workflow approvals: who checks which action?
• Write a testable AI automation project brief
• Testing AI document processing: an acceptance template