A two-hundred-page client scan splits into the wrong number of documents

Reconcile counts before you look at the splitter. A 200-page batch that should have produced 63 documents and produced 58 has under-split by 5 boundaries; the same batch producing 71 has over-split by 8. Those two faults have different causes, different costs and different fixes, and the difference is invisible in any accuracy figure computed over the whole batch — because the error rate is not uniform across document types, it is concentrated in 2 or 3 of them.

The failure usually gets logged as a multi page PDF splitting document classification error, which quietly conflates two separate questions: where the boundary was drawn, and what the resulting document was called. Only the second is a classifier problem. A perfectly trained classifier handed a document containing the last page of one invoice and the first 2 pages of another has already lost, and no amount of retraining recovers it.

Count what went in against what came out, sliced by type

1. Get a physical count at capture. Whoever feeds the scanner writes the document count on the batch sheet, or the portal records 1 upload per document. Without a number from the input side, every check downstream is comparing your output against your own output.
2. Compare emitted documents to that count for the batch as a whole. A match proves nothing on its own — 1 merge and 1 split cancel out — but a mismatch is definitive and free.
3. Sample 30 documents per type and mark each as correct, merged or fragmented. Type here means the thing that determines page structure: single-page receipt, multi-page invoice, monthly statement, multi-page form, covering letter.
4. Score each type separately and never blend. A batch at 94% overall can be 99% on receipts, which are most of the volume, and 61% on multi-page invoices, which are most of the value. The same arithmetic that hides locale faults behind a low overall error rate hides this.
5. Split the failures into over and under. Record which, because the two point at opposite adjustments and a single boundary accuracy number cannot tell you which direction to move.

Over-splitting is loud, under-splitting is silent

Tune for under-splitting, not for accuracy. An over-split document announces itself: it has no header, no supplier, no total, and it fails every completeness check you already run. An under-split document looks entirely normal, extracts the first page's supplier and the last page's total, and the document that vanished inside it is not in any queue because nothing knows it existed.

Five places the boundary gets guessed wrong

• Multi-page documents with no page-of-n marking. A 3-page invoice whose pages 2 and 3 carry only line items and a footer gives the splitter no positive evidence of continuation. Many suppliers print page numbers on page 1 only, which is the worst possible arrangement.
• Continuation pages that repeat the header. The opposite fault: a supplier that reprints its logo, address and invoice number on every page hands the splitter what looks like the start of a new document, 3 pages in a row.
• Duplex scans with blank versos. Blank-page detection uses an ink-coverage threshold, and a faint bleed-through, a scanner artefact or a stray staple shadow puts a blank page over it. Drop a verso that was not blank and the boundary moves by 1 page; keep a blank that should have gone and a document acquires a page that belongs to nothing.
• Stapled bundles that are physically 1 document and logically 3. A remittance advice, the invoice it pays and a delivery note travel together, and a person scanning them sees 1 item. Whether they should be 1 document or 3 is a policy decision, and until somebody makes it, the count reconciliation has no defined right answer.
• Runs of near-identical documents. 12 monthly statements from the same account, or 20 invoices from the same supplier on the same template, defeat every layout-similarity signal at once — consecutive pages look alike precisely because they are alike, which is the signal the splitter was relying on.

Separator sheets are unglamorous and still the cheapest answer

A separator sheet moves the boundary decision from a model that is inferring it to a person who already knows it. The mechanism is old and reliable: a printed sheet carrying a barcode, commonly Code 128 or a QR code, or a patch-code pattern the scanner driver recognises, placed between documents by whoever is loading the feeder. The sheet is detected, the boundary is certain, and the sheet is discarded from the output.

Do the arithmetic before dismissing it as manual work. Placing a sheet takes about 3 seconds per document; finding and repairing 1 merged document later takes a reviewer several minutes, and that assumes it is noticed at all. At 60 documents in a batch, separation costs roughly 3 minutes of somebody's hands. One undetected merge that reaches the ledger costs more than that in a single query. Where the scanner supports it, per-document scanning — one press per document — removes the boundary problem outright and is faster than sheets for small batches.

Every boundary a person knows and does not record is a boundary a model has to guess, and the guess is made where the evidence is thinnest.

The durable fix sits where the pages are produced

Splitting is a recovery operation. It reconstructs information that existed at capture and was thrown away, which is why the returns on a better splitter fall off quickly while the returns on better capture do not. The practical moves are unglamorous: a portal that accepts 1 document per upload rather than 1 file per month, a mobile capture flow that ends a document explicitly, a scanner profile per client that matches how that client's paperwork actually arrives, and a standing request that clients send bank statements as separate downloads rather than 1 merged file.

Where the pages cannot be controlled — a client who will always send a 200-page scan — the answer is a review step designed for boundaries specifically, not a general document review. A reviewer shown page thumbnails with proposed breaks, who can drag a break 1 page either way, will correct a batch in a fraction of the time it takes to open and re-file documents one at a time. That is a small, specific interface, and building it is the sort of scoped AI agents and automation work that pays for itself in one filing season.

What a better splitter will not fix

A merged document does not fail loudly; it fails in the numbers. An invoice that absorbed the first page of the next invoice extracts a plausible supplier, a plausible date and a total that does not agree with its own line items — which is exactly the arithmetic fault described in line items that do not sum to the invoice total. A statement split mid-period fails balance continuity, which is why a statement-to-transactions pipeline that gates itself catches boundary damage that no splitting metric reports.

The under-split document has a worse ending. A purchase invoice that was never emitted as its own document is a purchase that was never recorded, and nothing downstream can miss what it never saw. On a tax return that turns up as a claim that does not agree with the counterparty's record — the shape of an input credit mismatch between the books and the portal, discovered late and reconciled by hand.

This is also the right question to put to any vendor demonstrating document intake. A clean 20-page batch of distinct layouts splits perfectly for everyone. Ask for the boundary error rate on 200 pages of your own worst client's paperwork, broken down by document type, and ask what the system does when it is unsure — the same evidence-over-claims test that applies to choosing an AI development partner generally. The rest of this sits in extraction and classification of source documents, part of the accounting and tax systems we build.

• document intake
• batch scanning
• document boundaries
• capture