Key takeaways
- Budget for the whole workflow, including integrations, human review, retries and ongoing work.
- Define what “completed” means before calculating the cost of a case.
- Keep launch costs separate from operating costs, and look at cost alongside quality and turnaround time.
An invoice reaches your shared inbox. An agent reads it, looks up the purchase order and prepares a match. Then it finds a discrepancy, asks for another document and hands the case to someone in finance.
What did that case cost?
It’s not just the model. You also pay for infrastructure, paid services, human review, retries and ongoing support, while the cost of launching the workflow should be kept separate.
Then measure the operating cost against completed cases, including failed attempts and cases that still need attention.
The FinOps Foundation’s approach to unit economics separates technical costs, such as cost per token, from the cost of actual business work. The example below applies that idea to an invoice-triage agent. The numbers are illustrative, not a fixed price for running an agent.
Agree on what the agent is completing
In our fictional workflow, the agent extracts invoice details, checks them against a purchase order and prepares the evidence for a finance decision. It does not approve the payment.
A completed case should have the required fields, a reliable purchase-order match and any issues the reviewer needs to resolve. If someone still has to repeat the checks, the case is not complete.
Completion is different from automation. A person may fix the agent’s work and complete the case. It still counts as completed, but the repair time is part of the cost.
A case can also be handled without human help and still be wrong.
So keep completion, automation and output quality separate. Otherwise, a smaller review queue can look like progress while mistakes move downstream.
Separate the work to launch from the work to operate
Before launch, someone needs to connect the inbox and ERP, set up access, define how to handle exceptions and build an evaluation set. These are project costs, even if your existing team or infrastructure does the work.
The integration also needs its own estimate. Reading a purchase order is different from preparing an authorized update. If MCP is part of the architecture, tool design and identity decisions can affect the work involved.
Keep these setup costs separate in the business case. You can spread them across the operating period if that works for your financial model, but be clear about how you did it.
Don’t compare a pilot’s operating cost with a production estimate that also includes implementation costs.
Follow the recurring costs through a case
For invoice triage, the main costs are:
- Model use: extracting and understanding the invoice, plus any later model calls.
- Workflow infrastructure: compute, queues, storage, document processing and retrieval.
- External services: paid APIs, software licences and connectors.
- Human work: approvals, exceptions, quality checks and corrections.
- Operation and maintenance: monitoring, evaluations, integration fixes, prompt changes and incident response.
Retries are already part of these costs. A failed attempt may use inference and compute, for example. Track it as a retry so you know what happened, but don’t add the same cost again.
The same applies to staff time. If an engineer’s time is already included in a shared support cost, don’t count it again as dedicated maintenance.
Use a completed-case calculation you can explain
Here is one deliberately simple example. Every number below is an invented assumption for illustration, not a market benchmark or a Moring price. Assume the workload begins with no backlog and no cases are reopened during the period.
- Incoming cases: 1,000.
- Cases completed to the defined quality threshold by period end: 900.
- Operating cost for that workload: $4,500, including inference, infrastructure, review, retries, unresolved work and the chosen allocation of engineering time.
- Operating cost per completed case: $4,500 ÷ 900 = $5.
The 100 unfinished cases still cost money, so their costs stay in the $4,500 total. If a person fixes a case and it is completed, it can still count as a completed case. The person’s time is already included in the cost.
Now suppose reviewers need more time, but the number of completed cases stays the same. The cost per completed case goes up, even if the model cost stays the same.
If the extra review helps complete more cases, both the cost and the number of completed cases will change. So look at both when measuring the impact of the extra review.
The $4,500 here is just a total example. Your own data will show how much went to the model, infrastructure, review and other costs.
In a real operation, the calculation can get a little harder. You may already have a backlog, some cases may be reopened, or work may move from one reporting period to another.
Agree with finance on how you want to count these cases and use the same method each time. This example does not include launch costs, so keep those separate in the business case or explain how you are allocating them.
Make the next budget discussion about a specific tradeoff
Suppose review time is going up. You could improve extraction, accept fewer document types or give reviewers better evidence. Switching to a cheaper model is another option, but it could also create more rework.
Or suppose inference costs are rising because the agent keeps fetching the same purchase-order history. The question then becomes: can the workflow avoid doing the same work again without using old or unauthorized information?
Tracing the agent’s steps alongside its outcomes helps you see where the cost is coming from. A token total alone won’t tell you why a case took a particular path.
Shared infrastructure adds another question. You can look at the extra cost caused by the workflow, or allocate part of the shared infrastructure and staff costs to it. Both are useful, depending on what you are trying to measure.
A checklist before you commit
- Can reviewers use the same definition of a completed case when checking real cases? If they disagree, clear it up before counting completed cases.
- Does the estimate include unresolved work and human corrections?
- Are setup costs separated from recurring operation?
- Can you trace the shared-cost allocation to its underlying bill or staff-time estimate, without counting the same expense twice?
- Have you tested the estimate against a harder case mix and higher review demand?
- Can you examine quality and turnaround time for the same cases used in the cost calculation, rather than comparing unrelated dashboard totals?
- Is someone responsible for maintaining the integration and evaluation set after launch?
As you plan the move from a pilot to an operating platform, those answers make the budget easier to defend and improve.
You do not need a perfect forecast to begin. You need a model that makes its assumptions visible, so the first month of real work tells you what to change rather than merely whether you overspent.
