What an automation estate actually costs

Most teams can tell you what their automation platform costs per year. Almost none can tell you what a single flow costs per month. The gap between those two numbers is where the money quietly goes.

The annual licence is a line in a budget. It gets negotiated, approved, and then forgotten. What happens afterwards (flows added, runs multiplied, model calls wired in) never comes back to that line. It arrives elsewhere, in smaller invoices that nobody adds up.

The three invoices nobody adds up

An automation estate bills you in three separate places, and they almost never land on the same desk.

The platform licence. Power Automate premium connectors, an n8n instance, a Make subscription. This one is visible, budgeted, and usually owned by IT.

The consumption underneath. Storage, API calls to the systems being automated, egress, the paid tier of a connector that got switched on for one flow and stayed. This lands on the cloud bill, which is owned by someone else.

The model calls. Any flow that summarises, classifies, extracts or drafts is calling an LLM. That bill arrives from a third provider, in one global line, and it is owned by a third person.

Three invoices, three owners, no shared denominator. Ask each of them what automation costs and all three answers will be honest and incomplete.

Run volume is the part that scales without asking

A flow that runs on a schedule has a predictable cost. A flow triggered by an event does not: it costs whatever the business decides to throw at it.

This is the mechanism worth understanding, because it is the one that surprises people. A flow built to handle a hundred invoices a month is the same flow when the company doubles its invoicing. Nobody rebuilt it, nobody reviewed it, and its cost line doubled without a single decision being taken.

The practical consequence: cost per run matters more than cost per month. A flow at €200 a month running 40,000 times is cheap and healthy. A flow at €80 a month running 300 times is expensive per unit, and worth a look. The monthly figure alone cannot tell those apart.

Model calls arrive as one global line

If a flow calls an LLM, the provider bills you for tokens (input and output), not for flows. What arrives at the end of the month is one amount for the whole organisation.

That is fine until you want to answer any of these:

• Which automation is responsible for most of this?
• Has it grown because we are doing more, or because a prompt got longer?
• Which team should this be charged back to?
• Would a smaller model do the same job here?

None of those can be answered from a global line. They can all be answered if each call is tied back to the flow that made it and to the person who owns that flow. That attribution is the whole game, and it is not something the provider can do for you: only your side knows which flow made which call.

Working out a cost per flow, by hand

You do not need a tool to do this once. You need a spreadsheet and an afternoon. Doing it manually is also the fastest way to understand what a tool would have to do for you.

Step 1. List the flows. Export the inventory from each platform. Include the disabled ones: a disabled flow still occupies a licence seat in some plans, and it still holds a connection.

Step 2. Get the run counts. Thirty days is enough. You want runs and failures per flow, not just totals.

Step 3. Split the platform cost. Take the licence total and divide it across flows in proportion to their runs. It is an approximation and it is defensible: it puts the cost where the consumption is. Flat-splitting per flow instead would make a flow that runs twice a year look as expensive as one that runs every minute.

Step 4. Add the direct costs. Any paid connector, any storage, any per-call API that belongs to one flow and not to the others.

Step 5. Attribute the model calls. This is the hard step and there is no shortcut: you have to go into the flows that call a model and read what they send. Note the model, estimate the tokens, multiply by the provider rate. Do it for the ten biggest first, the tail will not change the picture.

Step 6. Divide. Cost per run, per flow. Sort descending.

That last sort is where the afternoon pays for itself. The top of the list is almost never where people expect it.

What the number changes

Once a flow has a cost, three conversations become possible that were not before.

Arbitration. “Do we keep this?” is unanswerable without a number and obvious with one. A flow that costs more per run than the manual task it replaced is not an automation, it is a habit.

Chargeback. A cost per flow rolls up into a cost per team. Finance stops receiving one opaque invoice and starts receiving something a department head can be asked about.

Model choice. Attribution turns “we should use a cheaper model” from an opinion into a calculation. Sometimes the answer is that the expensive model is worth it. You cannot know that without the per-flow figure.

The part that does not fit in a spreadsheet

The afternoon exercise gives you a snapshot. The problem is that an estate is not a snapshot: flows get added weekly, run volumes drift, and prompts get longer. A number computed in August is wrong by October, and nobody has an afternoon every month.

That is the case for making it continuous rather than periodic, which is what we are building Synoptial to do. But the exercise is worth doing by hand first, whatever you use afterwards. It tells you which of the three invoices is actually the problem in your organisation, and that answer is different in every company we have talked to.

Start with the sort by cost per run. Everything else follows from what you see at the top.