A Stack View of the Document Processing Market

“AI document processing” is a vast product category. It encompasses enterprise content platforms,¹ hyperscaler APIs,²^,3^,4 frontier parsing services,⁵^,6 open-source converters,⁷^,8 OCR baselines,⁹ web-capture tools,¹⁰ review queues,¹¹ and full workflow systems.¹² The definition hides a chain of traceable transformations, from governed record to machine representation, reviewed claim and operational action.

The products examined here tackle document processing with varying concerns. The useful map follows five responsibility boundaries, covering custody of the record, representation of the page, orchestration of document work, review of proposed outputs and action in the operational system.

Criteria cut across markets

Criterion	Layer	Responsibility
Record control	Layer 1: custody	Accept, identify, permission, version, retain and audit the source record.
Provenance	Layer 1: custody	Keep each derivative, field and decision attached to source, process and time.
Layout fidelity	Layer 2: representation	Preserve page structure needed for extraction and review.
Structured extraction	Layer 2: representation	Turn recognised content into fields with schemas, confidence and locations.
Agent-readable output	Layer 2: representation	Produce a derivative an agent can read without losing needed structure.
Document-work state	Layer 3: orchestration	Route files, tools, parser choices, tasks and intermediate outputs.
Meaningful oversight	Layer 4: review	Give uncertain or policy-sensitive claims a competent authorised reviewer.
Operational commitment	Layer 5: action	Write approved results into cases, ledgers, alerts, ERP or BI.

The table groups criteria by stack responsibility.

These boundaries cut across recognised product categories. An ECM or DMS can own the record and route the work, while saying little about how a table cell turned into a field. A cloud document API can return polygons, spans and confidence, while staying reticent about which version is authoritative. A converter can give the agent readable Markdown and lose the page geometry a reviewer later needs. A workflow, RPA or agent runtime can manage tools and tasks without institutional authority to accept the extracted value.

Document-processing practice already treats the work as a pipeline,¹³ with IDP material separating capture, classification, extraction, validation and downstream integration¹⁴ while BPM and RPA vocabularies place the same work inside managed business processes.¹⁵ Model inference is one operation in that system.

The stack we discuss in this article is a record-to-action responsibility model in which:

custody keeps the source accountable
representation makes it machine-readable
orchestration turns document operations into managed work
review gives selected outputs institutional standing
finally, action commits accepted outputs into the systems where the institution continues the process

Layer 1: Custody

DMS custody and workflow

Custody comes first, as every later layer points back to a source that can be archived, identified and referenced. The authoritative record may live in a DMS, ECM platform, records system, case system or line-of-business system.¹⁶

We can refer to Doxis as a worked example. In Q1/2026, SER Group renamed the company after its platform, repositioned it as “The Document Intelligence Company” and installed the co-founder and CEO of the document-processing vendor it had acquired the previous year as Chief AI Officer.¹⁷ The move already shows an established document-management vendor bringing document management and document AI into the same commercial stack.

Doxis describes lifecycle management from intake to archive, routing into digital workflows and third-party systems, compliance tracking, ERP and CRM integrations, and platform certifications for security and compliance.¹⁸ Its no-code application layer lets users build workflow applications on top of the record system, so the same offering covers governance, review routing, files, users, roles, retention rules and process state.

Doxis decomposes automated text capture into capture from email, scanner and portal, classification for document type and routing, extraction of fields with or without a predefined schema, and validation for formal accuracy, duplicates and missing required details.¹⁹ The acquired layer adds conversion to structured formats, anonymisation, verification against trusted sources, fraud detection and human-in-the-loop review.²⁰

The integration point is the transaction system around the record. Doxis offers business connectors for ERP, accounting, CRM and HR systems,²¹ vendor-specific SAP, Microsoft and Salesforce interfaces,²² and a universal ERP connector that can pass extracted invoice data into an ERP workflow.²³ Those connectors sit at the boundary between custody and execution, letting the DMS keep the approved document record while SAP, Salesforce or another line-of-business system receives the data it needs to continue the process.

