RPA vs AI Automation: What Actually Works Inside an ERP

RPA vs AI automation is the wrong framing for most operators, because the interesting builds now combine both. RPA is a rules engine that clicks through screens and moves fields between systems. AI automation reads unstructured inputs (a PDF, an email, a scanned invoice) and turns them into structured data a downstream system can act on. The honest answer to which you need usually starts with a different question: what is the input, and how often does it change shape?

Key takeaways

RPA follows fixed rules and breaks the moment a source document or screen layout changes.
AI automation reads unstructured inputs (PDFs, emails, invoices) and produces structured data a system can act on.
The strongest builds combine both: AI reads the messy input, deterministic logic writes the clean record, a person approves before it posts.
Kelsan, a multi-state distributor in our own group running Epicor P21, has recovered over $100,000 in margin using this pattern.
Every engagement at Throughline starts with a fixed-fee AI Capability Audit at $7,500; the build is quoted separately in writing.

What RPA actually does, mechanically

RPA is a rules engine with hands. It logs in, clicks buttons, copies fields, and pastes them into another screen. If the source is a spreadsheet with the same columns in the same order every week, RPA is fine. Often it is the right answer. The bot runs, the record moves, nobody has to touch it.

The catch is fragility. Change the column order, add a header row, rename a field in the ERP screen, and the bot stops. It does not reason about what it is looking at. It executes the script until the script does not match reality, then it fails, usually silently. Teams that inherited an RPA deployment know this rhythm: quiet for a month, broken for a week, patched, quiet again.

That is not a knock on RPA. It is a description of what a rules engine is. If your process runs on structured, stable inputs and predictable UI, a rule-based bot is faster and cheaper to build than anything that involves a language model. Overkill is a real failure mode.

What AI automation does that RPA cannot

AI automation reads. That is the mechanical difference. A supplier sends a rebate statement as a PDF with a layout you have never seen before, and the system extracts the vendor, the period, the SKU lines, and the dollar amounts. Next month the same supplier sends a different template and it still works. This is intelligent document automation, and it is the piece RPA cannot do on its own.

Once the document is read, you are back in structured-data territory. Deterministic code matches the extracted lines against invoices, computes what is owed, and writes candidate entries into the ERP. The AI does the reading. The rules do the writing. The two halves are not competing categories; they are different tools that belong at different points in the same pipeline.

That is also why a person stays in the loop on anything that touches money. A language model can misread a line. Deterministic code cannot catch a misread it was never told to look for. Human approval on the write step is not a nice-to-have. It is the control that makes the pattern safe to run.

The pattern we run inside our own group

We built a rebate-and-margin recovery system inside Kelsan, a multi-state distributor in our own group running Epicor P21. Supplier rebate documents arrive in the shapes suppliers actually send them: PDFs, spreadsheets, emails with tables pasted into the body. The system reads those documents, matches the lines against invoices already sitting in P21, and surfaces candidate entries for a person on the Kelsan team to approve before anything posts. It has recovered over $100,000 in margin that would otherwise have been lost.

The reason it works is the split. The AI half handles the input variance suppliers throw at us. The deterministic half handles the match logic and the write into P21. The approval step keeps a human on the record. None of those three pieces would carry the load alone, and this is the shape of most useful ERP automation we build.

A decision framework

Start with the input, not the technology. Two honest questions cut through most of the noise.

First: is the input structured and stable? If yes, RPA or a plain integration is probably the right answer. Do not pay for a language model to read a CSV that has looked the same for four years. Second: does the input arrive in shapes that change, from senders you cannot control? If yes, you need something that reads. That is where AI belongs, and it usually sits upstream of the same kind of deterministic write logic RPA would perform.

Then ask a third question that both categories tend to skip: where does the risk sit on the write? If the write touches money, credit, inventory counts, or customer records, a person approves. That is true whether the upstream reader is a rule or a model. Any vendor pitching full autonomy on money-touching writes is selling you a problem.

When RPA is still the right answer

Plenty of times. Moving records between two internal systems that both have stable APIs or stable screens. Nightly reconciliation of two tables with fixed schemas. Kicking off a report and dropping it in a folder. If a junior analyst could write the steps on an index card and the steps never change, a rules-based bot is the honest answer and AI is overkill.

The trap is extending RPA into territory it was not built for. Reading supplier PDFs with a rules bot means writing a new template every time a supplier changes their layout, forever. That is a maintenance treadmill dressed up as automation. If your team is spending more time patching bots than the bots are saving, the input is telling you it needs a reader, not more rules.

When the two belong in the same build

Most real back-office work is a mix. A supplier sends a document, someone reads it, someone keys it into the ERP, someone reconciles it later. The reading is unstructured. The keying is structured. The reconciliation is deterministic. Splitting the job so AI handles what it is good at and rules handle what they are good at is the point of a real business process automation build.

This is the frame most vendor content misses, because vendors sell one category. Builders who have wired systems into a live ERP see the split immediately. It is also the reason a good AI systems integrator will ask about your inputs and your approval flow before recommending a stack.

Next step

If you are scoping this decision for real, start with a conversation about the input, not the tool. We run a fixed-fee AI Capability Audit that maps your candidate processes, names the ones worth building, and names the ones that are not. If it is a rules problem, we will tell you. If it is a reading problem, we will tell you that too.

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.

FAQ

Questions

What actually breaks in an RPA bot when the source document changes?

The bot's script assumes fixed positions: this field is in column C, that value is on line 4. When the sender changes the layout, the script reads the wrong cell or fails to find the field at all. The bot either errors out or, worse, writes wrong data into the downstream system. That is why document-shaped inputs are a poor fit for pure RPA.

Can AI automation replace an existing RPA deployment?

Sometimes, but usually the better move is to wrap it. Keep the deterministic write logic your RPA already performs and put an AI reader in front of it to handle the unstructured input. You get the reliability of the existing bot on the write step and the flexibility of a reader on the input step. Ripping out a working RPA deployment because "AI is the future" is not a strategy.

What does human approval look like in practice?

A person on your team sees the extracted data and the proposed write, side by side, and approves or rejects before anything posts to the live system. Approval can be batched or line-by-line. The point is the write to a record of value never happens without a human confirming it. This is how we run every money-touching system in our group.

How do I know when a rules-based bot is enough and AI is overkill?

If the input is structured, the schema is stable, and the process has run the same way for a year without a template change, a rules-based bot is enough. Reach for AI when the input is unstructured, the senders are outside your control, or the layout changes often enough that maintaining templates costs more than the automation saves.