What does it cost to automate a business process?

There is no fixed price for "an automation". The costs depend mainly on the number of steps, the number of systems involved, the exceptions the solution must recognise and the licences it needs. An Excel query that combines files and a software robot that processes orders across three systems therefore differ greatly in price. Below you see which cost items there are, how they work out in four scenarios and how to build your own business case with a short template.

Why one fixed price is misleading

Anyone who quotes one price for every automation calculates with an average process. Your process is rarely average. Four factors determine most of the costs:

• The number of steps and decision rules. Every step must be built, tested and maintained later.
• The number of systems. Every system, such as the ERP (the business system for orders and administration), the PDM system in which engineering manages drawings and revisions, or a customer's portal, brings its own login, its own error messages and its own updates.
• The exceptions. An order without a customer number or with an unknown item needs a rule: what does the automation do itself, and what goes to an employee?
• The licences. A query in Excel usually needs no extra licence. An unattended software robot (see scenario 2) does need a licence, and often its own machine too.

The quality of the input (fixed Excel columns or varying PDFs) and whether there is a test environment also count. A fixed price is only reliable once the analysis is done and the assumptions are on paper. A fixed price before the analysis contains a margin for uncertainty, or exclusions that you only come across later.

The cost items at a glance

Maintenance keeps what exists working; a change adds something. Agree in advance where the boundary lies, otherwise every invoice becomes a discussion. You can read what maintenance involves exactly in what maintaining a software robot costs.

Four scenarios side by side

The four scenarios use the same example company. This shows that one question ("can we automate order entry?") can get four different answers, with very different costs.

1. Simple local data processing

The work stays in Excel. Power Query is the part of Excel that you use to get and transform data. Power Query records the steps as a query that you can refresh later. In the example, a query combines all Excel orders of the day, puts the columns in a fixed order and marks item numbers that are not in an export from the ERP. If the ERP has an import function, an employee imports the result in one go.

What determines the costs: the number of file layouts and how often customers change them. Cost items: mainly analysis and build, a short test, little infrastructure. If you already use Excel, you usually need no extra licence.

The limitations are real. The PDF orders stay manual work, and an employee starts the query and checks the result. A macro (VBA) can do more, but Office blocks macros by default in files that come from the internet, such as email attachments. Also record who manages the file: a solution that only one colleague understands becomes a risk when that colleague leaves. You can read more about this route in Connecting Excel to ERP.

2. A software robot that uses one application

A software robot operates screens like an employee: it opens windows, reads fields, clicks and types. This is called RPA (robotic process automation). In the example, the robot takes the combined Excel file and enters each order through the screens in the ERP. An employee starts an attended robot on their own computer (attended RPA). An unattended robot (unattended RPA) starts automatically and does the work without an employee having to be present, usually on its own machine. It follows predefined rules. On an error or exception it can stop, send an alert or put the case to an employee. The run stays traceable.

What determines the costs: the number of screens and fields, and how stable those screens are. Cost items: analysis, build, test, a robot licence and, for an unattended robot, a machine. Maintenance is needed after every update of the application, because a changed screen can make the robot stop.

The licence costs can start small here. With the free Power Automate licence for work and school accounts, you can build and run desktop flows (automations that operate screens) locally, started by an employee (attended). Sharing, central management and unattended runs need paid licences. They are in the table further down.

3. A process across several systems

This is the full example. The robot reads the mailbox, takes the order data from the PDF or the Excel file and looks up the customer and the items in the ERP. In the PDM system, it checks whether the revision on the order is the released revision. Then it enters the order and sends an order confirmation with the delivery date. Some customers want that confirmation in their own supplier portal; the robot fills it in there. It puts orders with an exception, such as an outdated revision, with the reason, in a review queue for the inside sales team: the list of cases that an employee reviews. Every day, an employee checks in 15 minutes whether all orders have been processed.

What determines the costs: the number of systems and handovers, the variation in the input and the number of exceptions. Getting data out of PDFs is harder than out of fixed Excel columns: more cases drop out, and a person checks more often. Recognition with AI can have usage costs. In Power Automate, AI Builder, the service that gets data out of documents, uses credits, each type of recognition at its own rate. According to Microsoft, the 5,000 credits per month with a Premium licence expire on 1 November 2026; after that you buy Copilot Credits. Cost items: all items from the table, with a larger share for analysis and test. Every system, including the customer's portal, needs an account with the right permissions.

4. An extensive integration with exception handling

Here the solution works through integrations as much as possible. An integration exchanges data without a screen, usually through an API that the supplier of a system offers. In the example, an integration creates the orders directly in the ERP. A queue keeps track of which step each order is in. On a technical failure, a new attempt or an alert follows. An order with an exception goes to the review queue with the reason. Every step goes into a log, so that afterwards you can see what happened to an order.

What determines the costs: the number of integrations, the quality of the API documentation, the error handling, the security (keys, certificates, permissions) and the number of test environments. Cost items: mainly build and test, then hosting, monitoring and sometimes an API module or integration platform. A documented API usually changes less often and less unexpectedly than a screen. Maintenance per change is therefore easier to plan.

Whether this scenario is worth it depends on the volume and on the damage when an order goes wrong. A comparison between robot and integration is in RPA or API integration: which is the best choice?