Web intake as custody work

Not all sources come as files, since a policy page, institutional FAQ, public regulation or vendor manual may enter the workflow through a URL. Modern agentic workflows may choose a representation at access time, with Markdown, HTML, JSON, links and status fields preserving different classes of evidence.

Legal scholarship treats URL evidence as an archive problem by separating link rot from reference rot. Reference rot names the case where a URL still resolves but no longer contains the cited material, and the essay treats page capture at citation time as the remedy.²⁴ Administrative workflows need the same separation between the URL that identifies where the source was found and the captured snapshot that can be reviewed later.

Layer 2: Representation

Provenance carries custody forward when the source record becomes a representation, keeping the new work surface attached to the record, route and process that produced it.²⁵ A working system needs to preserve identity, page location, confidence, approval state and custody while the file changes shape. A derivative is the agent-readable representation generated from a record, usually Markdown, JSON, HTML, or another structured document format. It corresponds to the practical family of renditions, extracted representations and representation information, but it is narrower because the agent and reviewer need an inspectable work surface.²⁶ The agent usually works on the derivative, while the canonical file remains the governed source. The derivative gives the model a readable surface with enough structure for reasoning and enough provenance for review.

Cloud APIs expose page mechanics

A hyperscaler API is a hosted document-analysis service from a large public cloud provider, such as Microsoft Azure, Google Cloud or AWS. Page mechanics are the concrete facts this layer returns, giving the surrounding system both an input contract and an evidence model. The input contract says which source files and output formats the service supports, while the evidence model ties extracted content back to page structure so a DMS or prototype run record can attach a derivative to the right source page or route a difficult page to another parser.

Azure AI Document Intelligence covers a wide intake and output surface, accepting PDF, images, Office formats and HTML and returning either JSON with page polygons and character spans or Markdown through a documented output mode.²⁷

// Azure layout response sketch
{
  "status": "succeeded",
  "analyzeResult": {
    "apiVersion": "2024-11-30",
    "modelId": "prebuilt-layout",
    "stringIndexType": "textElements",
    "content": "Payment due\nEUR 184.20",
    "pages": [
      {
        "pageNumber": 1,
        "width": 8.5,
        "height": 11,
        "unit": "inch",
        "words": [
          {
            "content": "184.20",
            "polygon": [4.12, 6.38, 4.78, 6.38, 4.78, 6.55, 4.12, 6.55],
            "confidence": 0.997,
            "span": { "offset": 16, "length": 6 }
          }
        ]
      }
    ],
    "paragraphs": [
      {
        "role": "sectionHeading",
        "content": "Payment due",
        "boundingRegions": [
          { "pageNumber": 1, "polygon": [0.92, 5.8, 2.1, 5.8, 2.1, 6.0, 0.92, 6.0] }
        ],
        "spans": [{ "offset": 0, "length": 11 }]
      }
    ]
  }
}

Azure output ties text spans to page geometry.

When plain Markdown lacks a way to express tables with merged cells or multi-row headers, the service embeds HTML tables and can also mark paragraph roles, section nesting and handwriting spans with confidence. A workflow can stay on this route when embedded text is enough, while embedded Office images or workbook-level spreadsheet logic need another route.

Google Document AI is organised around processors, meaning configured parser or extractor endpoints. The relevant examples are processor families, where a form parser extracts key-value pairs, tables and checkboxes without a schema, a layout parser produces structure-aware chunks, and custom extractors take a developer-defined schema that can run through a generative foundation model, a trained custom model or a fixed template.

// Google processor object sketch
{
  "type": "CUSTOM_EXTRACTION_PROCESSOR",
  "displayName": "travel-expense-invoices",
  "name": "projects/123456/locations/eu/processors/a1b2c3d4e5f6",
  "state": "ENABLED",
  "processEndpoint": "https://eu-documentai.googleapis.com/v1/projects/123456/locations/eu/processors/a1b2c3d4e5f6:process",
  "defaultProcessorVersion": "projects/123456/locations/eu/processors/a1b2c3d4e5f6/processorVersions/pretrained"
}

