A manager I spoke to last year had eleven people whose whole job was moving data between systems. Not deciding anything. Just reading a number off an email, checking it against a purchase order, and typing it into an ERP. That is the work intelligent automation is built to absorb.
The term gets thrown around loosely, so it is worth being precise. Intelligent automation is not a single product you buy. It is a stack: rule-based bots at the bottom, AI models in the middle, and increasingly a layer of agents on top that decide what to do next. The blog post you are reading sits in our wider series on agentic AI, which is the part of that stack doing the most interesting work right now.
What intelligent automation actually means
Most automation you have met is brittle. A script does the same thing every time, and the moment the input looks slightly different, it either breaks or does something wrong quietly. That is fine for a stable task and a disaster for a messy one.
Intelligent automation pairs the speed of software with enough judgment to cope when reality does not match the template. A misspelled vendor name. A date in the wrong format. An invoice that turns out to be a credit note. At its useful end, it means software that can read a situation, decide what to do, and act, with a human checking the calls that carry real cost.
The three layers doing the work
It helps to separate the term into its parts, because vendors blur them on purpose. There are three, and they do genuinely different jobs.
RPA: the hands
Robotic process automation is the oldest piece. A bot clicks through screens and moves data the way a person would, just faster and without getting bored. RPA is good at stable, high-volume tasks and bad at surprises. Move a button on a vendor portal and the bot walks straight off a cliff. On its own it automates the doing and none of the thinking.
The AI layer: eyes and judgment
This is where the "intelligent" part comes from. Machine learning models read documents, classify them, pull out fields, and make calls a fixed rule cannot. A model can look at an invoice photographed at an angle and still find the total. It can decide a new vendor's layout is close enough to one it has seen before. The judgment is probabilistic, which is the whole point and also the catch: it is usually right, and you need a plan for when it is not.
Document understanding
Reading paperwork is the workhorse use case. This is where agentic document extraction goes past plain OCR. Instead of just turning pixels into characters, it reasons about what the fields mean and whether they add up.
Classification and routing
The same models decide what a document is and where it should go. An incoming email attachment gets sorted as an invoice, a remittance, or a customer query before a person ever opens it.
The agent layer: deciding what happens next
An agent is the part that ties the pieces together and makes decisions. Instead of following a fixed script, it has a goal and a set of tools and works out the steps. If data is missing, it can go find it. If something does not reconcile, it can flag the problem rather than force a wrong answer through.
Planning in practice
A quick example
Say an invoice arrives with no PO number. A scripted bot stops dead. An agent checks the vendor master, finds the open PO by matching the amount and date, attaches it, and routes the invoice for approval. If it cannot find a confident match, it sends the invoice to a person with a short note on what it tried and why it stopped. That last part, knowing when to ask for help, is most of what separates an agent from a macro.
Where it earns its keep first
You do not roll this out everywhere at once. It lands first where the work is high-volume, rule-heavy, and currently done by people who would rather be doing something else. Here is the range we tend to see across finance and operations rollouts in the first 90 days.
Ranges PTAS sees in the field, not vendor benchmarks. Your numbers depend on volume and how messy your documents actually are.
Finance and accounts payable
AP is the classic first project because the work is structured and the cost of an error is obvious. Invoices come in, get matched against POs and receipts, get coded, and get queued for payment. Our invoice agent handles the read-and-match step that used to eat most of a team's morning.
Back-office operations
Onboarding, KYC checks, claims intake, order processing. Anything where a person reads a document, checks it against a system, and types the result somewhere is a candidate. The pattern is the same even when the paperwork changes.
How mature is your automation, really?
A simple way to place yourself: four rough stages. Most teams I see are stuck somewhere between the second and the third, with bots handling the easy 70% and humans still mopping up everything unusual.
Manual
People do the work and the copying. Spreadsheets, email, and a lot of re-keying between systems.
Scripted
Bots handle the stable, repetitive steps. Anything unusual still lands on a person's desk.
Intelligent
Models read documents and make calls. People handle the exceptions and the edge cases.
Agentic
Agents run whole workflows end to end and escalate only the decisions that need a human.
The mistakes that quietly kill these projects
The most common way these projects fail has nothing to do with the technology.
Mistake one: automating a process that was already broken. If your invoice approval takes nine steps because of a workaround someone invented in 2019, a bot will just run the broken process faster. Map the work first. Cut what should not exist. Then automate what is left.
Mistake two: treating model output as gospel. Decide up front what a wrong answer costs, and build the review queue to match. A misread phone number is cheap. A misread payment amount is not. The teams that get this right keep their savings; the ones that skip it quietly switch the system off six months in.
So, is it worth it?
For most finance and operations teams doing repetitive document work at volume, yes, and the bar to get started is lower than it was even a year ago. The honest caveat is that this is a project, not a purchase. You are changing how work flows through your organisation, not just buying a tool that bolts on.
Teams that treat it that way tend to hit the 60–80% and hold it. Teams that drop a bot onto a broken process get a brief demo-day win and not much else. If you want to see which camp your documents fall into, the fastest way is to put a real stack of them through a system and look at the field-level numbers.