If you have ever tried to manually categorise a 200-page mixed PDF — invoices next to notary letters next to insurance policies — you already know that the hard part is not reading each document individually. It is holding the whole picture in your head while you do it.
One document at a time, you can triage accurately. Two hundred documents at once, your classification decisions start to drift. The forty-seventh insurance letter gets a different level of attention than the first one. Context from three documents back bleeds into your reading of the current one. You make errors you would not make if you were fresh.
Batch processing is designed to solve this — and several of the problems it faces are structurally different from the problems of processing a single document well.
The first question: where does each document start?
When a user uploads a 200-page PDF, the first question the system has to answer is not "what is in this document?" but "how many documents are in here, and where does each one start and end?"
A PDF of that size almost certainly contains multiple distinct documents. The transition between them is often visually clear to a human reader — a change in letterhead, a new date, a different document format — but has no formal marker in the PDF specification itself. A PDF is structurally a sequence of pages. Nothing in the format indicates that a new document begins on page 47.
Document boundary detection — identifying where one document ends and another begins — is one of the more genuinely difficult parts of batch processing. The system looks for signals: changes in visual layout, changes in the sender or recipient information extracted by OCR, discontinuities in the document type the language model infers from each page. These signals are probabilistic and usually correct. When they are wrong, the failure mode is either two documents being merged into one (under-segmentation) or a single multi-page document being split in the middle (over-segmentation).
Both failure modes are visible in the results: an unusually long entry with mixed content, or two adjacent entries with very similar content and low confidence scores. Checking the OCR preview for these cases quickly reveals what happened.
The multilingual batch
Batch uploads that contain documents in multiple languages add another layer of complexity that does not exist when processing a single-language document.
Language detection is a necessary pre-processing step. The OCR models optimised for German and Spanish are not the same model — they have been trained on different character distributions and layout conventions. Applying the wrong model degrades text extraction quality in ways that then propagate into classification errors.
When a single PDF contains alternating German and Spanish documents — the kind generated by a cross-border business operating in both markets — the system has to detect language at the document level, not the file level, and route each document segment to the appropriate processing path. Language detection at the document level is more reliable than at the page level, because individual pages sometimes lack enough text for confident detection (a cover page, a signature page, a diagram with minimal text).
Classification then operates on correctly extracted text in whatever language that text is in. The category taxonomy — invoice, contract, property document, bank statement — is language-agnostic: the structural patterns that identify an invoice are present in German, Spanish, French, and Italian documents, and the language model is trained to recognise them across all of them.
Confidence distributions across a batch
When you process a single document, a low confidence score is information about that document. When you process two hundred, the distribution of confidence scores across the batch is itself diagnostic.
A healthy batch looks like this: roughly 85–90% of documents score above 0.80, with a small tail of lower-confidence documents representing genuinely ambiguous cases — unusual formats, very short content, or degraded scan quality. In PaperSweep's results table, sorting by confidence ascending immediately surfaces these cases for manual review. In a well-scanned batch, that list is short.
An unhealthy batch looks different: a large proportion of documents scoring below 0.65, spread across many categories rather than concentrated in a specific type. This pattern usually indicates a systematic problem — poor scan quality throughout, a document type the model handles less well, or boundary detection errors that have fragmented documents incorrectly.
The confidence score on each document is designed to make this pattern visible. It is not just a quality indicator for individual documents; it is a signal about the batch as a whole.
What does not scale linearly
Several problems get structurally harder as batch size increases, not just slower.
Cross-document deduplication — identifying when the same document appears twice in a batch — requires comparing documents against each other, not just classifying each one in isolation. At small scale this is a trivial check. At 200 pages with potential partial duplicates (page 3 of document A is the same as page 3 of a different version of document A), it requires a different algorithmic approach entirely.
Result ordering and coherence — presenting results in a meaningful sequence rather than the order they happened to appear in the uploaded PDF — requires understanding relationships between documents that are only visible when looking across the whole batch. Grouping related documents (all invoices from the same supplier, all letters from the same authority) is a batch-level operation.
Processing time and progress feedback — a 5-page document processes in seconds; a 200-page document takes longer, and the relationship is not strictly linear because some processing steps have fixed overhead per batch rather than per page. The progress bar during processing is a live readout of actual position in the document, not an estimate based on expected duration.
Practical implications for large uploads
For users uploading large batches, a few things follow from the above:
Scan quality matters more at scale. A slightly suboptimal scan that produces acceptable results on a 10-page document will produce more errors across a 200-page batch simply because the error rate compounds across more documents. Flat, well-lit scans consistently outperform angled or poorly lit ones.
The confidence score column in the results table is more useful for large batches than small ones. For 10 documents, reviewing all of them is feasible. For 200, sorting by confidence ascending and reviewing the bottom 15–20 is the efficient path.
The results are a starting point, not a final answer. Batch processing handles the volume problem — producing a structured, searchable catalogue of what is in a pile of documents — so that human judgment goes to the right places. It does not replace that judgment; it focuses it.
For most users, the practical workflow is: upload a well-scanned PDF, review the low-confidence entries, download the spreadsheet and ZIP, and use the spreadsheet as the index for your document archive. That workflow scales from 10 pages to several hundred without changing in kind — only in the time it takes.