A processor object gives the endpoint and version behind a configured extractor.

The planning parameter is the amount of labelled data each route expects. Google’s own table puts production quality at three documents for fixed templates, 10-100+ documents for custom models, and 0-50+ documents for foundation-model extraction depending on layout variation.²⁸ That determines whether an administrative prototype can begin with a few sample forms or needs time for a preliminary labelling project.

Amazon Textract is especially explicit about page geometry in this group, with a narrower input and output surface. Its analysis response returns text, forms, tables, queries, signatures and layout as blocks, and each block can carry page number, bounding box, confidence and relationships to other blocks.²⁹ Queries answer developer-supplied questions with answer blocks, while adapters customise those query responses after the team uploads representative documents, annotates query answers and trains the adapter.³⁰

// Textract query request sketch
{
  "Document": {
    "S3Object": {
      "Bucket": "expense-intake",
      "Name": "receipt-page-1.png"
    }
  },
  "FeatureTypes": ["TABLES", "FORMS", "QUERIES", "LAYOUT"],
  "QueriesConfig": {
    "Queries": [
      {
        "Text": "What is the reimbursable total?",
        "Alias": "reimbursable_total",
        "Pages": ["1"]
      },
      {
        "Text": "What is the invoice date?",
        "Alias": "invoice_date",
        "Pages": ["1"]
      }
    ]
  }
}

Textract queries turn business questions into named answer fields.

Mistral Document AI sits closer to representation than to custody or review. Its primary output is a readable derivative of the page, with structure and hierarchy preserved in Markdown. Tables can arrive inline or as separate Markdown or HTML objects, and confidence is available at page or word granularity under a wide language-coverage claim.³¹ That shape works when the output immediately goes to a language model. It is weaker when the next consumer is a database field that later has to be checked against the source pixel. A word-level confidence score on generated Markdown gives the reviewer less location evidence than a polygon on the original page.

// Mistral OCR derivative sketch
{
  "pages": [
    {
      "index": 0,
      "markdown": "# Receipt\n\nTotal due [tbl-0.html]\n\n![img-0.jpeg](img-0.jpeg)",
      "tables": [
        "<table><tr><th>Total</th><td>EUR 184.20</td></tr></table>"
      ],
      "images": [
        {
          "id": "img-0.jpeg",
          "top_left_x": 118,
          "top_left_y": 220,
          "bottom_right_x": 412,
          "bottom_right_y": 540,
          "image_base64": "..."
        }
      ],
      "dimensions": {
        "dpi": 200,
        "height": 2200,
        "width": 1700
      },
      "confidence_scores": {
        "average_page_confidence_score": 0.982,
        "minimum_page_confidence_score": 0.91,
        "word_confidence_scores": [
          { "word": "Total", "confidence": 0.99 },
          { "word": "184.20", "confidence": 0.96 }
        ]
      }
    }
  ],
  "model": "mistral-ocr-latest",
  "usage_info": {
    "pages_processed": 1
  }
}

Mistral centres the derivative on Markdown, extracted tables and image metadata.

The model-side literature explains why page mechanics remain necessary even when the parser is a vision-language model. OCR-first pipelines can lose layout and reading-order information before the model sees the page.³² Model-native readers remove the separate OCR step, but long documents still stress context windows, and small layout changes can change what the model reads.³³ Newer OCR systems keep structure explicit by detecting layout and reading order first, then recognising content inside page regions.³⁴ Difficult pages push page mechanics inside the model pipeline before extraction.

Hard-tail parsing

Cloud APIs handle ordinary page description, but the hard tail starts when a page needs more than text, tables and coordinates from a general layout API. Dense tables, charts, handwriting, nested sections and mixed scans are common in administrative work, and a few such pages can collapse the pipeline.

