How AI Agents Actually Read Your Contracts and Invoices

Dropping a PDF into a chat window and asking "when does this renew?" is not document automation. It is a person doing the work with a faster assistant. The document is still in the inbox, the answer is still in someone's head, and nothing happens if nobody asks.

An AI agent working on documents is a different thing. It runs unattended on everything that arrives, it produces a record rather than an answer, and it has to act — register, route, escalate — on what it read. That changes what "reading" means, and it changes what breaks. This is the walkthrough: the five steps an intake agent runs, where each one stalls on real contracts and invoices, and what the document and the system around it have to look like for the agent to get through.

Step 1 — Capture: getting text out of the thing that arrived

Nothing arrives as a document. It arrives as an email with a thread, a signature block, two attachments, and a forwarded chain in which somebody says "see below". The first job is to decide which of those is the document, and then to get text out of it.

A PDF exported from Word has a text layer, and capture is trivial. A scan — and a surprising share of signed contracts are scans, because somebody printed, signed, and photographed — has no text layer at all. The agent runs OCR, and OCR has its own error profile: O for 0, dropped decimal points, a column of amounts read as one long number. An agent that treats OCR output with the same trust as native text will file a wrong amount with high confidence.

Step 2 — Classify: what is this?

Contract, invoice, order form, amendment, credit note, quote, or noise. This looks easy and is the step where a wrong answer costs the most, because everything afterwards is conditioned on it. An amendment classified as a new contract becomes a duplicate registry entry with a fresh renewal date. An order form classified as an invoice goes to accounts payable.

Real classifiers use both vocabulary ("hereby", "shall", "governed by" versus "bill to", "amount due", "remit") and structure (a signature block versus a line-item table). The important design property is that the classifier returns a probability, not a label. A document that is 55% invoice and 45% order form is a document a person should look at, and an agent that reports it that way is more useful than one that picks.

Step 3 — Extract: the fields that let anyone act

This is the step people picture when they say "AI reads the contract", and it is the step the agent-readiness checker makes visible. The agent is not summarising. It is filling a fixed set of fields, each with a confidence, and it has to be honest about the ones it could not fill.

For a contract, the fields that matter operationally are a short list:

• Parties — both, as legal entities, with roles.
• Effective date and term — and from those, the end of the current term.
• Renewal mechanics — does it auto-renew, for how long, and with how much notice.
• Notice rules — calendar or business days, and whether notice counts on sending or on receipt. These two decide the actual deadline.
• Money — amount, currency, cadence, payment terms, permitted increases.
• References — the order form, the MSA, Exhibit B, the PO number.
• Status — draft, executed, countersigned.

For an invoice the list is shorter and stricter: vendor, bill-to, invoice number, invoice date, due date or terms, service period, line items, total with currency, and the PO or contract it bills against. Three-way matching needs every one of those; a missing service period is how the same month gets paid twice.

Where extraction actually fails

It fails less on prose than people expect and more on formatting than people expect. The recurring cases, from watching real inboxes:

The payload between steps: what the agent hands downstream

Between extraction and everything after it sits one structured payload. Nothing downstream — the registry, the deadline watcher, the approval router — ever sees the PDF. They see this, and only this. It's the contract between steps, and it is what makes the whole pipeline testable: you can replay a thousand documents through routing without a model in the loop, and a person can correct one field instead of re-reading forty pages.

{
  "tool": "extract_document",
  "document": { "type": "contract", "id": "MSA-2026-0417", "version": "2.1", "governing_law": "New York" },
  "parties": [
    { "name": "Northwind Analytics, Inc.", "role": "provider" },
    { "name": "Globex Logistics Ltd",      "role": "customer" }
  ],
  "money": { "amount": 24000, "currency": "USD", "cadence": "year", "payment_terms": "net 30" },
  "dates": {
    "effective": "2026-03-01", "term_months": 12,
    "renewal": "2027-03-01", "renewal_source": "derived",
    "auto_renews": true, "notice_days": 60, "notice_unit": "unspecified",
    "notice_effective": "receipt", "notice_deadline": "2026-12-31"
  },
  "routing": { "signed": true, "purchase_order": "PO-88213", "owner": "Priya Raman",
               "suggested_action": "register_and_watch_deadline" },
  "confidence": { "dates.renewal": "medium", "dates.notice_days": "medium" },
  "open_questions": [ "Calendar or business days?" ]
}

