The gap between AI operations and finance is a unit economics gap. Treat it like alignment and it never closes.

It is a unit-economics gap, not a vocabulary gap. Operations writes a memo about an AI agent that will run a workflow 500 times a week and save 8 hours per run. Finance is asked to approve a $300K to $700K total contract value (TCV) that mixes Studio seats, Robot licenses, Orchestrator, document AI transactions, AI Center compute, and a separate implementation SOW. Nothing in that bill is the workflow finance is being asked to approve. There is no line that says 'claims_intake produced $187K in March at a runtime cost of $4,463.' Finance has nowhere to put the AI-ROI claim against the AI-cost reality, so the deal stalls or the deal happens and the post-mortem is unwinnable. The fix is a bill whose line items are workflows, with a unit (a minute of runtime) finance can cross-multiply against the unit of business value (a claim, a renewal, a reconciliation).

Two reasons. First, UiPath bills on capacity not consumption. An Unattended Robot license is roughly $13K per year per concurrent slot regardless of whether the robot ran for 8 hours or 8 minutes that month. Finance gets a fixed annual fee that does not move when throughput moves, which means the unit cost of any one workflow is undefined; it changes every time another workflow is deployed onto the same robot. Second, the per-execution telemetry that does exist (Orchestrator's queue items table, Insights dashboards) is in a separate place from the bill. To answer 'what did claims_intake cost in March,' someone in the RPA Center of Excellence has to export a queue report, allocate a fraction of the Robot license to that workflow based on duration, allocate a fraction of Orchestrator, allocate a slice of AI Center, and rebuild a per-workflow cost in a spreadsheet. That spreadsheet is the workaround for the gap. It does not actually close it because finance cannot audit it; only the RPA team can.

It is one Next.js route handler at apps/web/src/app/api/billing/usage/route.ts. The runtime (the open-source Terminator executor) writes execution_duration_seconds to the workflow_executions table on every run, alongside workflow_id, status, and started_at. The route handler queries that table for the last 365 days, groups by (workflow_id, year-month), multiplies durationMinutes by a single constant RATE_PER_MINUTE, and emits a JSON with the shape { ratePerMinute, months[].workflows[].{name, executions, totalMinutes, cost} }. The UI at /billing pulls that JSON and renders it as the customer's bill. The same shape feeds the customer's internal cost-per-process dashboard. There is no allocation step, no per-license slicing, and no spreadsheet. The bill is the runtime telemetry, multiplied by a rate.

The public list rate is $0.75 per minute of executor runtime, plus a $10K turn-key program fee that converts to credits on the same meter. In the source code, the rate is a single constant at the top of the billing route; per-customer contracts substitute different constants without changing any of the data shape. A workflow that runs 10 minutes a day for a year costs roughly $1,575 in runtime at the list rate; one that runs 8 hours a day costs roughly $145K at the list rate, which is the territory where finance starts asking whether the workflow should be re-architected with an API instead of a desktop agent. That conversation is healthy; it is what unit-economics visibility unlocks.

Most enterprise AI contracts (RPA, agent platforms, copilots) bill on seats, capacity, or token volume. None of those line items maps cleanly to a workflow or a process. A CFO presented with such a bill has two options: trust the operations team's per-workflow ROI math (which is built bottom-up in a spreadsheet from non-billed telemetry), or treat the entire contract as overhead and exclude it from process P&L entirely. Both paths are why enterprise AI ROI conversations feel disingenuous. A meter that emits a per-workflow line item gives the CFO a third option: treat each automation as a unit of cost-of-goods-sold, exactly the way infrastructure cloud costs are treated since AWS published per-service usage in 2010. The accounting treatment is not new; the data shape is.

Yes, and it is the point. The /billing UI authenticates against Clerk, scopes to the org via the row-level security policy on workflow_executions and deployed_workflows, and serves the JSON straight from Postgres. A finance user with org access reads the same page the RPA Center of Excellence reads. The per-workflow cost line, the per-month total, and the running 365-day history are all there. Finance does not need a quarterly export from operations; they pull the page. That is the structural shift that closes the gap. It also means the operations team stops being the translation layer between the bill and the business case, which is most of the reason these conversations were stuck in the first place.

The program fee is a one-time onboarding cost; it converts to runtime credits with a small bonus, so on the meter it appears as a prepaid balance that draws down workflow by workflow. From a finance perspective it is amortized across the workflows that run against the credit, not a separate capital line. Implementation services beyond the program (custom integrations the open-source Terminator SDK can't cover, or compliance-specific deployments) are billed as time-and-materials with a separate line and a separate SOW. The runtime meter never mixes with services billing; that separation is what keeps the per-workflow unit cost auditable.

Three places. First, workflows with extreme variance in duration (a 10-second happy path versus a 4-minute exception path) make per-workflow averages noisy; finance gets a stable monthly total but per-execution unit cost swings, and the operations team has to break the workflow into named variants to get clean attribution. Second, workflows that share state across runs (queues that drain in batches, end-of-day reconciliations) bill as the long single execution they actually are, which can spike a monthly total even though the per-claim cost is unchanged; the right fix is to refactor the workflow, not the meter. Third, very high concurrency at peak (1,000+ simultaneous executions) compresses unit cost less than seat-based RPA does at the same scale; the crossover where UiPath's flat-license amortization beats Mediar's meter is around the territory of always-on, always-saturated robots in 24x7 operation. For long-tail and burst workloads, which is most enterprise RPA, the meter wins.