The ParseBench comparison makes the hard-tail problem visible at the level of the model by testing whether parsers preserve source text, keep reading order and avoid omissions or hallucinations on enterprise pages.³⁵ In the published benchmarks, extra VLM capability and compute produced only marginal gains on the parsing metrics. Parser quality is better measured on document-parsing tasks³⁶ than inferred from the model’s general rank.³⁷

LlamaCloud decomposes the product surface into Parse, Extract, Classify, Split, Sheets and Index, mapping those products to LLM-ready text, schema-shaped JSON, document categories, concatenated-document separation, spreadsheet-like data and hosted vector search.³⁸ The managed service acts as an escalation route for pages where the baseline API loses layout or visual structure. Parser products are becoming tools inside document-oriented agents, where file access, tool calls, task state and review surfaces matter as much as the OCR step.³⁹

Document-ETL research reaches the same result by treating the whole processing pipeline as an object of optimisation. Complex document tasks improve when the pipeline rewrites the task, decomposes the data and evaluates candidate plans before execution.⁴⁰ Parsing touches orchestration because the pipeline chooses the representation, routes page regions that need specialist handling and passes only acceptable results to extraction.

Open converters and local baselines

A converter turns the source file into a derivative that the rest of the stack can consume. A quick converter helps when the first goal is to make a large source set readable, while a structured parser is necessary when tables, reading order and layout objects will later be inspected. Research systems that construct knowledge from heterogeneous documents follow this split by separating layout, metadata and semantic layers, with human review deciding which extracted relations survive.⁴¹

MarkItDown optimises for LLM-readable text over high-fidelity rendering.⁴² It converts a wide intake range, from Office and PDF to images, HTML and archives, while preserving headings, lists, tables and links where it can. Scanned pages use a vision-model plugin, and Azure AI Document Intelligence supplies the cloud escalation path, which makes its value early corpus access. A team can turn mixed files into rough Markdown quickly enough to inspect, search and prototype over them, then reserve structured parsing for the files whose tables, reading order or provenance need inspection.

Docling is the structured parser in this group, parsing each input into a unified document representation and exporting Markdown, HTML, structured text or lossless JSON.⁴³ It operates a distinction in which Markdown helps the agent read while lossless JSON records the parser’s objects, so a pipeline that stores both can answer later questions about a table cell or reading-order decision that a Markdown-only pipeline usually loses.

OCRmyPDF and Tesseract define the local OCR baseline, with OCRmyPDF wrapping Tesseract to add a searchable OCR text layer to scanned PDFs, locally and deterministically.⁴⁴ The baseline works for clean printed scans because it produces repeatable searchable PDFs, but it is the wrong tool for complex layout, tables and handwriting. It gives the pipeline a cheap first pass and the evaluator a control row for downstream paid layers.

The deterministic baseline has also gained a model-native neighbour, Surya, an open-source OCR toolkit that installs from the package index and can run through local inference backends.⁴⁵ A local fast tier can now add model-native OCR before it reaches a cloud API.

LiteParse extends the local tier from OCR into parsing by giving a pipeline a first-pass parser that can run locally while failed pages escalate to LlamaCloud or another frontier parser.⁴⁶ The local baseline can include parser logic as well as OCR, with managed escalation reserved for pages that fail the local pass.

The remaining tools are specialised use cases around representation. Apache Tika belongs at intake, where email attachments and legacy repositories arrive in many formats and file type, text and metadata extraction matter across more than a thousand formats.⁴⁷ GROBID belongs to scholarly PDFs, where PDF-to-TEI, references and citation links are the needed derivative,⁴⁸ while Pandoc belongs at publication, turning approved Markdown back into DOCX or PDF for circulation.⁴⁹ These tools cover boundary cases around the representation layer and leave layout-aware extraction to a dedicated parser.

Layer 3: Document-work orchestration

Orchestration is the work layer between document representation and institutional review. It maps to BPM, workflow and RPA practice more closely than to a standalone document market label.⁵⁰ It decides which tool receives a file, where intermediate derivatives are stored, which source version the model can see, how long a task may run, and which output becomes a review object. These interfaces define a document-oriented agent as much as the model does. One implementation describes document processing as tool calling over a virtual filesystem, structured generation, task loops, parsing, extraction, classification and an asynchronous user interface for long document workflows.⁵¹

