Skip to content
Zarif Automates

Parse, Extract, Classify, Split: Which One You Need

ZarifZarif
Published Updated

Most document AI projects need one of four operations, and it's easy to start with the wrong one:

  • Parse turns a page into text a program can read.
  • Extract pulls out the specific fields you ask for, like the invoice number and total.
  • Classify says what kind of document it is.
  • Split cuts a file that holds several documents into separate ones.

This is part 2 of the Document AI series. It runs one made-up invoice through all four so you can see what each one hands back. Every sample output below was written for this article to show the shape of the data. None of it came from running a real tool.

The document: one synthetic invoice

The same invoice shows up again in parts 4 and 5 of the series, so here are its details once. Harbor Lane Supplies and Example Manufacturing are invented companies.

FieldValue on the page
VendorHarbor Lane Supplies LLC
Bill toExample Manufacturing Inc.
Invoice numberHLS-2026-0417
Invoice dateSeptember 1, 2026
Terms and due dateNet 30, due October 1, 2026
Purchase orderPO-88231
Line 1Nitrile gloves, box of 100, 20 at $12.50 = $250.00
Line 2Safety glasses, 30 at $8.00 = $240.00
Line 3Shop towels, case, 10 at $41.80 = $418.00
Subtotal, tax, total$908.00, sales tax 8.25% $74.91, total due $982.91 USD

Page 1 has the header, the line items, and the totals. Page 2 has payment instructions and terms. The math on the invoice is correct on purpose, so any mismatch you see later is the extractor's mistake, not the document's.

Parse: what is on the page, in reading order

Parsing turns the document into text a program or a model can read, with the layout kept. You get markdown or HTML for the whole document, plus a list of blocks (a heading, a table, a paragraph) and where each one sits on the page.

An illustrative parse of page 1 looks like this:

# INVOICE
Harbor Lane Supplies LLC

| Invoice # | Date | PO |
| --- | --- | --- |
| HLS-2026-0417 | 09/01/2026 | PO-88231 |

| Description | Qty | Unit price | Amount |
| --- | --- | --- | --- |
| Nitrile gloves, box of 100 | 20 | 12.50 | 250.00 |
| Safety glasses | 30 | 8.00 | 240.00 |
| Shop towels, case | 10 | 41.80 | 418.00 |

Subtotal 908.00
Sales tax (8.25%) 74.91
Total due USD 982.91

Notice what parsing doesn't do. It doesn't tell you that 982.91 is the total due, or that 09/01/2026 means September 1 rather than January 9. It keeps what's on the page and leaves the meaning to the next step.

Use parse on its own when whoever reads the result, a model or a person, reads the whole document: a chat assistant looking things up, search, summaries, or an agent that needs the full context. The RAG agent guide starts right here. Extend's parse overview describes this output as markdown chunks that follow the page layout, alongside blocks with bounding boxes, the rectangles that mark where each block sits. Datalab's conversion docs recommend markdown for LLM and RAG pipelines and JSON when you need blocks and boxes.

Extract: the fields your system needs, in your shape

Extraction fills in a form you design. That form is called a schema. You list the fields, say what type each one is, and describe what it means. The service returns JSON that matches, ideally with a pointer to where on the page each value came from.

A minimal illustrative schema for the invoice:

{
  "type": "object",
  "properties": {
    "invoice_number": { "type": "string", "description": "Invoice number printed near the top" },
    "invoice_date": { "type": "string", "description": "Invoice date in YYYY-MM-DD" },
    "po_number": { "type": "string", "description": "Customer purchase order number" },
    "total_due": { "type": "number", "description": "Grand total due, after tax" },
    "currency": { "type": "string", "description": "ISO 4217 currency code" }
  },
  "required": ["invoice_number", "total_due"]
}

And the kind of output it returns:

{
  "invoice_number": "HLS-2026-0417",
  "invoice_date": "2026-09-01",
  "po_number": "PO-88231",
  "total_due": 982.91,
  "currency": "USD",
  "total_due_citations": ["block_14"]
}

That pointer, the citation field, follows the pattern Datalab documents in its extraction API, where each field gets a list of source block IDs. Extend returns the value and its metadata in separate objects instead, as part 4 shows.

Use extract when the result goes into the system your business treats as the official record: accounting software, a ledger, a CRM, a database row. The schema is a promise about the shape of the answer, the same idea as the prompt contracts lesson, and it's what you'll score in part 7.

