What process automation is
Process automation is software that carries out the repeatable steps of a business process. It moves data between systems, applies your rules, routes work to the right person and records what happened. People keep the exceptions and approve the decisions that carry risk, and the software does the copying, checking and chasing in between.
This article is for operations and finance leads who have repetitive work and want a method before they talk to a supplier. We build and run automations, and once the process is chosen we work in this order:
- 01Measure how the process runs today.
- 02Choose rules or AI for each step.
- 03Choose how to build it.
- 04Run it alongside the team before it takes over.
- 05Go live and monitor it.
Which processes to automate first
Start with a process that runs often, follows rules your team can write down and costs something real when it goes wrong or runs late. It also needs one owner who can say what the correct outcome is. A single process that meets those tests is enough for a first release.
| Criterion | Good first candidate | Leave for later |
|---|---|---|
| Frequency | Runs daily or weekly, so the manual time adds up | Runs a few times a month; a clear form may do the job |
| Rules versus judgement | Most cases follow rules the team can state | Most cases depend on experience nobody has written down |
| Cost of an error | Errors cost money or time today and are easy to spot in a check | An automated error would take effect before anyone could catch it |
A high cost of error is a reason to automate, and a reason to keep a review step on the risky decisions. A process whose rules change every month needs stabilising first.
Four processes often come first in finance, HR and operations, and our back-office automation page describes how we build each one. As typical cases:
| Process | Why it fits | Where judgement stays |
|---|---|---|
| Purchase and expense approvals | Routing by amount, department or supplier is already set out in a policy | The approver decides; the flow routes, reminds and escalates |
| Bank reconciliation | Most transactions match an invoice on amount and payment reference | Partial payments, combined payments and unknown senders |
| Joiners and leavers | One HR trigger creates or revokes the same accounts for each role | Non-standard access requests and early contract ends |
| The shared inbox | Most messages fall into a known set of request types | Complaints and replies that commit the organisation to something |
Step 1: measure the current situation
Before building anything, record how the process runs today: how often it runs, how long a case takes, where work waits, how often it goes wrong and what an error costs. These numbers are the baseline you compare the automated version against, and they show where the time really goes.
Do this with the people who run the process, because the documented process and the real one usually differ. Check that you have:
- Volume per week or month, and when the peaks fall.
- Handling time per case from a sample of real cases, split into working time and waiting time.
- Every step, with the system it happens in and the person who does it.
- Recent exceptions, and why each one left the normal path.
- How often errors happen and what each one costs in rework, fees or risk.
- The form the input arrives in (API, file export, email, PDF or scan) and which systems have a documented API.
- The rules as written in the policy, the rules as the team applies them, and the owner who can change them.
Keep the sample of real cases with their correct outcomes. In step 4 it shows whether the automated version gets them right, and for AI steps it becomes the test set you run before every change. If AI steps look likely, our AI readiness checklist covers the data, risk and ownership questions.
Step 2: choose rules or AI for each step
Decide per step. Use a fixed rule when the input is structured and the correct outcome can be written as a condition. Use a language model when the step has to read free text, such as an email or a PDF, and check its output with rules. Keep a person on decisions that need judgement or cannot be undone.
Most processes end up as a mix. Take the steps you mapped in step 1 and place each one in this table.
| If the step | Use | Example |
|---|---|---|
| Works on structured data and the outcome follows a condition | A fixed rule | Route purchase requests above the approval limit to the finance director |
| Matches records on exact fields | A fixed rule, with unmatched items going to a person | Match bank transactions to open invoices on amount and payment reference |
| Has to read free text, a PDF or a scan | A model extracts or classifies, and rules validate the result | Read the totals from a supplier invoice, then check they add up and the supplier exists |
| Matches incomplete records, or drafts text for someone outside the team | A model proposes and a person confirms | Link a payment with a truncated reference to the likely invoice; draft a reply about a delivery date |
| Needs judgement across several systems, with a different path per case | An AI agent with scoped tools and approval steps | Investigate a disputed invoice using order history, contract terms and delivery records |
| Carries legal or financial weight, or cannot be reversed | A person, with the automation preparing the facts | Approve a payment run or reject a claim |
| Follows a rule that changes often or that nobody can state | Nothing yet: write the rule down and agree an owner | Discounts that depend on which account manager is asked |
Four questions for each step
- 01Is the input structured? Fields in a system or an API response suit rules; free text needs a model.
- 02Can someone state the correct outcome? If the answer is that it depends, ask on what. Each answer is another rule or a judgement call.
- 03Can a wrong outcome be undone? A misrouted email is quick to fix. A payment to the wrong account may not come back, so that step keeps an approval.
- 04Can the output be checked? A model's output is usable when rules can verify it, for example that totals add up. Where nothing can check it, a person reviews it.
Why rules come first
A rule does the same thing every time, costs very little to run and fails with a clear error. A model step adds a running cost per call, output that can vary between runs, and a test set of real cases to maintain. That is worth paying where a rule cannot do the job, which in back-office work mostly means reading documents and messages.
Rules have limits too: keyword rules for a shared inbox break on the first message phrased differently. For documents, our post on document parsing with LLMs covers schemas, validation and review queues.
A model inside a flow, or an agent
A model inside a flow reads or classifies one thing and returns a checked result, and the flow decides what happens next. An agent decides the next step itself: which system to query and which action to propose. That suits cases that each take a different path, and it needs scoped tools, approvals and a full log. If your step looks like that, read what an AI agent is and when one is worth building.
Step 3: choose how to build it
There are three routes. Use the workflow features of a system you already have when the process lives inside it. Use an integration platform when the flow crosses a few systems with documented APIs and your team wants to see and adjust it. Write custom code when volume, logic, reliability or data rules call for it.
| Route | Fits when | Watch for |
|---|---|---|
| Standard tool: built-in workflows in your ERP, accounting or HR system | The process stays inside one system, or two the vendor already connects | Limited exception handling and logic hidden in undocumented settings |
| Integration platform: a workflow tool that connects systems through their APIs | Several systems with documented APIs, moderate volume, a team that wants to adjust the flow | Error handling that has to be built on purpose, and flows only one person understands |
| Custom code: workers in Python or TypeScript in your infrastructure | High volume, complex matching, strict reliability, weak APIs, or AI steps with test sets | Needs an owner, tests and monitoring; non-engineers cannot change it |
Mixing routes is normal: a platform flow handles notifications while a custom worker does the matching. We choose per workflow, by volume, complexity and who maintains it. We build in n8n when your team should be able to read and adjust the flow; it can be self-hosted to keep data in your environment.
If the process lives in one system and its built-in workflow covers the rules, use that; you do not need a supplier. For the wider choice between buying software and having it built, our build vs buy decision guide has a cost comparison and a decision matrix.
Step 4: run alongside the team first
Before the automation takes over, run it next to the manual process on live cases. The team works as usual, the automation produces its own result for each case, and you compare the two. Differences show the exceptions you missed and the rules nobody wrote down, while nothing reaches your systems unchecked.
How we set this up:
- The automation writes to a review queue, where a person accepts, corrects or rejects each proposal.
- Each proposal shows its evidence, such as the source document and the matched record.
- Every approval is logged with who made it and what they changed. Corrections become new test cases.
- Accuracy per step and handling time are compared with the baseline from step 1.
- The process owner agrees in advance what each step must show, over what period and volume, before it runs without review.
Switch steps over one at a time as each meets its criteria. A routing rule that has matched the team's choices for weeks can run on its own, while a payment approval may stay with a person for good. Our post on human-in-the-loop design for AI agents covers approval checkpoints, confidence thresholds and audit trails in more depth.
Step 5: go live and monitor
Going live means the automation writes to your systems without a person checking each case, for the steps that met their criteria. From then on it needs the care of any system your operation depends on: alerts when a run fails, a queue where failed items wait, and regular checks that the output is still right.
- Alerts go to a named owner when a run fails or a system returns errors.
- Failed and uncertain items wait in an exception queue with the reason attached, after a limited number of retries.
- Every run is logged, so you can trace what happened to a specific invoice or request.
- Someone checks volumes and queue sizes each week; a sudden change usually means something upstream changed.
- For AI steps, the test set runs before every prompt or model change.
- Staff can pause the automation and fall back to the manual process without a deployment.
Suppliers change invoice layouts and systems rename fields, so each workflow needs documentation and an owner. Once the first process is stable, take the next candidate from your list; the connections and review screens carry over.
Common mistakes
Most costly mistakes happen before the build: automating a process nobody has mapped, skipping the baseline, or putting a model on a step a rule could handle. After go-live, the usual failure is an automation with no owner, alerts or log, which stops working when an upstream system changes and nobody notices.
- Automating the process as documented, without sitting with the people who run it.
- Starting with the largest or most visible process, where every rule is contested.
- Automating a step nobody needs, which should have been removed.
- Using a model where a rule would do, which adds running cost and variation.
- Screen automation on a system that has a documented API, which breaks when the layout changes.
- Full automation from the first day, with no review queue and no logged approvals.
Our automation page describes how we map, build and run these systems.
Frequently asked questions
What does business process automation cost?
The cost depends mainly on the number of systems involved and the quality of their APIs, the number of rules and exceptions, whether any steps need AI, and how many review screens people need. Running costs come on top: hosting, platform licences, model usage and maintenance as systems change.
Compare it with the manual effort you measured in step 1. We scope the build and the running costs during discovery, so both sit next to that figure before you decide.
What is the difference between RPA and AI automation?
RPA (robotic process automation) works through other software's screens, clicking and typing along fixed steps the way a person would. It helps with older systems that have no API, and it breaks when a screen changes. AI automation uses language models to read and classify unstructured input, such as emails and documents.
The two can work together: a model reads an invoice and a screen script enters it. Where a system has a documented API, we use the API, because it survives screen changes.
Do I need AI to automate a process?
Often you do not. Approvals, joiners and leavers, scheduled reports and most bank matching run on rules and integrations alone. AI earns its place where a step has to read unstructured input, such as emails or documents in varying layouts, or where the next action depends on judgement across several systems.
Can we automate a process when a system has no API?
Usually. The options are file exports, direct database access, email-based routes and, as a last resort, screen automation. Each is less reliable than an API, so check the route during step 1.