The orchestration layer becomes dangerous when it treats working files as authoritative records, or when an autonomous agent can write, delete or transform sources without a bounded custody relation. A safe orchestration layer gives the agent a controlled copy, records the route it chose and returns proposed fields or derivatives to the system that owns the record.

LlamaIndex and LlamaCloud span adjacent layers because they sell both representation and orchestration. LlamaParse, LlamaExtract and LlamaClassify produce document-understanding outputs, while LlamaIndex workflows and agent loops run the surrounding work. The sampled product movement runs from isolated parsing calls to managed document work, with VLM parsing as one component.

Layer 4: Review

Review is where a proposed field becomes an institutionally accepted value. IDP material often calls this validation,⁵² ABBYY calls the same step human-in-the-loop verification,⁵³ and Amazon Augmented AI packages it as a human-review workflow around Textract.⁵⁴ The parser supplies candidate evidence, while the review layer records the outcome under the governing source version.

Validation workbenches

Validation products make the review role into a concrete system interface. Rossum sends empty fields and low-confidence fields into a validation stage and points the reviewer to the relevant document area,⁵⁵ while ABBYY Vantage treats human-in-the-loop review as the step used when validation rules fail or when a document class and extracted data need manual correction, tying those corrections to continuous learning and straight-through-processing analytics.⁵⁶ Instabase turns failed validations from a deployment into review tasks by file, run or packet, with queues, escalation groups and service-level targets.⁵⁷

Validation is packaged as an exception workbench, where the reviewer typically receives a queue, a document viewer, a field editor, validation rules, assignment and a return path into downstream systems. The review layer should be evaluated through work objects as much as through extraction metrics. The ergonomics test here is whether a low-confidence field becomes a traceable task with a source location, reviewer, decision and replayable output.

Oversight is stricter than validation

Human oversight literature argues that review can fail when the reviewer lacks competence, authority or epistemic access,⁵⁸ or when incentives make the human reviewer a weak check on the automated system.⁵⁹ In document processing, the reviewer needs enough source evidence to understand the proposed value, enough authority to correct or reject it, and enough system support for the correction to change the maintained record.

Dense extraction products already expose the auditability primitives that review needs. Page attribution, bounding boxes, no dropped outputs and calibrated confidence scores make a proposed field reviewable,⁶⁰ but those signals are still only prerequisites. They route work to a reviewer and help the reviewer inspect it, while correctness and oversight come from the review decision.

The review layer has two jobs, turning uncertainty into work for a competent reviewer and recording the resulting decision as part of the case. A validation UI that only edits text fields belongs to the first job, while a review system that stores the reviewer, source region, policy basis, correction and downstream effect begins to satisfy the second.

Layer 5: Operational action

The last layer is where accepted document claims become operational state. An approved reimbursement amount enters ERP, a verified claim enters a case system, a classified contract enters a retention schedule and a confirmed supplier change enters a master-data workflow. This layer is outside parsing, but it belongs inside the buying problem because IDP and automation products are commonly justified by reduced rekeying, faster processing and integration with ERP, CRM, case or analytics systems.⁶¹

The operational sink is where stack promises become measurable, since a parser can be excellent and still leave the organisation with manual rekeying, a review queue can be polished and still fail if corrections never update the case record or downstream analytics, and a DMS can hold the record while leaving the extracted value stranded. As a final test, we want to consider whether the accepted output reaches the system that acts on it, with provenance still attached.

A sample implementation

A travel-expense workflow shows a full stack traversal at a small scale. The DMS owns the case, evidence, policy version and approval trail. The agentic workflow reads controlled derivatives, routes each source to a parser, creates field records, sends unsafe fields to review and writes the approved result back to the case and ERP.

