What Is Intelligent Document Processing? IDP for Developers in 2026

What is intelligent document processing? It is software that turns documents such as invoices, contracts, filings and forms into structured data a program can use. From a developer's seat it is a pipeline: documents come in, fields come out, and checks sit in between. This article defines IDP, shows how it differs from OCR and RPA, walks through its stages, and then runs one real extraction call, without a schema, on an IRS Form W-9, over REST or MCP.

The short version

• —The answer: IDP is the whole path from a document to validated fields. OCR (reading characters from an image) is one possible step in it, and RPA (automating clicks between screens) is a neighbour, not a substitute.
• —The real call: a public IRS Form W-9, extracted with instructions only. The result came back as JSON text in the human field, machine was null, and it cost 5 points.
• —The lesson: instructions alone let the model choose key names and nesting. For anything your code reads, pin the shape with a schema, as in the PDF to JSON article.
• —Who it is for: developers deciding whether to build, buy or assemble an IDP pipeline, and teams that want one extraction step behind their own intake and review.
• —What it costs: AI extraction is a flat 5 points per call, shown in the action costs on the pricing page. Inputs are URLs; no upload route is documented.

What intelligent document processing is

A document is information arranged for a human reader: columns, headings, tables, stamps, footers. A program wants a record: a supplier name, a date, a total, a list of line items. IDP is the work of getting from the first to the second without a person retyping it.

Three properties separate IDP from simply reading a file:

• —It handles variation. The same kind of document arrives in many layouts. One supplier's invoice looks nothing like another's, and a form from one country is arranged differently from another's.
• —It outputs fields, not text. The result is a structure with names and types, such as a date and a number, not a block of text you still have to interpret.
• —It includes a way to be wrong safely. Real systems validate what they read, flag what they are unsure about, and let a person correct the rest.

The last property is the one most often skipped in a first prototype and most often missed in production. A demo that extracts a clean document proves little. A system that behaves sensibly on a crooked scan, a missing field and a layout it has never seen is doing IDP.

IDP versus OCR

Optical character recognition (OCR) converts the image of a page into text. It is a perception step. Its output is a stream of characters, perhaps with positions, and it has no idea which of those characters is the invoice number and which is a phone number.

IDP can include OCR, because many documents are images or scans. But plenty of documents, such as PDFs generated by accounting software, already contain real text and need no OCR. OCR is a possible component and IDP is the whole job. A team that says "we have OCR" and expects fields to appear has done the first of several steps.

IDP versus RPA

Robotic process automation (RPA) automates actions in software the way a person would: clicking, copying, pasting between screens. It moves data around well when the data is already structured. It does not read an unstructured document.

The two meet at the edges of a workflow: IDP produces the record, and RPA, or a plain API call, puts it into the system.

IDP versus pasting a document into a chat model

A general-purpose chat model can read a document and answer questions about it, which is useful for a one-off. As a pipeline step it leaves you with work: the answer comes back as prose, the shape can vary between runs, and splitting, retrying and validating are yours. An extraction step asks the same model-based reading for a fixed set of fields and returns them as JSON. That is the difference between reading a document and processing documents.

How IDP works

This is how the industry generally describes IDP, from older template-based products to current language-model-based ones. It is a general picture, not a description of any one product. Vendors name the stages differently, and not every system has all of them.

1. Ingestion

Documents arrive from an inbox, an upload form, a storage bucket or a public URL. Ingestion collects them and records where each came from.

2. Classification

Before reading a document, a system often decides what it is: an invoice, a purchase order, a contract, a bank statement. Classification chooses which fields to look for. An invoice has a total; a contract has parties and a term.

3. Reading the content

Next the system gets at the text and its layout. For a digitally created PDF the text is already there and the job is reading it in the right order, across columns and in tables. For a scan or photo, OCR must produce the text first, and its mistakes flow into everything after. Layout matters because meaning depends on position: a number under "Total" is a total, while the same number in another column may be a tax rate.

4. Field extraction

This is the step most people mean by "extraction". The system maps content to the fields you asked for. There are two broad ways to specify them:

• —A schema. You define the fields, their types and which are required, and the output has that shape. This is the choice for anything you will store and query.
• —A description. You say in plain language what you want, and the system decides the structure. This is quick for exploring what a class of documents contains.

Template-based systems did this by coordinates and keywords per layout. Machine-learning systems did it with models trained per document type. Language-model-based systems do it by reading the content and following your instructions. The trade-off is that a model can produce a plausible value that is wrong, so the stages after this one carry more weight.

5. Validation

Extracted values are checked against rules you can state: the date parses, the currency is one you accept, line items add up to the subtotal, a required field is not empty. Validation catches many errors cheaply, because many wrong values break a rule. Let the model read, and let deterministic code decide whether a rule holds.

6. Human review

Documents that fail validation or look uncertain go to a person, with the source and the extracted fields side by side. Corrections are stored as corrections, so you can see over time which fields and which document types cause the trouble.

