AI in a finance team costs roughly 30 to 90 dollars per user per month in licences, plus usage costs that for typical finance work stay in the tens of euros per month, plus an implementation load that is the largest cost item for the first three months. You do not measure the saving in hours saved but in cycle time, error rate, and work you no longer hire in.
Rates updated 10 September 2026. AI vendor pricing changes every quarter and many rates are introductory with an end date. Always check with the vendor before you submit a business case.
Every CFO ends up asking the same two questions. What does this cost per month, and how will I know later whether it delivered anything. The first is a calculation. The second is harder, and it is where most organisations come unstuck: MIT studied three hundred public AI deployments and concluded that 95 percent of pilots showed no measurable impact on the P&L. The PwC CEO Survey of January 2026 found something similar: 56 percent of CEOs saw no measurable ROI over the past year.
That is not an argument against starting. It is an argument for deciding up front what you are going to measure.
The three cost layers
An AI budget that only looks at licences is wrong. There are three layers, and the third is the biggest.
Layer 1: licences per user
This is the number on the quote. As of September 2026, in dollars because that is how vendors bill:
| Product | Price per user per month | Note |
|---|---|---|
| Microsoft 365 Copilot | $30 | add-on on top of an existing M365 licence |
| Microsoft 365 Copilot Business | $18 to $21 | up to 300 users, promotional rate through end of 2026 |
| ChatGPT Enterprise | around $60 | seat price, usually with a seat minimum |
| Claude or ChatGPT team tier | $25 to $30 | per user, no Office integration |
Watch the trap with Copilot: the $30 is an add-on. Your underlying Microsoft licence comes on top, and that went up on 1 July 2026 (E3 from $36 to $39, E5 from $57 to $60). All-in cost per user therefore lands between $50 and $90 rather than at $30.
Layer 2: usage per token
The moment you build rather than buy, you pay per processed text instead of per person. That maths differently and is often surprisingly cheap for finance work. Current rates per million tokens sit in the model comparison; the range runs from about one dollar for a light model to five for a heavy one on input.
Translate it into something recognisable. A million tokens is roughly 750,000 words, a stack of 1,500 pages. Concrete finance examples:
- Bulk classification of bank transactions. A transaction plus context is around 200 tokens in and 50 out. At 2,000 transactions a month on a light model you land at roughly 40 cents a month. That is not a typo.
- Variance commentary at month-end close. A 20-page reporting extract in, two pages of commentary out, twelve times a year, on a workhorse model: a few euros a year.
- Having a 500-page contract portfolio read. Around 350,000 tokens in a single request on a heavy model, so under two dollars per pass.
Two things halve those costs again and are routinely forgotten. Cache hits are billed by Anthropic at ten percent of the input rate, which matters as soon as you send the same knowledge base along every time. And the batch API halves both rates for work that does not need an immediate answer, such as overnight classification.
The conclusion for most SME finance teams: usage cost is not your problem. Licences and implementation are.
Layer 3: what it costs your own people
This is the layer that breaks business cases, and it rarely appears in the budget.
- Setup. Building the knowledge base, writing instructions, wiring integrations, arranging permissions. Count on 40 to 80 hours for a serious first use case
- Governance. Drafting policy, setting tiers, arranging data processing agreements, keeping the AI inventory current. A one-off 20 to 40 hours, then maintenance
- Learning curve. A team that uses AI seriously loses time in the first month before it gains any. Count on two to four hours per person of real practice, not a webinar
- Checking. AI output on numbers has to be checked. That checking time does not disappear and belongs in your calculation
For a finance team of six, that first layer quickly reaches 100 to 150 hours in the first quarter. At an internal rate of 60 euros that is 6,000 to 9,000 euros, against roughly 2,500 euros of licences over the same quarter.
Worked example: a finance team of six
An SME finance team: a finance manager, two controllers, two AP/AR staff, a part-time analyst. Microsoft shop, Exact for accounting.
Year 1
| Item | Amount |
|---|---|
| Copilot Business, 6 users, 12 months | around $1,500 |
| Two heavy seats (controller work) | around $1,400 |
| API usage for two automated routines | around $150 |
| Setup and governance, 130 internal hours | around €7,800 |
| Training and practice, 20 internal hours | around €1,200 |
| Total year 1 | around €12,000 |
Year 2 onwards
| Item | Amount |
|---|---|
| Licences and usage | around €3,000 |
| Knowledge base and governance upkeep, 30 hours | around €1,800 |
| Total per year | around €4,800 |
That is the cost side. The whole question is whether the return side clears it, and that is exactly what most organisations fail to measure.
Why 95 percent shows no measurable return
The MIT research points to a cause that is actually favourable for finance. More than half of enterprise AI budgets flow to visible applications in sales and marketing, while back-office automation, the category with demonstrably the strongest ROI, stays chronically underfunded. Finance sits in the category where the return is, and gets the least money for it.
The second cause is methodological. What usually happens: a team starts using AI, everyone finds it pleasant, and six months later the board asks what it delivered. It then turns out nobody recorded how long the work took before AI. Without a baseline your saving exists only as a feeling, and a feeling does not survive a budget conversation.
The measurement framework: four levels
Measure at four levels, easy to valuable. The first two are simple and say little. The last two are harder and are the only ones that count.
Level 1: activity. How many people use it, how often, for what. Easy to pull from licence statistics. Says nothing about value, but does tell you whether anything is being used at all. If this is zero, stop measuring.
Level 2: time per task. How long did this task take before, how long now. This is where most reporting stops, and it is treacherous. Hours saved only become money when those hours go somewhere else or no longer have to be bought in. Otherwise it is comfort, not saving.
Level 3: cycle time and quality. This is where it gets interesting, because it is measurable without timesheets.
- Working days until the close is done
- Working days until the report reaches the management team
- Number of corrections after delivery
- Number of auditor questions on the same item
- DSO, if you deploy AI on receivables
FP&A benchmarks give an order of magnitude: forecast cycle time around 30 percent shorter, statement production time around 40 percent, scenario turnaround up to 70 percent. Use those not as a promise but as a check: are you anywhere near, or nowhere close.
Level 4: money. The only question the board asks. Three forms in which AI in finance genuinely touches money:
- Work you do not hire in. The interim controller you do not need at year-end, the temp at peak. This is the hardest number you have
- Cash released. Faster invoicing and sharper follow-up shortens DSO. One day of DSO at 10 million revenue is over 27,000 euros
- Errors avoided. A VAT correction not missed, a variance spotted in time. Hard to prove, but note them when they happen
The measurement protocol: twelve weeks
How to make this workable without building a measurement bureaucracy.
Week 0: baseline. Before anything changes, record: how many working days the close takes now, days until the report, current DSO, how many corrections there were over the past three months. Also ask each team member which three tasks take the most time and have them track that roughly for one month. Rough is fine, this does not need to be to the minute.
Week 1 to 4: one use case. Not five at once. One bounded task, with an owner, for which you have the baseline.
Week 5 to 8: measure and adjust. The same numbers again. What is not working, and is that the model, the instructions or the process? Usually the last one.
Week 9 to 12: conclude and expand. Put the outcome next to the baseline. If the effect shows at level 3, expand. If it only shows at levels 1 and 2, you have a pleasant tool and no business case, and that is worth knowing too.
Record the outcome in the same shape as your baseline, on one page. That is the document that gets you budget next year.
What not to measure
- Satisfaction as the headline metric. Everyone enjoys AI. That does not correlate with value
- Number of prompts or conversations. Measures activity, not results
- Hours saved with no destination. As long as you cannot say where those hours went, it is not a saving
- Everything at once. Four or five numbers you track consistently beat a thirty-indicator dashboard that gathers dust after two months
The rule of thumb
For an SME finance team of five to ten people, the break-even point is low. If AI saves one month of interim cover in the first year, or shortens DSO by four days, the business case is closed. That is a low bar, and precisely why the question is not whether it pays off but whether you are going to measure it.