This sample implementation uses an arbitrary DMS for custody, LlamaIndex for orchestration, LiteParse for the local parser route, LlamaParse for the escalation parser route, Apache Tika for uncertain intake metadata, DMS-attached derivative storage, a finance review queue and an ERP connector for the approved reimbursement payload. The practical target in this case is low-cost provenance and acceptance state.

The workflow keeps three source classes, with the case, the evidence and the governing policy separated from the start. In this simple model, the hotel invoice and ticket screenshot are ordinary evidence, the receipt photo is the escalation candidate and the travel-expense policy is versioned governing material.

Evidence enters through ordinary administrative channels, usually an email attachment or self-service portal upload. The DMS creates the case record, while the intake edge may still receive forwarded messages, screenshots, zipped attachments or files with weak MIME metadata. Apache Tika may be used at that edge, before parsing, where file type and attachment metadata have to be established before routing.

// Workflow record types
type WorkflowCase = {
  caseId: string
  dmsRecordId: string
  employeeId: string
  policyRecordId: string
  state: "submitted" | "in_review" | "approved" | "rejected"
}

type WorkflowSource = {
  sourceId: string
  role: "evidence" | "governing_policy"
  kind: "hotel_invoice" | "b2c_receipt" | "ticket_screenshot" | "travel_expense_policy"
  dmsRecordId: string
  fileName?: string
  version?: string
  custodyState: "submitted" | "approved" | "restricted"
}

type RouteDecision = {
  routeId: string
  sourceId: string
  route: "local_liteparse" | "managed_llamaparse" | "manual_reject"
  parser?: "liteparse" | "llamaparse"
  reason: string
  outputVersion?: string
}

type DocumentDerivative = {
  derivativeId: string
  sourceId: string
  routeId: string
  format: "markdown" | "structured_json"
  uri: string
  contentHash: string
}

type ExtractedField = {
  fieldId: string
  sourceId: string
  routeId?: string
  name: "vendor" | "date" | "total_amount" | "currency" | "policy_clause"
  value: string
  location: { page?: number; bbox?: number[]; section?: string }
  confidence?: number
  reviewState: "accepted" | "queued" | "corrected" | "reference"
}

type ReviewTask = {
  taskId: string
  caseId: string
  fieldIds: string[]
  trigger: "low_confidence_total" | "policy_conflict" | "total_mismatch"
  assigneeGroup: "finance_ops"
  state: "open" | "accepted" | "corrected" | "rejected"
}

type ApprovalPayload = {
  caseId: string
  approvedAmount: string
  accountCode: string
  approvalState: "approved" | "rejected"
}

Record types keep custody, routing, derivatives, review and approval separate.

Custody stays narrow in this example, with the case as the parent DMS record, evidence documents attached to it and the policy kept as an approved record referenced by version.

LlamaIndex makes the routing decision source by source.⁶² The hotel invoice stays on LiteParse because stable text positions are enough for extraction, while the photographed receipt escalates to LlamaParse because the reimbursable amount may depend on skew, faint print, discounts and tax lines.⁶³ The route record gives the review layer the parser, reason and output version behind each field.

The two parser routes produce different derivatives, but the workflow treats both as records. Markdown gives the agent a readable surface for comparing the receipt, invoice and policy, while parser JSON keeps the layout objects a reviewer needs when a total or line item is questioned.

The field record is the unit the agent and reviewer can share, keeping the extracted value with the source, page location, route id, confidence and review state. The agent can compare the receipt total with the policy clause, and the reviewer can reconstruct the path that produced the value.

Review starts wherever the workflow lacks enough evidence to accept its output, so low-confidence totals, policy conflicts and total-line mismatches become review tasks for finance operations. Once a reviewer accepts or corrects the field, the ERP connector receives the approved amount, account and approval state.

Sequence view of the travel-expense reimbursement workflow

Parser routing, review, and approved ERP handoff.

The sequence view above shows the same separation in time. Tika types uncertain intake files before the DMS creates the case and receives the approval record, LlamaIndex routes sources to LiteParse or LlamaParse, extraction emits field records, the review layer records corrections and ERP receives only the approved payload.