7. Delivery

Finally the record goes where it is needed: an accounting system, a database, a search index, an agent. Processing the same document twice should leave one record downstream, not two, so store the source address and a version of the extraction instructions with every record.

A real call on an IRS W-9

The rest of this article is not a general description. It is a real call, made on 2026-10-29 through the run_extract tool on NeuralVerge's hosted MCP server, on a real public document: the IRS Form W-9, a three-page PDF at irs.gov, revision March 2024. A W-9 is a form with numbered lines, boxes and instructions, the kind of layout IDP is meant for.

The key detail of this call is what was left out: no schema. Only a URL and instructions. The REST form of the same request looks like this.

curl https://api.neuralverge.ai/functions/v1/run-extract \
  -H "Authorization: Bearer <API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://www.irs.gov/pub/irs-pdf/fw9.pdf",
    "instructions": "Extract the document as structured data: form name, form number, revision date, issuing agency, the numbered fields or parts a person fills in (label and a short description), and the number of pages if stated. Leave a field null if it is not in the document."
  }'

The captured call used the MCP tool with the same two inputs. Parameter details live in the API documentation.

What came back

The top level of the response looked like this. Note the two fields at the end:

{
  "session_id": "546099a9-2ca5-4edf-a1c8-ca0a407e8578",
  "kind": "extract",
  "url": "https://www.irs.gov/pub/irs-pdf/fw9.pdf",
  "used_url": "https://www.irs.gov/pub/irs-pdf/fw9.pdf",
  "settings": { "has_schema": false },
  "human": "<the result, as JSON text - parsed below>",
  "machine": null,
  "total_points": 5
}

Without a schema, machine was null, and the entire result arrived as JSON text inside the human string. Parsed, that text is the following. It is shortened: the fields array had 12 entries in total, and only the first three are shown, with one long description cut off.

{
  "form_name": "Form W-9",
  "form_number": "W-9",
  "revision_date": "March 2024",
  "issuing_agency": "Internal Revenue Service",
  "fields": [
    {
      "label": "1 Name of entity/individual",
      "description": "An entry is required. (For a sole proprietor or disregarded entity, enter the owner’s name on line 1, and enter the business/disregarded entity’s name on line 2.)"
    },
    {
      "label": "2 Business name/disregarded entity name, if different from above.",
      "description": null
    },
    {
      "label": "3a Check the appropriate box for federal tax classification ... Check only one of the following seven boxes.",
      "description": "Individual/sole proprietor C corporation S corporation Partnership Trust/estate LLC. ..."
    }
  ],
  "pages": 3
}

The remaining entries covered lines 3b, 4, 5, 6, the requester's name and address, line 7, the social security number, the employer identification number, the signature and the date.

What this shows about inferring structure

The shape came from the instructions and the document, not from a definition we wrote. We never said the output should contain a fields array or that each field should have label and description keys. The model chose that structure from the instruction's wording ("label and a short description") and from what the form contains. This is the "structure inferred from layout" idea in IDP made concrete. The W-9 has numbered lines, and the output has numbered labels, in reading order, ending with the page count we asked for.

Absent information became null. Line 2 has no description in the form, and the response says null rather than inventing one. The instruction said "leave a field null if it is not in the document", and the output followed it. That is the behavior you want, and it is worth testing on your own documents rather than assuming.

The label text is the form's text, not a tidy name. The label for line 3a is a long fragment of the form's instruction wording. That is faithful to the document and useless as a database column name. A person reading it understands it; a program joining on it does not.

The result sits in the wrong place for code. machine is null here, and the data is JSON text inside human. Code that reads machine and finds nothing has to know to fall back to parsing a string.

Why a schema makes output dependable

The same document was also extracted with a schema, in a separate call: five fields (form_number, form_title, revision_date, issuing_agency, and an array of Part I line labels), all required. With a schema, machine carried the typed object and the keys were the ones the schema named. Without one, the model chose the names, and a second run, or a different W-9-like form, could reasonably choose different ones.

A schema does not make the values correct. In that call, the labels we asked for came back as printed on the form, including long instruction fragments, so typed fields still need your own cleanup and validation. The full with-schema response is in the PDF to JSON article. For documents where the arithmetic can be checked, such as invoices, the invoice extraction walkthrough shows the schema, the response and the validation checks that follow.

Choosing between instructions and a schema

REST and MCP

The W-9 call above is the MCP path: an agent sends the url and instructions to the run_extract tool on the hosted MCP server. The same capability is available over REST, a POST to https://api.neuralverge.ai/functions/v1/run-extract with a bearer API key and the same JSON body, as in the curl request shown earlier. Only the MCP response was captured here, so no REST response is shown. Endpoint and parameter details live in the documentation.

Inputs, outputs and price are the same either way, so the choice is about who makes the call. Use REST from a batch job or a queue that feeds documents through your own intake, classification and review. Use MCP when an agent meets a document link while doing something else: a company page links to a filing, a ticket links to an invoice. The agent asks for exactly the fields the current task needs and gets JSON, and its context window is not spent on pages of text. Setup is in the guide to connecting the MCP server. Tool names use underscores (run_extract), REST paths use hyphens (run-extract).

