Bundle preparation consumes more paralegal hours than most litigation practices care to measure, and it remains one of the least examined candidates for automation. Firms reach for AI on the headline work — contract review, due diligence, disclosure analysis — while the hours spent paginating, indexing, deduplicating, and hyperlinking court bundles stay firmly in the paralegal billing column. That is a costly and entirely avoidable oversight.

This article is written for litigation partners, practice managers, and innovation leads at UK law firms who want a clear-eyed view of what automation can reliably do here, where it falls down, and what a sensible build looks like. We build bespoke automation for firms and operate it on their behalf, so our interest is in getting the assessment right, not in selling a particular platform.

What bundle preparation actually involves — and why it doesn't automate cleanly end to end

A trial bundle under the CPR involves more than assembly. Practice Direction 32 sets the base requirements; individual courts — particularly the Business and Property Courts — layer additional e-bundle specifications on top, often judge-specific. You are dealing with document selection, chronological or thematic ordering, pagination, an indexed table of contents, hyperlinked cross-references in the electronic version, and compliance with HMCTS e-bundle standards. Since the Disclosure Pilot Scheme under PD57AD came into force in the Business and Property Courts in January 2019, the disclosure dimension of large commercial litigation bundles has added further structure requirements that interact directly with how bundles are assembled and checked. The current CPR bundle requirements and associated practice directions are published on HMCTS's Civil Procedure Rules portal.

The common assumption is that because bundles are formulaic, the whole task automates cleanly. It doesn't. The assembly automates well. The selection — deciding what goes in, what's duplicative but not identical, what needs to be redacted — still requires legal judgement. Automation handles the former reliably. It should not be trusted with the latter unsupervised, and any system that claims otherwise is either misrepresenting its capability or has not been tested on a genuinely contested commercial matter.

Where automation genuinely earns its keep

The highest-value targets are the mechanical steps that consume paralegal time without requiring legal judgement:

  • Deduplication: Large litigation matters routinely produce document sets where the same email appears in three custodians' exports, each with minor metadata variation. Exact-match deduplication is trivial; near-duplicate detection — same content, different headers or timestamps — requires a similarity threshold approach. We typically set this at 95% similarity with human sign-off on flagged clusters. Not because the model can't go higher, but because a court will not accept a missed document on the grounds that the system was 97% confident.
  • Pagination and TOC generation: Fully automatable once the document set is confirmed. The failure mode to plan for is scanned PDFs where OCR quality is inconsistent — you get phantom page counts when the OCR layer and the visual layer disagree. Pre-processing through a dedicated OCR pipeline before committing to pagination resolves this, but it adds a step most firms have not built.
  • Hyperlink generation: HMCTS and most commercial court judges now expect electronic bundles with working cross-reference hyperlinks. This is automatable using PDF manipulation libraries against a properly structured index. Where it fails is when document references in the text are non-standard — a witness statement citing "the email of 14th March" rather than a bundle tab and page number. Named entity recognition catches most of these, but in our experience expect a 5–8% miss rate on ambiguous references that a paralegal would catch by context.
  • Chronological ordering: Straightforward where documents carry reliable metadata. In our experience, around 30% of documents in a typical litigation export carry unreliable or missing creation dates. You need a fallback: either extracted dates from document text or a manual review queue. Assuming clean metadata and discovering otherwise mid-build is the single most common cause of project overrun in this space.

The tools most firms are already using — and their real limitations

Bundledocs is the most widely used dedicated bundle preparation tool in UK litigation. It handles pagination, TOC, and hyperlinking in a structured workflow that integrates with most DMS environments. The limitation that catches firms out: Bundledocs is a manual-input tool at its core. It does not ingest a raw document export and make decisions — a human still works through a defined sequence of steps in the interface. That is appropriate for the judgement-dependent stages, but it means the efficiency gains are modest compared with what a purpose-built automation layer delivers. You are reducing friction, not removing labour. For a medium-sized commercial litigation matter with a bundle of 800–1,200 pages, Bundledocs typically saves two to three paralegal hours against a fully manual approach. That is real, but it is not the same as cutting the paralegal task to a quality-check.