Worked example: a budget in hours for scenario 3

Below is a budget for the full example. The hours are assumptions and not a standard. A different ERP, a different developer or different orders give different hours. The point is the structure: which items there are and how they relate to each other.

With these hours, you calculate the costs with your own rates:

One-off = 144 × T + 30 × K

Per year = 12 × (L + I + 4 × T)

• T: the hourly rate of the developer. If you build it yourself, this is your own cost price per hour.
• K: what an hour of your employee costs: gross salary plus employer's costs, divided by the productive hours.
• L: licences per month.
• I: the machine or hosting per month.

The 4 hours of maintenance per month are 48 hours per year. How they are built up is in the worked example for a year of maintenance.

Note the ratio. Analysis and testing together are 40 of the 144 hours. That seems a lot for work that delivers no new functions. But that is exactly where you find the exceptions that otherwise show up after go-live, when they are more expensive to fix.

What licences cost

Licence prices are only shown here if the supplier publishes them itself.

Read the table with these notes:

• With Power Automate, the licences stack. A Process licence does not replace a user licence: Microsoft writes that a user with Premium must first register the machine. If you do not have a Premium user yet, the first unattended robot at list price therefore costs at least €13.00 + €130.00 = €143.00 per month, excl. VAT, plus the machine. If you want two desktop flows to run at the same time, you need two Process licences.
• Paying per run suits a small number of runs. A premium cloud run is a run of a cloud flow with premium connectors. A cloud flow is an automation that runs in the Microsoft cloud; a connector is a ready-made integration with another system. Runs of flows with only standard connectors cost nothing. Microsoft calls paying per run suitable for seasonal work and flows with few runs, and recommends a fixed monthly amount for flows with many runs. How many runs your process counts depends on the build: one run can process one order or all orders of a morning.
• With UiPath, the number of runtimes determines how many automations run at the same time. The number of runtimes that you assign to a machine is the maximum number of automations that run there at the same time. An attended robot needs a user licence.
• List prices are not a quote. Microsoft states that the prices shown are for marketing purposes only and can differ from the actual catalogue price. The amounts for paying per run are only in dollars on Microsoft Learn. The UiPath page also gives amounts in dollars and does not say whether they include or exclude tax. UiPath also reports that a new version of the Basic plan is coming soon.

Do not forget the licences outside the platform. Ask your ERP supplier whether a robot account needs its own user licence, and whether API access or an import module costs extra. You can read a comparison of the two platforms in UiPath or Power Automate.

Why low build costs do not mean low total costs

A quote mainly shows the one-off costs. You only see what you really pay when you count the ongoing costs over the lifetime:

Total costs over N years = one-off + N × ongoing per year

Two things make a cheap build expensive. First: a robot without good error handling and a log is quicker to build, but after that every failure means searching for the cause. Errors that nobody sees may only come to light at the customer. Second: the route with the lowest build costs often has the highest ongoing costs. A robot that works through screens can start without cooperation from the ERP supplier. But it pays for a licence and a machine every month, and needs maintenance after every screen change.

After one year, A is still cheaper in hours. After 20 months, both quotes are equal in hours (60 + 20 × 4 = 100 + 20 × 2 = 140 hours). After three years, B is cheaper, even before the licences of A count. If your ERP has no usable API, or the API module costs a lot, the outcome can reverse. So calculate both routes, over the period in which you expect to use the process.

How to make your own business case

A business case does not have to be a report. One page with these parts is enough to base a decision on and to compare quotes.

You can read how to calculate the payback period, and when the outcome is negative, in when automation pays off for a small business. If you first want to see whether a process qualifies, go through the four questions on the services page: four short questions with which you judge for yourself whether a process is suitable.

Decision framework: what to look out for

Questions to ask internally

• How many variants of the input are there really? Count the senders and the file layouts.
• Which systems must be involved, and does each system have a test environment?
• Which exceptions do we know, and what does the employee do then?
• Will the process or one of the systems change within two years?
• Who becomes the owner of the automation after go-live?

What weighs most

Licences are fixed amounts that you know in advance. The number of systems and exceptions is the uncertain factor. They determine the build, test and maintenance hours, and they often only become visible in the analysis.

When outside help makes sense

A short analysis by someone who automates processes more often helps if you are in doubt between a robot and an integration, if you cannot compare quotes well, or if nobody internally has an overview of all exceptions. In any case, ask for a quote in which one-off hours, licences, infrastructure and maintenance are listed separately, with the assumptions included. Also ask what happens if an assumption is wrong, for example if there turn out to be more file layouts.

What to take away

Start with the template and first fill in volume, time and exceptions: they determine the price more than the technology does. Only then does it make sense to compare quotes, and then over three years instead of only the build.

Sources

• Microsoft: Power Automate pricing (in Dutch) (accessed on 24 October 2026)
• Microsoft Learn: Types of Power Automate licenses
• Microsoft Learn: Pay-as-you-go meters (accessed on 24 October 2026)
• Microsoft Learn: Licensing and AI Builder credits (accessed on 24 October 2026)
• UiPath: Plans and pricing (accessed on 24 October 2026)
• UiPath Documentation: Robot licensing
• Microsoft Learn: What is Power Query?
• Microsoft Learn: Macros from the internet are blocked by default in Office