Extraction almost always runs a parse first, behind the scenes. Extend's credit docs say parse runs automatically when extract, split, or classify is used, and bill both.

Classify: which kind of document this is

Classification puts the whole document into one category from a list you write. It returns the label, a confidence score, and usually a short reason. For an inbox of bills to pay, a sensible list is invoice, credit note, purchase order, statement, and other.

An illustrative result for the Harbor Lane file:

{
  "type": "invoice",
  "confidence": 0.97,
  "reasoning": "Page 1 is titled INVOICE, has an invoice number, line items, and a total due."
}

That confidence value is made up for the example. Real classifiers return their own scale. Extend's classification overview describes the returned type, confidence, and reasoning, and recommends giving every category a description plus an explicit "other".

Classification earns its place when different kinds of document need different handling. A credit note from Harbor Lane looks almost identical to an invoice, but it's money coming back to you. Run it through the invoice schema and you record a charge instead of a refund. Classify first, then pick the schema and the review rule for that type.

Split: where one document ends and the next begins

Splitting takes one file that holds several documents and tells you where each one starts and stops. Scanned batches are the classic case: someone feeds a stack of paper into a scanner and you get one PDF.

Suppose the Harbor Lane invoice arrives inside a seven-page scan called ap-batch-0917.pdf, with a credit note and an invoice from a second vendor behind it. An illustrative split result:

{
  "splits": [
    { "type": "invoice", "startPage": 1, "endPage": 2, "identifier": "HLS-2026-0417" },
    { "type": "credit_note", "startPage": 3, "endPage": 3, "identifier": "HLS-CN-0112" },
    { "type": "invoice", "startPage": 4, "endPage": 7, "identifier": "RV-55190" }
  ]
}

Pages are counted from 1 here, to match Extend's startPage and endPage names. Datalab's segmentation docs count pages from 0, so check which one your tool uses before you cut files apart.

Without the split, an extractor asked for one total due on this file has to guess which of three totals you meant. It will pick one, confidently. Splitting fixes that, and it comes before everything else.

The four operations side by side

OperationQuestion it answersOutputExtendDatalabGoogle Document AIAzure Document Intelligence
ParseWhat is on the page?Markdown or HTML, blocks with boxes/parse/convertLayout Parser, Enterprise OCRLayout model, Read
ExtractWhat are the values of my fields?JSON matching a schema, with citations/extract/extractCustom extractor, Invoice parserPrebuilt invoice, custom extraction
ClassifyWhat type of document is this?One label, confidence, reasoning/classifyNamed segments in /segmentCustom classifierCustom classification
SplitWhere does each document start and end?Page or block ranges with types/split/segmentCustom splitterCustom classification boundaries

Sources, all read September 26, 2026: Extend's agent context file, Datalab's documentation index, Google's Document AI overview, and Azure's pricing page, which says custom classification also identifies document boundaries in a multi-document file. Datalab's index lists no standalone classify endpoint on that date. Its segmentation endpoint accepts named segments with descriptions, which covers the same need inside a bundle.

The order to chain them in

For an inbox with all kinds of files in it, the order is split, then classify, then extract, with parse running underneath all three. Each step makes the next one's job smaller.

Most pipelines need fewer steps than that. If every file is a single invoice exported from a supplier portal, skip split and classify and go straight to extract. If the documents only go into a search index, parse is the whole job. Add a step when a real file in your sample needs it, not because a platform offers it.

Three mistakes to avoid:

  • Running extract when a model is going to read the whole document anyway. You throw away context the model could have used, and pay for a schema nobody reads.
  • Extracting from a bundle without splitting it. The extractor returns one believable set of values mixed from several documents.
  • Treating an extraction that came back as a correct one. The schema proves the answer has the right shape, not that it's true. Check that the line amounts add up to the subtotal and that subtotal plus tax equals the total, then send anything that fails to a person. Human-in-the-loop approval covers the pattern, and part 8 of this series applies it to documents.

Each of these operations is billed per page, and the charges stack. A split, a classify, and an extract on the same seven pages is three charges, plus the parse underneath. The document processing cost calculator shows what that means at your volume once human review is included.

Previous: Document AI now: from OCR to vision-language models. Next: Datalab in practice: Marker, Surya and Chandra, then the API.

Zarif Choudhury

Zarif Choudhury

Zarif builds AI agents and automation workflows. He writes about what keeps working once real people use it: who is worth reading, the new jobs AI is creating, and agent workflows you can check step by step.