Cost and limits

Each extraction call cost 5 points, as listed in the action costs on the pricing page. The W-9 call without a schema cost 5, and the with-schema call cost 5. The same price applies over REST or MCP. This article makes no accuracy or speed claim for any document type.

Input limits worth stating plainly

AI extraction takes a URL. The W-9 above was a public PDF at a public address. No upload route is documented, so private files in your own storage are not covered by anything stated here. Handling of scanned, image-only or handwritten documents is not stated either, and neither are file size limits. Test your own samples before you plan around any of these.

A null result is still billed

One observation from testing: a call on a URL that did not load returned null and was still billed 5 points. The call was a sample invoice address that returns HTTP 404. So null does not mean free. If you run a batch, check that the URLs resolve first, and count null results as billed calls when you estimate cost.

Where the approach struggles

Shape drift without a schema. As the W-9 call shows, instructions alone leave key names and nesting to the model. Pin them with a schema before anything depends on them.

Plausible but wrong values. A language-model reader can return a value that looks right and is not. Validation rules and sampled human review are what catch it; the extraction call alone does not.

Private and sensitive documents. Invoices, contracts and identity documents may contain personal or confidential data. Before sending anything to any external service, check what its terms say about handling, retention and processing, and involve whoever owns that decision in your organization. The W-9 used here is a blank public form with no filer data in it.

A single call is a building block. Mapped onto the stages above, the call is the extraction step, with some of the reading step behind it. Choosing which URLs to send, validating and reviewing the fields, and storing the result are yours.

How to decide

Whether you buy a platform, assemble components or call an extraction endpoint, run the same checks on real documents of your own.

• —Test on your worst documents, not the demo. Include poor scans and odd layouts.
• —Measure field-level correctness. Check a sample against a hand-verified answer, per field, not "it looked fine".
• —Check what happens when a field is missing. You want an empty value, not a plausible guess.
• —Check where the result lands. With and without a schema, does your code find the data where it looks?
• —Find out what inputs are accepted. A URL, an upload, an email attachment, a bucket: confirm it matches how your documents actually arrive.
• —Check how failures are billed and reported. An address that does not load should be distinguishable from a document with nothing in it, and you should know whether it costs anything.
• —Match the use case. Accounts payable (invoices into line items and totals, matched to purchase orders), onboarding and compliance (fields from company documents and tax forms, with a reviewer confirming the important ones), public filings and tenders (rows an analyst can filter), and agent workflows (a tool such as run_extract that returns fields from a document the agent meets) all stress different parts of the pipeline.

Frequently asked questions

Is intelligent document processing the same as OCR?

No. OCR turns the image of a page into text and stops there. Intelligent document processing starts from the document and ends with usable fields. In the general industry description it includes reading the text (with OCR when the document is an image), working out what kind of document it is, finding the fields you care about, checking them, and handing the result to another system. OCR is one possible step inside IDP, and for documents that already contain real text it is not needed at all.

Do I need to train a model for each document type?

Not necessarily. Older IDP products relied on templates or per-type training. Current approaches use language models that read the document and fill in fields you describe, so a new layout often needs only a changed instruction or schema. You still need to test each document type on real samples, because a model that has not been trained on your layout can still misread it.

Can IDP be fully automatic with no human review?

For some fields and some documents, yes, but it is a decision you make with evidence, not a default. Extraction can be wrong in ways that look right, so production setups validate fields, route uncertain documents to a person, and measure error rates before reducing review. How much review you need depends on what a wrong value costs you.

How does NeuralVerge's AI extraction fit into an IDP pipeline?

It covers the extraction step. You send a URL that points at a public page or PDF, describe the fields you want in plain language, optionally add a JSON Schema, and get the result back. Without a schema the shape is chosen by the model and arrives as JSON text in the human field with machine set to null; with a schema the typed object arrives in machine. Intake, classification, validation, review and delivery remain your own pipeline. It costs 5 points per call.

Can I use document extraction over MCP from an AI agent?

Yes. AI extraction is available as the run_extract tool on the hosted MCP server, with the same inputs, outputs and price as the REST call, so an agent that meets a document link can request exactly the fields it needs. Our W-9 test was made through that tool. AI research is REST-only, but extraction is on both.

Can I upload a file directly, or does the document need a URL?

NeuralVerge's AI extraction is documented as taking a URL that points at a public page or PDF, and no upload route is documented. If your documents are private files, for example invoices sitting in your own storage, check the documentation for what the endpoint accepts today before designing around it. Scanned or image-only documents, and file size limits, are not described either, so test your own samples.

What happens if the URL does not load?

In our test, a URL that returned a 404 came back with a null result, and the call was still billed 5 points. Check that URLs resolve before a batch run, and count null results as billed calls.