Azure Document Intelligence — formerly Form Recogniser — has become the practical workhorse for legal document pre-processing in the UK market. It handles OCR, table extraction, and key-value pair identification at scale, with predictable pricing: roughly £0.01 per page for the standard Read model at current Azure rates. The failure mode we see repeatedly is confidence scoring. The API returns a confidence score per field, but firms rarely configure a meaningful rejection threshold, so low-confidence extractions flow through into the downstream pipeline unchecked. We set a hard rejection threshold at 0.85 and route anything below it to a human review queue. Without that gate, you will ship bundles with incorrect pagination on scanned legacy documents and not discover it until counsel raises it — at which point the bundle needs to be rebuilt under time pressure.

We have covered the broader mechanics of the pre-processing layer in more depth in our article on legal document extraction from PDF to structured data, which is worth reading before scoping the ingestion stage of any bundle automation project.

One misconception worth correcting before you build anything

The most common misconception we encounter is that bundle automation requires a large language model at its core. It doesn't. The majority of the value in bundle automation comes from deterministic rules and structured pipelines: OCR pre-processing, deduplication logic, metadata extraction, PDF manipulation for pagination and hyperlinking. An LLM adds genuine value only at specific decision points — identifying what an ambiguous document reference is pointing to, classifying borderline documents for inclusion, or drafting index descriptions. Using an LLM for the whole pipeline is slower, more expensive, and less auditable than a hybrid approach that applies the right technology to each stage.

If you are being pitched a bundle automation tool described as "powered by AI" as a general claim, ask them to specify which steps use which technology. The answer will tell you quickly whether you are talking to people who have actually built and operated this in production, or people who have built a wrapper. This distinction between genuine AI agents and simpler automation matters across legal workflows more broadly — we have written about where AI agents are and are not the right tool for legal workflow problems, and bundle preparation is a useful case study precisely because most of it does not need an agent at all. It needs a well-engineered pipeline.

What a sensible build looks like

Based on what we have built and operated, a well-designed bundle automation pipeline for a litigation practice runs as follows:

  1. Ingestion and pre-processing: Raw document export from DMS → OCR normalisation via Azure Document Intelligence or equivalent → metadata extraction with confidence scoring → rejection queue for anything below the confidence threshold.
  2. Deduplication: Exact hash match first, then near-duplicate clustering at a configurable similarity threshold. Flagged clusters go to a human review interface. Auto-resolution of near-duplicates is not appropriate without supervising fee-earner sign-off.
  3. Structure assembly: Chronological or thematic ordering using extracted and verified dates, with a manual override queue for undated or ambiguously dated documents. Pagination generated programmatically against the confirmed document set.
  4. TOC and hyperlink generation: Automated against the confirmed structure. An NER pass flags in-text document references for human verification before the bundle is finalised.
  5. Output and QA: Draft bundle produced in the required format — PDF with bookmarks and hyperlinks — alongside an auto-generated QA checklist. The supervising fee-earner signs off before filing. The audit trail is complete and exportable.

The paralegal is not removed from the process. They are repositioned to handle the rejection queues and sign off on outputs — which is where their judgement is genuinely needed. On a matter with a 1,000-page bundle, this typically reduces paralegal time from eight to ten hours down to two to three hours, with higher consistency and a defensible audit trail if the bundle is challenged.

The financial case is not complicated. At a paralegal charge-out rate of £150–200 per hour, each bundle represents £750–1,400 of recoverable or absorbed time. Across a busy litigation practice running thirty to fifty significant matters a year, the arithmetic is straightforward. The real cost of manual document work in UK law firms is routinely underestimated because it is distributed across matters rather than visible as a discrete line item — which is exactly why it persists.

The question to answer before you commission anything

Before scoping a bundle automation project, establish what your current document export quality actually looks like. If your DMS exports are clean, consistently named, and reliably dated, you can move quickly and the pipeline build is predictable. If your document management is inconsistent — legacy matters with unstructured filing, mixed PDF quality, custodian exports with metadata stripped — the pre-processing layer becomes the majority of the project, and it needs to be scoped and costed before you touch the bundle assembly step.

If you are running a litigation practice and want a specific assessment of where your current bundle process could be automated and at what cost, we are happy to work through it. Contact us with a brief description of your matter volumes and current tooling — that conversation tends to be more useful than a generic demo.