What is intelligent process automation? In plain terms, it is a system that reads the documents and messages a business already receives, decides what they mean, and writes entries into the software that business already runs, with a person on the team approving anything that touches a live record. It is not a chatbot. It is not a macro. It is a piece of software wired into your ERP, your accounting system, or your ticketing tool that handles a specific chore end to end, and hands the judgment calls to a human.
Key takeaways
- Intelligent process automation reads unstructured inputs (PDFs, emails, portals), applies judgment, and writes structured records into the systems you already run.
- The difference from RPA: RPA clicks buttons on a fixed script; IPA handles inputs that vary and decisions that require reading.
- A working example: a rebate-and-margin tool built inside Kelsan's Epicor P21 has recovered over $100,000 in margin that would otherwise have been missed.
- Every write to a live record is queued for a person on the client's team to approve. No autonomous posting to money-touching systems.
- Every Throughline engagement starts with a fixed-fee AI Capability Audit at $7,500. The initial call is free.
The plain definition
Intelligent process automation is the combination of two things: software that can read and interpret messy inputs (a supplier PDF, an email thread, a scanned invoice), and software that can write structured entries into the systems your business runs on. The "intelligent" part is the reading and the judgment. The "process automation" part is the writing.
Put another way: robotic process automation drives a keyboard on a script. Intelligent automation reads a document first, decides what to do, and then drives the keyboard, with a person checking the work before it posts.
How IPA differs from RPA and from generic AI
RPA is deterministic. Give it the same screen and the same fields in the same order, and it will do the same thing every time. It breaks when the layout changes or when a field is missing. It cannot read a supplier's rebate letter and figure out which SKUs it applies to.
Generic AI, on the other end, can read almost anything but does not touch your systems. A chatbot that summarizes a PDF is useful the way a smart intern is useful: you still have to key the result into your ERP yourself.
Intelligent process automation sits between those two. It reads variable inputs the way a person does, then writes to real records the way RPA does, with a review step in the middle. This is where robotic process automation and AI in business services actually earn their keep: on chores where the input is unpredictable but the write path is well defined.
If you want the longer comparison across the four categories of AI partner, we wrote a buyer's guide comparing categories of AI partner that lays it out honestly.
What an IPA system looks like inside a business you would recognize
Consider a wholesale distributor running Epicor P21. Supplier rebate programs arrive as PDFs and spreadsheets, each formatted differently, each with its own tier structure and effective dates. Someone in accounting is supposed to read them, match them against invoices, and claim the margin. In practice, some of those rebates get missed, because the volume is too high and the formats too varied for a person to catch everything.
An IPA system for that chore reads each rebate document as it comes in, extracts the terms, matches them against invoice lines already in P21, and surfaces the entries a person should review. The person approves, and the entry posts. This is the pattern for AI for distributors: read the documents that already arrive, match them against the ERP, and put a human on the approval.
The same shape works elsewhere. A services firm gets vendor invoices in a shared inbox: an intelligent document automation layer reads them, codes them to the right GL account, and queues them for AP to approve. A manufacturer gets purchase orders as PDFs from ten different customers in ten different formats: an IPA system parses each one and writes a sales order draft into the ERP.
None of these are science projects. Each one is a specific chore, wired into specific software, with a person keeping the final say.
First-hand: what we built inside Kelsan
Kelsan is a multi-state distributor in our own group running Epicor P21. We built a rebate-and-margin recovery system inside it. The system reads supplier rebate documents, matches them against invoices in P21, and surfaces entries for a person to approve before they post. It has recovered over $100,000 in margin that would otherwise have been lost.
That is the honest test of an intelligent automation build: it reads a real document, it writes a real record, a real person approves it, and the money either shows up or it does not. If you want the mechanism in more detail, we wrote up how we recovered over $100,000 inside our own distributor.
We built this into the ERP the business already runs. That is what ERP automation means to us: not swapping systems, not adding a portal, but wiring the reading and writing directly into P21.
Where IPA is worth building, and where it is not
Worth building when: the input is a document or message that arrives with real frequency, the decision rules are clear enough that a person could explain them in a page or two, the write path lands in a system your team already trusts, and a missed one costs real money. Rebate matching, invoice coding, order entry from PDF POs, claims triage, and status updates across systems all fit.
Not worth building when: the volume is low enough that a person handles it in an hour a week, the rules change every month, or the write target is a system nobody in the business trusts anyway. Automating a bad process gets you a faster bad process. In those cases we say so, and we do not take the build.
We also do not build fully autonomous systems that touch money without a human in the loop. Every write to a live record goes through an approval queue on the client's team. That is a hard rule, not a preference.
Where this fits in the vendor rebrand cycle
RPA vendors spent the last few years relabeling their platforms as intelligent automation, automated intelligence, or intelligent AI as generative models reshaped what "reading a document" can mean. The labels have moved faster than the substance. What matters for a mid-market operator is not the label. It is whether the resulting system reads the documents you already receive and writes to the systems you already run.
That is what we mean by back office automation: take a chore that arrives as unstructured input, wire it into the system of record, and put a person on the approval. If the tool your existing vendor sells does that inside your stack, use it. If it does not, someone has to build it. That is what we build.
What a first step looks like
Every engagement starts with a fixed-fee AI Capability Audit at $7,500. We look at the chores that consume real hours, the documents that arrive on repeat, the write paths into your ERP or accounting system, and we come back with a short list of candidates worth building, ranked by payoff and risk. The build itself is a separate fixed fee, quoted in writing before anything starts. Cloud costs are metered like any cloud service and quoted in writing before a build.
If a chore is not worth automating, we say so in the audit. That is cheaper for you than a build you regret.
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.