UiPath pricing: one published price, and a quote for everything else

The short version

• UiPath's public pricing page carries a monthly figure for the Basic tier and a 'contact sales' route for everything above it.
• Basic is capped at two robots, which is enough to prove one process works and not enough to run a department.
• The licence is the visible half of an RPA bill. The people who build and repair the automations are usually the larger half.
• Any first quote is the smallest contract the relationship is designed to have, so renewal terms belong in the first negotiation.
• If the system you want to automate has an API, a small service you own will beat a robot on cost and on how clearly it fails.

What does UiPath publish, and what does it hold back?

One price. UiPath's self-serve pricing page carries a monthly figure for its entry Basic tier, and that is the only numeric monthly price on the page. Every tier above Basic routes to a sales conversation instead. If you arrived looking for a per robot or per developer list price for the tier a real programme would run on, it is not published. Treat any figure you find on a comparison site as somebody else's negotiated deal rather than a list price.

The Basic column tells you more than its price does. The same plan comparison table caps the number of robots in Basic at two, and caps users on the row beside it. Two robots is a budget for proving that one process survives contact with production. It is not a budget for running a finance back office. So the one published price is the price of an experiment, not of a programme, and the tier you would actually buy is the tier with no number next to it.

There is a structural reason the page stops there, and the company's own financial reporting shows it. UiPath reports its subscription business as annualised invoiced amounts per solution SKU. The bill is assembled from parts: who builds automations, what runs them unattended, what reads documents, what orchestrates and audits the whole thing. A quote is the sum of your particular parts. There is no single number that would be true for two different buyers, which is why no single number gets printed.

What are the units you are actually paying for?

Seats, runtimes and consumption. Almost every RPA quote decomposes into three kinds of line: people who build automations, machines that run them, and metered services the automations call while they run. Insist the quote is broken out this way before you compare it to anything, because vendors bundle these differently and a cheaper headline usually means a cost moved into a different line.

Developer seats are the easiest to underestimate. One person builds the pilot. A programme touching four departments needs people who can maintain what that first person built, and the seat count then follows headcount rather than process count. Ask whether somebody who only fixes existing automations needs a full developer seat, because the answer changes the shape of the second year.

Runtimes split into attended and unattended, and that distinction matters more to the bill than it does to the demo. An attended robot sits with a person and runs when they ask it to. An unattended robot runs on a schedule on a machine nobody is watching, which is the thing you want for overnight work and the thing that costs more. Count the processes that must run with no human present. That number drives the quote.

Metered services are where year two surprises people. Document processing, model inference and anything agentic tend to be priced per page, per call or per unit of compute, so the cost grows with volume rather than with licence count. A quote built on this quarter's volume is a quote for this quarter's volume. Ask for the unit price and the overage rate, not just the included allowance.

Why is the licence usually the smaller half of the bill?

Because automations are software, and software needs maintainers. The licence is fixed, negotiated and visible. The engineering time around it is variable, invisible at the point of purchase, and in most programmes larger. Nobody sends you an invoice for it, which is exactly why it gets left out of the business case.

RPA automations break for reasons that have nothing to do with your code. A vendor ships a UI change and a selector stops matching. A supplier redesigns an invoice template. A login page adds a second factor. A report gains a column. None of these are defects you wrote, and all of them stop the robot tonight. Either budget for a person who owns that queue, or accept that automations go quiet and nobody notices until a month end closes late.

If you want a defensible number for that person, use published wage data rather than a vendor's calculator. The US Bureau of Labor Statistics publishes wage figures for software developers and for quality assurance analysts and testers, most recently from its May 2025 survey of employers. That is a better basis for your market than a return on investment slide built by somebody selling licences. For a handful of automations the realistic figure is a fraction of one engineer, not a team, but it is not zero.

What do UiPath's own filings tell a buyer about pricing?

That the commercial model expects your spend to grow, and that the renewal is the real negotiation. UiPath reports the net expansion of recurring revenue from its existing customers over the preceding twelve months. A company features that metric when it expects growth to come from accounts it already holds. Read it as the vendor telling its investors, in public, that your first contract is the smallest one the relationship is designed to have.

The filings also show how the vendor counts you. The annual report for the year ended 31 January 2026 gives customer counts grouped by annualised renewal run-rate, and separately a count of unique paying customer accounts, where one organisation counts once and free and trial users are excluded. Two useful things follow. Free and trial access exists, so you can test on your own systems before you pay anybody. And your run-rate decides which band you sit in, which is a fair proxy for how much attention and flexibility your account will get.

Use that while you still have leverage. Ask for renewal pricing, the annual uplift and the price of the tier above yours in writing during the first negotiation. The leverage you hold as a prospect does not come back at renewal, by which point your finance processes are already running on the platform and switching is a project rather than a decision.

What drives the bill, and what should you ask before signing?

When is UiPath the wrong thing to buy?

When you have two processes and an API. RPA earns its licence by driving software that will not let you in any other way: a desktop client, a vendor portal with no integration, a terminal screen nobody will modernise. If the system you want to automate exposes an API, a small service you own will beat a robot on cost, on speed and on how loudly it fails when something changes. Clicking a UI to reach data that is already available over HTTP is work you are paying twice for.

It is also the wrong shape when the work is reading rather than clicking. A robot follows a fixed path well. It judges badly. An unusual invoice, an email that contradicts its own attachment, a case that needs someone to decide: none of that is a path, and wrapping it in a deterministic script produces either a brittle automation or a queue of exceptions that a human works anyway. That work wants a model with a review step and an audit trail, which is a different build with a different cost base.

And it is the wrong purchase when the honest scope is small. If you can name three processes and each saves a few hours a week, an enterprise automation platform is a lot of commercial surface for the value, and most of your first year goes into the platform rather than the processes. Write the three automations, measure what they actually save, and buy a platform when governance becomes the hard part instead of the automation. That usually happens when the count of automations passes what one person can hold in their head, not when a vendor says it should.

How should you build the first year budget?

In four lines, with the vendor's number as only one of them. Licences for the tier you will genuinely run, not the tier that fits a pilot. Build time for the first wave of processes. Run cost for the person who keeps them working. Then a contingency for the volume growth and the uplift the renewal will carry.

Do it in that order, deliberately. Pick the processes first, count the ones that must run unattended, then ask for a quote against that list. Teams who ask 'what does it cost' before they know what they are automating get a tier recommendation rather than a price, and a tier recommendation always rounds up. Arriving with a list changes the conversation from which plan suits you to what your plan costs.

Then test the smallest real version. Free and trial access exists, so the question 'does this survive our environment' can be answered before anybody signs anything. Run it against your actual portals, your actual logins and your actual document formats, not the vendor's sample data. Nearly everything you learn in the first year will be about your own systems rather than about the platform, and that learning is cheaper before the contract than after it.

In what order should you price it?

1. Name the processes in writing before you ask anybody for a price.
2. Count the ones that must run with nobody watching. That number moves the quote more than headcount does.
3. Ask for the quote itemised by seat, runtime, orchestration tier and metered service.
4. Add build time for the first wave, and name the person who owns repairs.
5. Get the renewal uplift and the next tier's price in writing while you are still a prospect.