Provenance keeps the agentic part tied to the record system, since source links, route records, page locations and review decisions show why a value was accepted.⁶⁴ Confidence decides whether the value enters the queue,⁶⁵ but the source relation makes the decision reviewable.⁶⁶

Stack failure points

Failure points concentrate in representation, orchestration, review and provenance because tables, handwriting, dense layouts and mixed scan-and-digital bundles behave differently from ordinary text extraction. As previously hinted, a reliable stack routes at page level, keeps simple pages on the local or lower-cost path, escalates difficult pages, and stops pages that lack enough evidence before extraction. Tables need a separate test set drawn from the institution’s documents: recent parsing research treats document pages as more than text-recognition problems⁶⁷ and newer OCR work separates page layout, table structure and region-level recognition inside that broader problem.⁶⁸

The provenance failure is less visible during a successful run, when a derivative can fall out of step with the record or the DMS record can move on while an agent keeps reading an older corpus. Confidence scores route review without proving a field correct.⁶⁹ A reviewer can correct a wrong amount or date only when the field still points to the source version, parser route, page region and policy version that produced it.

Further parser accuracy eventually gives diminishing returns: the system first of all needs a fast review and action path. It identifies uncertainty, routes it to the right owner, records the decision and turns the accepted output back into maintained product state. Model accuracy can reduce the number of exceptions, but review design determines whether the remaining exceptions stay cheap and bounded.

Appendix: Competitor matrix by stack role

Tool	Strongest role in this model	Product category	Strongest position
Doxis / OpenText / DocuWare / ELO / JobRouter	custody	ECM, DMS and workflow suites	system of record, workflow routing, retention, audit and connectors
Azure AI Document Intelligence	representation	cloud document analysis API	broad intake, page geometry, spans, confidence and Markdown output
Google Document AI	representation	cloud document extraction platform	schema-driven extraction, form parsing and foundation-model extraction
Amazon Textract	representation	cloud document analysis API	PDF and image intake, explicit geometry, confidence, forms, tables and queries
Mistral Document AI	representation	Markdown-native document API	page Markdown, HTML tables, word confidence and language coverage
LlamaCloud / LlamaParse / LlamaExtract	representation	managed frontier parser	enterprise tables, charts, dense extraction and page-level auditability
Docling	representation	structured open converter	lossless document object plus Markdown export
MarkItDown	representation	fast open converter	rapid corpus conversion into LLM-readable Markdown
Surya / LiteParse / OCRmyPDF / Tesseract	representation	local parser and OCR tier	local first pass, searchable PDF, model-native OCR and parser fallback
Apache Tika / GROBID / Pandoc	representation	format utility set	file-type extraction, scholarly TEI and approved Markdown export
LlamaIndex workflows	orchestration	document-agent workflow layer	tool calling, task loops, controlled filesystems and structured generation
UiPath Document Understanding⁷⁰	orchestration	RPA document automation platform	validation actions suspend and resume orchestration
Automation Anywhere Document Automation⁷¹ / Tungsten TotalAgility⁷²	orchestration	business automation platform	extraction, validation, routing and audit inside automation
ABBYY Vantage	review	validation workbench	human verification, correction workflow and continuous-learning analytics
Rossum	review	transactional validation queue	low-confidence and empty-field review tied to document context
Instabase	review	deployment review queue	failed validations become review tasks with queues and service targets
Amazon Augmented AI⁷³	review	managed human-review service	human-review workflows around ML predictions and Textract
Hyperscience / Klippa / Parashift / Konfuzio / Hypatos / ExB	review	IDP specialist set	assembled stacks for extraction, validation and downstream BI
Mindbreeze / Sinequa / Squirro	action	insight and search platforms	search, classification, insight surfaces and dashboards over document corpora
ERP / CRM / case systems / BI	action	operational systems	accepted outputs become financial, customer, case or analytical state

The table groups products by their strongest responsibility in this model.