What is business process automation? It is a system built into the software you already run, that reads real documents, matches them against real records, and writes entries a person on your team approves before anything posts. It is not a chatbot. It is not a Zapier flow. It is not a separate platform you log into. The work happens inside your ERP, your accounting system, or whatever system of record already runs the business.
Key takeaways
- Business process automation reads the documents you already receive and writes entries into the systems you already run, with a person approving every write that touches money.
- BPA is different from RPA (which mimics clicks) and workflow automation software (which routes tasks); BPA changes real records inside real software.
- A rebate-and-margin system we built inside Kelsan, a multi-state distributor in our group running Epicor P21, has recovered over $100,000 in margin that would otherwise have been lost.
- Not every process should be automated. If the inputs are inconsistent, the volume is low, or the rules change monthly, the honest answer is often no.
- Every Throughline engagement starts with a fixed-fee AI Capability Audit at $7,500. The initial call is free.
A plain definition
Business process automation is the practice of taking a repeatable process that a human currently does by hand, then building software that does the reading, matching, and drafting for them, and hands the result back for approval. The word "process" matters. A process has inputs (documents, emails, files), a set of rules, and outputs (a record posted, an invoice paid, a credit issued). BPA is what happens when you put a machine between the inputs and the outputs, and keep a person on the approval side.
That framing rules out a lot of what gets sold as BPA. A chatbot that answers questions is not process automation. A dashboard that shows you what happened last quarter is not process automation. A macro that copies data from one spreadsheet to another is closer, but it does not read unstructured documents and it does not know what a valid entry looks like in your ERP.
How BPA differs from RPA, workflow tools, and "AI"
The category is crowded and the terms are used loosely, so it helps to be specific.
RPA (robotic process automation) mimics a human clicking through screens. It records the mouse and keyboard, then replays them. It works when the screens never change and the inputs are already structured. It breaks the day a vendor updates a UI.
Workflow automation software routes tasks between people. Think of a purchase request that needs three approvals in order. Workflow tools are good at moving a task from inbox to inbox. They do not read a PDF and decide what the numbers mean.
Generative AI, on its own, writes text. It can summarize a document, draft an email, or answer a question. That is useful, but it is not a system. A system is what you get when you wire generative AI into your systems of record so it reads and writes real data, under controls you can audit. That wiring is what makes generative AI integration different from a subscription to a chatbot.
Business process automation, the way an operator should think about it, sits above all three. It uses document reading to handle unstructured inputs, uses rules and models to decide what a valid entry looks like, and writes to the system of record with a human in the approval loop.
What a real BPA system does
Here is what it looks like in practice, without the marketing language.
A supplier emails a rebate statement as a PDF. The document lists dozens of line items, each tied to a product family, a date range, and a percentage. Somewhere in your ERP, there are invoices those rebates should reduce. A person could open the PDF, open the ERP, and match them by hand. Multiply that by a hundred suppliers a quarter and you have a full-time job that mostly does not get done well.
A BPA system reads the PDF, pulls out the structured data, queries the ERP for the matching invoices, and drafts the entries. A person on the team opens a queue, reviews what the system found, and approves or rejects each one. What posts, posts because a human said so.
We built exactly that inside Kelsan, a multi-state distributor in our group running Epicor P21. The tool reads the 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. You can read more about the rebate-and-margin tool we built inside Kelsan if the shape of the problem sounds familiar. It is one of the systems we run across our own operating companies before we take a version of it to anyone else.
That is the pattern. Read documents you already receive. Match against records you already have. Draft entries. Person approves. Post.
Where BPA fits versus low-code and off-the-shelf
Off-the-shelf software is the right answer when a category is mature and your process is standard. If you need payroll, buy payroll. If you need CRM, buy CRM. Do not build.
Low-code tools sit in the middle. They are good for connecting apps that already have clean APIs and simple triggers: when a form is submitted, create a row, send an email. They struggle the moment the input is a document a person has to read, or the output is a record inside a system with real business rules.
BPA, done as a build, is what you reach for when the process is specific to your business, the inputs are messy, and the write matters. That is often back office automation work: rebates, credits, statements, exceptions, the queue of things that never quite fits a template. It is also often ERP automation, because that is where the records live.
For distributors specifically, the pattern repeats across rebates, pricing exceptions, freight claims, and supplier statements. If you are running P21 or a similar ERP, the shape of AI for distributors tends to look the same: document in, structured data out, entry drafted, person approves.
When not to automate
The honest section. Skip a build if:
The volume is low. If a process runs twenty times a year, a well-written checklist beats a system.
The inputs are wildly inconsistent. If every supplier sends a different format and the formats change every quarter, expect the reading layer to need more care than the math.
The rules change monthly. Automation encodes rules. If the rules are unstable, you will spend more time updating the system than doing the work by hand.
Nobody owns the process today. If there is no person on your team who can describe what "correct" looks like, a machine cannot either. Fix the process first.
The savings are theoretical. If you cannot point to specific dollars, hours, or errors the current process is costing, do not build. Measure first.
We would rather tell you not to build than build the wrong thing. That is part of what the AI Capability Audit is for.
What it costs, roughly
Every Throughline engagement starts with the same first step: a fixed-fee AI Capability Audit at $7,500. The audit produces a written map of where automation fits in your business, what to build first, and what to leave alone. The build itself is a separate fixed fee, agreed in writing before work starts. Cloud costs are metered like any other cloud service and quoted before a build begins.
We do not sell hours. We do not sell seats. We do not resell a platform.
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.