What is intelligent document automation? It is a system built into the software your business already runs, which reads the documents you already receive, extracts the fields that matter, and drafts entries for a person on your team to approve before anything posts to a live record. It is not a chatbot. It is not a separate dashboard. It sits inside the ERP or accounting system you already log into, and it turns paper, PDFs, and email attachments into structured data your team can act on.

Key takeaways

  • Intelligent document automation reads unstructured documents (PDFs, scans, emails) and writes structured entries into the system of record a person already uses.
  • It is different from plain OCR: OCR gives you text, while document automation understands which fields on which document map to which record in your ERP.
  • A human on your team approves any write to a live record. Nothing money-touching runs unattended.
  • Throughline built a rebate-and-margin recovery system inside Kelsan, a multi-state distributor in our own group running Epicor P21, that has recovered over $100,000 in margin.
  • Every engagement starts with a fixed-fee AI Capability Audit ($7,500). The initial call is free.

A plain definition, in operator language

Every business runs on documents it did not design. Supplier rebate agreements. Invoices in a dozen formats. Bills of lading. Insurance certificates. Vendor statements. Purchase orders emailed as PDFs. Someone on your team opens each one, reads it, keys the important numbers into a system, and files the original.

Intelligent document automation replaces the reading and keying step. A tool ingests the document, identifies what kind of document it is, pulls out the fields you actually care about, matches those fields against records already in your ERP or database, and drafts an entry. A person then approves, edits, or rejects that draft. When they approve, it posts.

That is the whole mechanism. There is no magic. The point is that the reading and matching are done by software that does not get tired at 4:30 on a Friday, and the judgment is still made by a person who knows the business.

How it differs from OCR, RPA, and "AI" in general

OCR turns an image of text into text. That is it. If you scan a supplier invoice, OCR gives you a wall of characters. It does not know which number is the total, which is the tax, which is a line item, or which vendor sent it.

RPA (robotic process automation) clicks buttons and moves data between systems along a fixed script. It is brittle. Change the layout of a form and it breaks.

"AI" as a general term covers a lot of ground, most of which is not this. A chatbot is AI. A recommendation engine is AI. Neither reads your supplier statements and writes GL entries.

Intelligent document automation combines the reading step (modern models that handle varied layouts far better than old OCR) with the matching step (checking extracted fields against your existing records) and the writing step (drafting an entry in the system of record). It is a specific application of generative AI integration aimed at one job: getting information off documents and into your systems without a person retyping it.

What it looks like when it works

Here is the honest version, from work we did inside our own group.

Kelsan is a multi-state distributor running Epicor P21. Supplier rebate programs are a real part of distribution margin, and they are also a mess. Rebate agreements arrive as PDFs with different structures per supplier, different tier rules, different effective dates. Matching those rebate terms against actual invoice line items in P21, at scale, across hundreds of SKUs and dozens of programs, is exactly the kind of work that quietly leaks margin because nobody has time to reconcile it by hand.

We built the rebate-and-margin tool we built inside Kelsan directly into that P21 environment. It reads the supplier rebate documents, matches them against invoices already in P21, and surfaces entries for a person on the Kelsan team to approve before anything posts. To date it has recovered over $100,000 in margin that would otherwise have been lost.

Two things worth naming. First, the system does not decide. A person approves every entry that touches a live record. Second, the tool lives inside the ERP the team already uses. There is no second dashboard to check, no separate login, no new place for work to hide.

That is the shape of a working ERP automation build. Same pattern applies whether the documents are rebates, freight invoices, packing slips, or vendor bills.

Where it applies, and where it doesn't

Good candidates for intelligent document automation:

  • High volume of similar-but-not-identical documents (supplier invoices, remittances, statements, rebate agreements, insurance certificates, freight bills).
  • Documents that arrive from outside your business, in formats you do not control.
  • A clear system of record where the extracted data needs to land.
  • A real cost to the current manual process, whether that is headcount, delay, or leaked margin.

Poor candidates:

  • One-off documents that arrive twice a year. Not worth the build.
  • Documents where the downstream decision is genuinely judgment-heavy and the reading step is not the bottleneck.
  • Situations where the source documents are so inconsistent or handwritten that even a person struggles to extract the data reliably.

Be honest with yourself about volume and consistency. If your accounts payable clerk processes forty invoices a week and half of them are already EDI, you do not need this. If she processes four hundred a week from two hundred vendors in fifty formats, you probably do.

How it connects to the systems you already run

The connection point is the ERP, accounting system, or database that already holds the records. A build reads documents from wherever they arrive (a shared inbox, a folder, a supplier portal), extracts fields, checks them against records in the system, drafts the entry, and presents it to a person in an interface they can approve or reject.

For distributors, that system is often Epicor P21, NetSuite, SAP Business One, or a comparable ERP. For services businesses it might be QuickBooks or Sage. The read-match-draft-approve pattern is the same. What changes is the API surface, the record schema, and the approval workflow.

This is why we describe what we do as building an AI systems integrator practice, not selling a platform. The system is built into your software. When we are done, you keep it. It is not a subscription to another vendor's product.

When it is not worth building

Sometimes the right answer is not to build.

If a good off-the-shelf tool already reads the exact document type you care about and writes cleanly to your system, buy it. If your volume is genuinely low, a person is cheaper than a build. If your process is so undefined that nobody can describe what a "correct" extraction looks like, fix the process first.

An honest audit will tell you which of those applies before you spend on a build. That is the point of starting with the audit rather than a proposal.

The next step

If you have read this far, you probably have a document workflow in mind already. The right next move is a short conversation about whether that workflow is a real candidate, what the shape of a build would look like, and what it would cost. If it is not worth building, we will say so.

Book a call with Throughline, or start with a fixed-fee AI Capability Audit ($7,500). The call is free. Call 865-417-3554.

About the author

Throughline is a small team of builders inside Keller Group. We build AI systems into our own operating companies first, then into yours.