Use caseDocument AIWorkflow automation
Court mail read, deadlines calculated by rules, and every one confirmed by a lawyer
Court documents from beA or e-filing read, service dates and deadlines calculated by rules in code, proposed in your case system and confirmed by a lawyer.
A blueprint, not a client story. The business described is illustrative; the architecture, integrations and trade-offs are real, and this is how I would build it. By Ergini, .
The short version
A docketing workflow for litigation firms. It reads court documents as they arrive through beA or e-filing notices, classifies them, extracts the periods, dates and hearing details with the sentence each came from, matches the matter, and calculates deadlines with rules in code that know weekends and public holidays by state. Proposed entries go into RA-MICRO, Advoware, DATEV Anwalt or Clio, and the responsible lawyer is alerted. A lawyer confirms every deadline; the model never sets one.
- Best for
- Litigation firms that receive court mail electronically but still calculate and enter every deadline by hand.
- Connects to
- beA or e-filing notices, RA-MICRO, Advoware or DATEV Anwalt, Clio, LEAP or Actionstep, Outlook, Holiday and rules calendar
- The AI does
- Classifies court documents and pulls out the court reference, the parties, each period or date the court sets and the hearing details, with the sentence each came from.
- People do
- Submit the acknowledgment of receipt, confirm every calculated deadline, handle extensions, and decide anything the rules do not cover.
- Built as
- AI Workflow Automation, usually $15K - $30K
The clerical task with a malpractice claim behind it
Take a litigation firm in Hamburg with 25 lawyers and a team of legal assistants. Court documents arrive through beA, the electronic mailbox every German lawyer has, and filing with the courts has been electronic for lawyers for several years. In an ordinary week that is well over a hundred court documents: judgments, orders, hearing notices, and the other side's briefs forwarded by the court.
Every document that starts a deadline goes through the same routine. A legal assistant reads it, works out what triggers the deadline and how long it runs, counts the days, checks weekends and public holidays, enters the deadline and a pre-deadline reminder in the case management system, and puts it in front of the responsible lawyer. The lawyer checks it, often in a hurry, often at the end of the day.
It is the most dangerous clerical task in the firm. A missed statutory deadline can lose a case outright, and afterwards the first question is whether the firm's deadline control was properly organized. So firms build double checks around it, the routine is slow by design, and it still depends on a person counting days correctly at six in the evening.
The same problem exists elsewhere under other names. US firms docket from e-filing notices against federal and state court rules; UK firms work from court emails and electronic filing notifications under the Civil Procedure Rules. The systems differ. The need for rules that compute and a lawyer who confirms does not, and neither does the case for keeping a model well away from the date itself.
The deadline routine, by hand and with the workflow
By hand
- A legal assistant opens every beA message and decides which ones start a deadline
- The service date comes from the acknowledgment of receipt, if someone remembers to look
- Days are counted by hand or in the software's calculator, one deadline at a time
- Regional holidays depend on the person counting knowing them
- The lawyer confirms a line in a calendar without seeing the sentence it came from
With the workflow
- Every court document is classified on arrival, and nothing sits unread in the mailbox
- Deadlines are computed provisionally from the day of receipt, then recomputed from the date on the acknowledgment
- Every period, weekend and holiday shift is calculated by the same tested rules
- Holidays come from a calendar per state, and per municipality where that matters
- The lawyer sees the court's sentence, the computation and the proposed entry side by side
An order with a period and a hearing date in it
Court documents often carry more than one date. Each becomes its own proposal, confirmed on its own.
beA, Thursday 3 September 2026, 17:41
- fetch_new_messages(inbox: "beA via case system")1 message from Landgericht Hamburg / 2 documents: order (Verfügung, 2 pages), plaintiff's brief of 28 August (18 pages) / acknowledgment of receipt requested
- classify_and_extract(document: "Verfuegung.pdf")court order / reference 312 O 188/26 / item 1: 'binnen drei Wochen' from service, to respond to the plaintiff's brief / item 2: hearing 26 Nov 2026, 10:30, room B 3.18, personal appearance of the parties ordered
- match_matter(court: "LG Hamburg", reference: "312 O 188/26")1 match: matter 2026/0412 / client is the defendant / responsible lawyer and deputy on file
- service_date(message: "beA-7731")acknowledgment not yet submitted / provisional trigger: day of receipt, 3 Sep 2026
- compute_deadline(period: "3 weeks", trigger: "2026-09-03", court_state: "HH")ends Thu 24 Sep 2026 / no weekend or holiday shift / reminder Thu 17 Sep (firm rule: one week before) / status: provisional
Docketing workflow · Outlook
New court order in 2026/0412 (LG Hamburg, 312 O 188/26). Proposed: response to the plaintiff's brief due Thu 24 Sep 2026, provisional until you submit the acknowledgment of receipt; reminder Thu 17 Sep. Hearing Thu 26 Nov 2026, 10:30, room B 3.18, personal appearance ordered. Both entries are waiting for your confirmation in the case system.
- Next morning the lawyer submits the acknowledgment, giving Friday 4 September as the date of service. The workflow recomputes: deadline Fri 25 Sep, reminder Fri 18 Sep. The provisional and final versions both stay in the log.
Responsible lawyer · Case system
Confirmed 25 Sep and the hearing. Client has to attend in person; informing them today.
Read, compute, confirm: one court document's path
The model reads. Rules compute. A lawyer confirms. That split is the whole design, and each step below belongs to exactly one of the three.
01 Trigger · Case system beA interface, Microsoft Graph
A court document arrives
The case management system fetches beA messages with the firm's own credentials, and the workflow picks them up from there; it never logs into beA itself. Outside Germany, e-filing notices and court emails arrive the same way through the firm's mail system.
02 AI model · Structured output
Classify and extract
The model identifies the document type (judgment, order, hearing notice, forwarded brief) and extracts the court, reference, parties, each period or date the court sets and what triggers it, and hearing details, each with its source sentence. Periods come back as written ('drei Wochen'), never as a calculated date.
03 Plain code
Match the matter
Court and reference must match an open matter, and at least one party name must agree. A reference misread as '312 0 188/26' is normalized first. No match, or more than one, goes to a legal assistant.
04 Plain code
Fix the trigger date
Where service needs an acknowledgment of receipt, the date on the acknowledgment starts the period. Until the lawyer submits it, deadlines are computed from the day the message arrived, which can only produce an earlier date, and are marked provisional.
05 Plain code
Compute each deadline
A rules module turns each period into a date: the firm's table of deadline types, the counting rules, the shift when a period ends on a weekend or public holiday, and the holidays at the court's location. The firm's pre-deadline reminder is added, and every step of the computation is stored.
06 Decision
Can it be proposed as it stands?
Code decides, from what the extraction and matching returned.
- One matter, a clear trigger, periods the rules table covers then propose the entries and alert the responsible lawyer
- Several dates in one document, or a court-set date that conflicts with the computed one then propose each separately, with the conflict highlighted
- Unknown document type, no clean matter match, a period outside the table, or an extension then to a legal assistant, with nothing entered
07 System · Case system API or import
Write proposals to the case system
Entries go into the deadline calendar marked unconfirmed, with reminder, responsible lawyer and deputy. Writes are keyed by message, document and item, so a retry never creates a second entry. If the case system is unreachable, proposals go out by email with a warning and are written once it returns.
08 Person
The lawyer confirms each entry
The lawyer sees the court's sentence, the computation and the proposed entry side by side, and confirms, corrects or rejects each one. Only confirmed entries count. Unconfirmed proposals escalate to the deputy and the office manager at a set time.
09 Result
An audit trail for every deadline
Source document, extracted text, trigger, each computation step, who confirmed and when. It is the record a firm needs if its deadline control is ever questioned. A pipeline that fails silently is worse than none, so any court document left unprocessed for an hour raises an alert to the office manager.
Six ways a docketing system gets a deadline wrong
An ambiguous service date
Electronic service to lawyers turns on the acknowledgment of receipt, and the date on it is the one the lawyer declares. Computing from the arrival date until then keeps any error on the early side, and a recompute replaces the provisional entry the moment the real date is known. The workflow never submits the acknowledgment.
Several deadlines in one document
A judgment can start more than one period; an order can set a deadline, schedule a hearing and ask for a document. The extraction schema is a list, not a single field, and each item is confirmed separately, so confirming one never quietly confirms the others.
Extensions and moved hearings
When the court grants an extension or moves a hearing, the new document supersedes the old entry instead of adding a second one, and the history is kept. The rules table also marks the deadline types that cannot be extended at all (Notfristen), so nobody treats an extension request as a safety net for them.
The wrong matter
Two matters against the same opponent, a reference misread by OCR, a court that renumbered a chamber. Matching needs the court, the reference and a party name, and anything short of one clean match is a person's call. A deadline filed in the wrong matter is a deadline missed in the right one.
Regional holidays
If a period ends on the Day of Prayer and Repentance, it moves to the next working day before a court in Saxony, the only state where that is a public holiday, but not before a court in Hamburg. In Bavaria, some holidays apply only in certain municipalities. The calendar holds holidays per state and municipality and applies those at the court's location.
A model that is confidently wrong
Models misread dates and occasionally invent them. So the model never outputs a deadline: it returns the court's wording and the trigger, code computes, and any absolute date the court wrote is parsed and checked against the text around it. A disagreement stops the proposal and goes to a person.
Running beside the existing deadline control before replacing any of it
The four-eyes principle holds at every stage; what changes is who types, and how much evidence the lawyer sees when confirming. The replay below is an evaluation set in the sense of the LLM evaluation guide, with the firm's own court mail as the test data.
| Stage | What happens | Moves on when |
|---|---|---|
| Replay | A year of past court mail runs through extraction and rules, and every result is compared with what the firm actually entered. | Every difference is explained: either a rule is fixed, or the old calendar was wrong. |
| Parallel | The workflow reads live court mail and computes deadlines into a separate log. Staff docket by hand as before, and differences are reviewed daily. | Several weeks of live mail with no unexplained differences. |
| Proposals | Entries appear in the case system as unconfirmed proposals. Legal assistants check and forward them instead of typing, and lawyers confirm. | Assistants rarely correct proposals, and only in categories already understood. |
| Straight to the lawyer | Proposals for document types with a clean record go directly to the responsible lawyer; assistants work the exceptions queue. | This is the last stage. A lawyer's confirmation is never removed. |
Who is allowed to decide a date
The AI model
Classify court documents and extract periods, dates and triggers with their source sentences
Court language varies by court and judge; reading it is a language task.
Plain code
Normalize references and match the matter
Exact matching, with clear rules for when to stop.
Take the trigger date from the acknowledgment of receipt
A recorded fact, not an inference.
Compute deadlines, shifts and reminders
Deterministic, versioned and tested against past mail.
A person
Submit the acknowledgment of receipt
It is the lawyer's own declaration.
Confirm, correct or reject each proposed deadline
The four-eyes principle, with a lawyer as the second pair of eyes.
Handle extensions, unknown documents and unmatched mail
Cases the rules table does not cover need judgment.
Maintain the rules table and holiday calendar
Owned by a named partner, changed through review, and every change tested before it goes live.
Your law firm software already has a deadline calculator. Is that enough?
For the calculation itself, often yes. RA-MICRO, Advoware, DATEV Anwalt and similar systems include deadline calculators and beA integration. In the US, rules engines such as CompuLaw compute deadlines from court rule sets, and docketing services will do the entering for you. If your bottleneck is counting days, use what you already pay for.
What those tools do not do is read. Someone still opens each document, decides what it triggers, types the period and matches the matter. A custom workflow earns its cost at firms with a high volume of court mail, several practice areas with their own deadline types, or a mix of systems (a German office on beA and RA-MICRO, a UK office on LEAP) that no single vendor covers.
The version I would build keeps your case management system as the only calendar that counts, uses its calculator where it exposes one and my own tested rules module where it does not, and adds the reading, matching and proposal layer in front of it. Firms that cannot send client documents to an external model run the reading on a private, EU-hosted model, and nothing else in the design changes. The other legal use cases follow the same rule: the model reads, a lawyer decides.
How you would know it is working
A blueprint has no results to report, so here is what I would measure from the first week instead, on your own data.
- Proposals confirmed unchanged, by document type
- The share of proposed deadlines the lawyer confirmed without correction. Every correction is reviewed and becomes a test case.
- Time from receipt to confirmed deadline
- From the beA message arriving to the lawyer's confirmation, with proposals past the escalation time counted separately.
- Provisional-to-final differences
- How often the acknowledgment date differs from the day of receipt, and by how much. This shows how much the conservative provisional rule matters in your firm.
- Documents that fell to a person
- Unmatched and unclassified court mail, by reason. The list shows which document formats or deadline types to add to the rules next.
What a build like this costs
This is built as AI Workflow Automation, which runs $3.5K - $60K overall. A build like this one usually lands in the multi-step workflow tier: $15K - $30K, 3-5 weeks. The first working version runs on your real data well before the end of that window.
What it costs to run
Court documents are short and the model only reads them, so model costs are cents per document on a hosted model. The rules module and holiday calendar cost nothing to run but need a small recurring maintenance budget when rules or holidays change. Self-hosting the model adds a fixed monthly infrastructure cost.
What moves the price
- The case management system's interface: an API, an import format, or careful desktop automation
- How many deadline types and practice areas the rules table covers at launch
- How many jurisdictions: German states only, or German, UK and US courts with different rules
- Whether documents may go to an EU-hosted model or the reading must run on the firm's own infrastructure
- The size of the historical replay used to test the rules before go-live
Who this is for
- German litigation firms receiving court mail through beA and docketing by hand in RA-MICRO, Advoware or DATEV Anwalt
- Firms with offices in several countries whose docketing runs on different systems and rules
- In-house legal teams tracking court deadlines across matters run by several outside firms
- US and UK firms that already use a rules engine but still read and key every notice by hand
Questions people ask about this
Can AI calculate court deadlines?
It should not calculate the date. A language model can read a court document and find the period and what triggers it, but the date itself should come from rules in code: the period, the counting rules, weekends and the public holidays at the court's location. That makes the result repeatable and testable against past cases, and a lawyer still confirms every deadline before it counts.
How do I automate beA deadline management?
Pick up court documents after your law firm software has fetched them from beA, have a model classify them and extract periods and dates with their source sentences, match the matter by court reference, and compute the deadlines with a tested rules module. Proposals go into the case management system as unconfirmed entries for the responsible lawyer. The acknowledgment of receipt stays the lawyer's own act.
Does this replace the four-eyes principle?
No. It changes who does the first check. Instead of a legal assistant typing each deadline and a lawyer checking it, the workflow proposes each entry with its source sentence and computation, and the lawyer confirms. Exceptions still go to legal assistants, and nothing counts as entered until a lawyer has confirmed it.
What if our partners won't put client files into an AI model?
Then the reading runs on a model inside infrastructure the firm controls, and nothing leaves it. Often the real objection is less the model than the lack of oversight, so the build keeps a per-matter log of every AI action: which document was read, what was extracted, what was proposed and who confirmed it. Nothing is used for training, and logs hold references rather than document content.
What does legal docketing automation cost?
For one jurisdiction, the main court document types and one case management system, a build like this usually fits the multi-step tier of AI workflow automation shown on this page, three to five weeks including the replay test. More jurisdictions, a case system without an interface, or self-hosted models move it up. Per-document model costs are small.