Three things in that payload are doing most of the work. renewal_source: "derived" says the renewal date was computed from the effective date and the term, not read — so it gets a lower confidence and a person should glance at it. notice_unit: "unspecified" is the honest answer when the clause says "60 days" and nothing else; the agent has not assumed calendar days, it has flagged that the two readings sit about 25 days apart. And open_questions is not an error list — it's the agent's half of a conversation, phrased so a person can answer in one line.

Step 4 — Link: a document with no relationships is a filing, not a record

An invoice is meaningless on its own. It's meaningful against the contract that sets the price, the PO that authorised the spend, and the previous invoices that establish whether this period was already billed. An amendment is meaningless without its original. An order form is meaningless without the MSA whose terms it inherits — including, usually, the notice period.

Linking is where an agent starts to beat a person, because a person links from memory and memory leaves the company. The agent links by matching: counterparty name, PO number, reference numbers in the text, amounts that agree, dates that nest. When it can't link — new vendor, no PO, a reference number nobody has seen — that's a routing decision, not a failure: hold for a human, and say why.

This is also the step that answers the question the renewal spreadsheet never could: not "when does this renew" but "what else changes if we let it".

Step 5 — Route: decide, act, or ask

The last step turns a record into an outcome. For a contract with a clean extraction: register it, compute the notice deadline, watch it, and notify the owner at 90, 60, and 30 days. For an invoice that matches: route to the approver the policy names for that amount and cost centre, or straight through if policy allows. For anything with open questions: ask the person most likely to know, with the questions already written and the document already linked.

Whether the agent itself ever approves is a policy choice, not a technical one. Most teams draw a threshold: below it, a matching invoice goes through with the agent's reasoning attached to the audit trail; above it, a named person decides, and the agent's job is to have done everything except decide.

IDP versus an agent: where the line actually is

Intelligent document processing vendors have done step 3 well for a decade. The difference isn't accuracy. It's what happens after the fields exist.

	Intelligent document processing	Document intake agent
Input	A file you send it	Everything that arrives in a mailbox, unattended
Output	Fields	A registry record, a routed approval, or a question — plus the fields
Context	This document	This document against the contract, PO, and history it belongs to
Ambiguity	Best guess, or a confidence score you have to act on yourself	Asks a specific question of a specific person, then continues
Action	None — you build the workflow	Calls tools: register, watch a deadline, request approval, file
Audit	Extraction log	Why it routed where it did, what it asked, who answered

What the system has to expose — the other half of agent-readiness

Everything above assumes the agent has somewhere to put what it found and something to call when it decides. A shared drive gives it neither. A folder has no "since I last looked", no status, no owner, and no way to say "this invoice belongs to that contract" except a naming convention that nobody follows.

A document management system built for agents exposes documents as objects with IDs, versions, statuses, links, and owners — and a small, predictable toolset for working with them. The reference shape is seven calls, and they map one-to-one onto the five steps:

Tool	Step	What it does
list_documents	Capture	What arrived since a cursor, filtered by type, status, party, or deadline window.
get_document	All	The full record — text, fields, version, status, links, owner.
extract_document	Extract	The payload above, with per-field confidence.
find_related	Link	The MSA behind an order form, the invoices under a contract, the amendment that changed a clause.
request_approval	Route	Route by amount, category, or cost centre; returns a ticket the agent can cite.
get_approval_status	Route	Approved, rejected, waiting on whom, since when.
file_document	Route	Commit to the registry with fields, links, and a watched deadline; returns an ID.

Exposed over MCP or an equivalent, this is what lets any agent — yours, a vendor's, the one in your finance team's chat client — work with the documents without a bespoke integration. The property that matters is the one in the last column: every call returns structured records with IDs, never files. The tool surface alone isn't the whole story — validation and the audit trail still have to be designed — but without it there is nothing for an agent to hold on to.

Try it on your own document

The Document Agent-Readiness Checker runs a transparent, rule-based version of step 3 in your browser: paste a contract, an invoice, or the email it came in, and it shows the three columns — what an agent extracts with confidence, where it stalls, and what it would have to ask you — plus the extract_document JSON above, built from your text. Nothing is uploaded. If it finds a renewal date and a notice period, it hands them to the deadline calculator so you can see the actual last day to act.

Most documents score in the sixties on the first run. The score is not a judgement of the document; it is a list of the questions you'd be answering by hand, one document at a time, if an agent were reading your inbox today. That list is short, and every item on it is fixable in the template.

The version where you don't do this by hand — an agent on contracts@ running all five steps on everything that arrives — is what SynapticRelay is. The rest of the operational reference on what those documents say is in the renewals hub.