In this guide
AI document classification identifies what a document is; PDF splitting identifies which pages belong to each document instance. A reliable intake workflow needs both answers before sending pages to an extractor or a business queue. Preserve the original bundle, review uncertain boundaries and keep a page-level record of every output.
This guide is for operations teams receiving mixed attachments and technical teams building document intake. It explains how to define classes, choose splitting behavior, validate page coverage and evaluate boundaries separately from labels. A downloadable reference pack includes a fictional nine-page bundle and a locally tested manifest validator. Examples in this guide use fictional documents and records.

A reliable intake keeps
- The original bundle
- A page-level record of every output
- Review of uncertain boundaries
Why a correctly labeled page can still reach the wrong workflow
An incoming PDF can contain a three-page invoice, a second invoice, a delivery receipt and a credit note. Labeling five pages “invoice” does not tell the application where the first invoice ends. Merging the two can combine line items, overwrite a reference or make totals appear inconsistent. Splitting each page separately can detach line items from the header they belong to.
There are three decisions: identify the class, identify the document instance and choose its permitted route. Evaluate them independently. A record can have the right class and the wrong boundary, or the right boundary and a route that exposes it to the wrong team.
The AI document-processing workflow covers extraction and field validation after intake. This article completes a different task: turning a composite file into an auditable set of logical documents without dropping pages or assuming that a class label proves identity.
Define classes around actions your team can support
A taxonomy is useful when a class changes what happens next. “Invoice,” “credit note” and “delivery receipt” can trigger different checks. “Other finance document” may be too vague to select a safe extractor. Conversely, dozens of supplier-specific classes create a maintenance burden if every class leads to the same action.
Write the inclusion rule, exclusion rule and next action for each class. Include confusing examples. An account statement can contain invoice references and totals without being a new invoice. A quotation may resemble an invoice but should not create a payable draft. A receipt for goods and a receipt confirming payment serve different purposes.
On smaller screens, scroll to compare all columns.
| Class | Distinguishing evidence | Permitted next step |
|---|---|---|
| Invoice | Document asserts an amount due for a stated transaction | Invoice extraction and independent AP checks |
| Credit note | Document identifies a credit or adjustment | Dedicated credit workflow; no ordinary positive-invoice assumption |
| Delivery receipt | Document records delivered goods or acknowledgment | Receipt review, with purchasing linkage where justified |
| Statement | Summary of account activity or balances | Reconciliation queue; no new invoice from each reference |
| Unknown / ambiguous | No supported class has adequate evidence | Human triage with source pages retained |
| Blank / separator | Page is intentionally recorded as non-substantive | Retain in the manifest; exclude from extraction only by explicit rule |
Separate model labels from application states. A classifier may only return one of its trained labels. Your application still needs an unresolved state when evidence is insufficient, a class is unsupported or downstream checks conflict. Do not force an unfamiliar document into the nearest known workflow just to avoid a queue.
How should you split a multi-document PDF?
If an approved intake channel guarantees one document per file, whole-file classification can be enough. Verify that assumption against actual arrivals. If every page is independently meaningful, a page-based route may be appropriate. For multipage forms and invoices, preserve logical document instances instead.
Microsoft’s custom-classifier documentation describes identifying multiple document types and repeated instances within one file. For the v4.0 API version 2024-11-30, the default splitMode is none; using auto explicitly enables splitting. Confirm the version and request behavior after each upgrade, since earlier defaults may change.
Google Document AI’s custom splitter predicts document classes and their constituent pages. Its documentation distinguishes that prediction from physically separating the PDF and recommends review because incorrect splits can damage multiple documents. Your implementation needs a defined step for materializing the approved page map.
Neither behavior establishes a universal accuracy level. Compare the output against your actual bundle patterns. Two consecutive invoices from the same supplier are a particularly useful test: their layout and class may be identical, while their document instances must remain separate.
On smaller screens, scroll to compare all columns.
| Input condition | Possible starting approach | Failure to test |
|---|---|---|
| One verified document per file | Whole-file classification | A sender merges several documents without changing the filename |
| Independent single-page records | Per-page classification | A continuation page needs the preceding header |
| Variable multipage bundles | Document-instance splitting and classification | Two adjacent instances of the same class are merged |
| Interleaved or reordered scans | Page-set review before extraction | Assuming every document is a contiguous range |
Keep the original bundle and create a page manifest
Preserve the exact received file with a stable intake ID, content hash and original page count. Treat a split as a versioned interpretation of that file. If a reviewer moves a page later, create a revised manifest and retain the previous decision.
Use explicit original page numbers, starting from a documented base. Many internal libraries use zero-based indexes while people read PDFs from page one. An off-by-one error can produce valid files containing the wrong pages. Convert at one named boundary and test the first and last page.
{
"bundle_id": "BUNDLE-DEMO-001",
"manifest_version": 1,
"page_count": 9,
"documents": [
{"id": "INV-A", "class": "invoice", "pages": [1, 2, 3]},
{"id": "INV-B", "class": "invoice", "pages": [4, 5]},
{"id": "REC-A", "class": "delivery_receipt", "pages": [6]},
{"id": "CR-A", "class": "credit_note", "pages": [7]},
{"id": "UNKNOWN-A", "class": "unknown", "pages": [8]},
{"id": "BLANK-A", "class": "blank", "pages": [9]}
]
}This record format is defined by your application. A production manifest also needs the source hash, classifier version, decision evidence, review state and destination permissions. Use page arrays if your scope can contain noncontiguous pages; do not imply that a simple first/last range represents an interleaved document correctly.
Validate structural coverage before trusting semantic decisions
For a simple partitioning workflow, require every original page to appear exactly once, including pages retained as blank or unknown. Reject negative, zero, non-integer and out-of-range numbers. Reject empty document instances and duplicate instance IDs. These checks detect structural defects even when the class prediction looks plausible.
Some specialized workflows intentionally reuse a shared appendix. If you need that, define an explicit relationship and keep the uniqueness check in place. Record one owned source page and references from the dependent documents. The downloadable validator intentionally implements the simpler one-owner-per-page contract.
A manifest can pass all structural checks and still be semantically wrong. Combining pages 1 to 5 into one invoice uses every page exactly once, but merges two real instances in the example. That is why a coverage validator is necessary and insufficient.
Walk through the nine-page bundle
Pages 1 to 3 are invoice A, with the header on page 1 and continuation lines on pages 2 and 3. Pages 4 and 5 are invoice B from the same supplier. Page 6 is a delivery receipt, page 7 a credit note, page 8 an unrecognized letter and page 9 a blank separator.
The correct proposed output is six retained instances, four eligible for their defined specialist review paths and two held outside extraction. Do not describe this as six successfully extracted documents. The unknown letter still needs triage, and the blank page still needs an explicit disposition.
Now consider a candidate that merges pages 1 to 5. Its page classes can all be correct: five invoice pages remain labeled invoice. Yet the invoice-instance count falls from two to one. A downstream extractor may return one header and a combined table, creating a record that never existed in the source.
The repair is to inspect the boundary between pages 3 and 4. Look for independent reference changes, new headers and continuation evidence. These are review cues; none is a universal separator. A repeated header can occur on every page of one invoice.
How do you measure classification and splitting accuracy?
Build an independently labeled evaluation set containing real bundle patterns you are authorized to use. Keep it separate from training and rule tuning. Include adjacent same-class documents, continuation pages, separators, unfamiliar classes, scans, different languages where in scope and genuine partial or reordered arrivals.
Use a stable version of the class definitions. Two labelers can disagree because the taxonomy itself is unclear. Resolve disagreements before using those examples as reference truth, and retain ambiguous cases with their reason.
On smaller screens, scroll to compare all columns.
| Measure | Definition to freeze | What it can miss |
|---|---|---|
| Page-class correctness | Correctly classified original pages / all labeled pages in the cohort | Correct labels with merged document instances |
| Boundary precision and recall | Correct predicted document breaks / predicted breaks; correct breaks / reference breaks | Wrong class labels or incorrect ordering inside an instance |
| Exact instance match | Predicted instances with the right class and complete page set | Whether the destination has correct permissions and receipt |
| Bundle integrity | Bundles with every page accounted for under the manifest contract | Semantically wrong merges that still cover every page |
| Incorrect automatic routing | Materially misrouted instances / all instances the proposed rule would route automatically | Held work and reviewer capacity |
| Review effort and delay | Active review minutes and elapsed queue time, separately | Correctness unless decisions are also inspected |
For the example bundle, the reference breaks after pages 3, 5, 6, 7 and 8. A candidate that merges the invoices predicts breaks only after 5, 6, 7 and 8. All four predicted breaks are correct, so boundary precision is 4 / 4 = 100%, but recall is 4 / 5 = 80%. Four of six reference instances match exactly; all nine page labels can still be right. These calculations illustrate a failure mode.
Google’s evaluation documentation explains precision, recall and threshold-dependent predictions for its processors. For your application, retain the exact matching definition and supplement provider metrics with page-set and routing checks. A vendor F1 score does not automatically measure your complete intake workflow.
Do not select a threshold on the same documents used to claim final performance. Compare candidate thresholds on a tuning set, freeze the chosen rule and inspect a separate evaluation set. When a provider returns no confidence score, show that state visibly. An LLM’s invented percentage is not a substitute for a provider score or labeled error analysis.
Review the boundary with enough context
Show a reviewer the last page of the proposed document and the first page of the next one, with nearby continuation pages available. Display the original page numbers and proposed instance IDs. A page thumbnail without readable text may hide the invoice reference that changes the decision.
Let the reviewer move pages, merge or split instances, change a class and mark an item unresolved. Save the resulting manifest version. If an extracted record already exists, invalidate or hold the affected downstream result before reprocessing. Avoid silently making the stored source link point to a different set of pages.
Preserve source permissions when creating derivative files and routes. A mixed bundle can contain material intended for different teams. A shared invoice queue should not automatically receive the unknown page because it was attached beside an invoice. Use the workflow permissions and guardrails guide for the action boundary; use the RAG architecture guide if the destination is a searchable document library.
Use the reference pack to test the contract
Download the classification and split-manifest reference pack (ZIP). It contains an editable class-policy CSV, the fictional nine-page reference, a merged-invoice candidate, a Python validator and evaluation script, expected results and instructions. It contains no real invoice files or personal data.
Local checks exercise complete coverage, duplicate pages, missing pages, out-of-range values, unsupported classes, empty instances, duplicate IDs and the merged-invoice example. The evaluator compares class plus page sets and boundary counts. It does not read PDFs, classify text or demonstrate a cloud model’s accuracy.
Run the script, then remove page 9 from the manifest. Structural validation should fail even though the missing page was labeled blank. Restore it and merge the two invoice instances: validation should pass while exact-instance evaluation worsens. That difference is the core lesson to preserve in a production acceptance test.
Move from a trial to an operating intake process
Start with reviewed page maps in shadow mode. Keep the source bundle available, inspect every proposed automatic route and record how corrections affect downstream extraction. Set scope-specific acceptance criteria with the process owner before collecting success numbers. This guide supplies no universal accuracy threshold or minimum sample size.
Track unknown classes and boundary corrections by source pattern. Repeatedly splitting one supplier’s continuation pages can suggest a missing training pattern; a sudden new class can require a taxonomy decision. Re-evaluate after model, class-policy, input or routing changes. Preserve a previous version so a model update can be compared before replacing it.
Define the completion receipt: approved manifest, verified derivative page sets, permitted destination and confirmed handoff. A completed classification API call is only an intermediate result. If handoff times out, inspect the destination before replaying the create operation.
For an invoice destination, continue with the AI invoice-processing guide. For an implementation discussion, bring representative authorized bundles, the class policy, page ownership rules, destination permissions and review owners to AGI Technologies’ document and image processing service. Request a quote for a bounded intake pilot.
Sources: the classifier, splitter and evaluation documentation linked above, as of 13 October 2026.
Reviewed by Andrii Gorbenko, founder of AGI Technologies

