Pitching AI to the CFO: three numbers, twenty minutes

The meeting died in a glass room in Rotterdam. Our slide said invoice-chasing agent. The CTO raised his hand and asked which vector database we planned to use. Forty minutes later, the COO had her laptop open and was replying to email, and the deal had slid into the polite limbo where things go to be forgotten.

It was not a bad meeting. It was the wrong meeting. We had pitched the work to the engineering team, and engineering, doing its job properly, started auditing the architecture instead of buying the outcome. We have not made that mistake again.

Why engineering kills AI deals by accident

A good engineer in a buying meeting is, structurally, a problem. They are paid to find the failure case. They want to talk about hallucination rates, fallback behaviour, evaluations, the difference between fine-tuning and retrieval, and whether you have considered open weights. These are excellent questions. They are not the questions that release budget.

The 2024 Stack Overflow Developer Survey found that most developers who use AI tools still do not trust their accuracy. That is not lazy cynicism; it is the rational scepticism of people who ship software for a living. It is healthy. It is also exactly what stalls a procurement conversation. If your first meeting is with the people whose job is to be sceptical, you will leave without a decision.

The CFO meeting takes twenty minutes

We changed who we book first. The first meeting now goes to whoever signs the invoice. In a Dutch SME that is usually the CFO. Sometimes it is a controller, sometimes a finance director, occasionally the founder who still does the books on Sunday night. We do not bring an architecture slide. We do not bring a demo unless they ask. We bring three numbers.

Twenty minutes. Three numbers. They say yes, they say no, or they say "send me the SOW and I will read it tonight". The last one is also a yes.

Number one: fully-loaded cost per task

Hourly wage is the wrong unit. The CFO already knows the wage; they want the fully-loaded cost. That is wage, plus employer contributions, plus overhead, plus the slice of management time the task consumes. Eurostat publishes the underlying ratios; in the Netherlands fully-loaded sits at roughly 1.4 to 1.6 times gross salary, before you add the office, the laptop and the SaaS stack.

Take an invoice chase. A finance assistant on €38k gross writes a polite "your invoice is fourteen days overdue" email. Pull the PDF, draft the wording, look up the customer history, send it, log the result. Ten minutes per case if nothing breaks. Fully-loaded that is roughly €4.20 per chase.

If you do not have your own number, ask Finance for the fully-loaded cost of a transactional FTE divided by the annual task count. They know it. They might never have written it down.

Number two: monthly volume

How many of these tasks does the team actually do in a month. Not per year. Not "all our customer touchpoints". The specific, repetitive thing the agent is going to do.

A wholesaler with 800 active accounts on a 28-day average payment term runs roughly 1,400 invoice-chase events per month. A B2B SaaS doing inbound support triage might see 3,000 inbound emails. A real-estate firm fielding viewing requests might see 200. Get the actual number. If finance does not track it, the mailbox does, the ticket queue does, the CRM does. We count.

Volume times cost per task is the monthly burn. €4.20 by 1,400 is €5,880 per month, every month, forever, while the same team also does not get to do anything else.

Number three: payback in months

Build cost divided by monthly net savings. That is it. Net savings is the burn minus what the agent actually costs to run: model usage, infrastructure, and the few minutes of human review per day that any sensible deployment keeps in the loop.

A reasonable invoice-chase agent costs roughly €18k to build and around €120 a month to run. Against €5,880 of monthly burn, call it €5,000 of net savings after the human review. Payback: 3.6 months.

The slide that does the work

One table. Five rows: today's cost per task, agent cost per task, monthly savings, one-time build cost, payback in months. Underneath, one sentence: "if these inputs are roughly right, this project pays back by [month, year]."

The CFO will challenge the inputs. They should. Push back on €4.20. Push back on 1,400 events. Push back on €18k. That is the meeting we want. When the CFO is arguing about the inputs, you are winning, because the framework is now theirs and the conversation has stopped being about whether AI is interesting.

What this constraint changes about the build

This is not a sales trick. It is a discipline that makes the work better. If we have to fit a project under twelve months of honest payback, we cannot sell a six-month consulting engagement that ends with a Notion document and a roadmap. The agent has to ship, and it has to do its job in weeks, not quarters. That happens to be how we build anyway, and it is why the CFO conversation works: we are quoting against the same arithmetic they use to run the company.

When we built the invoice-chasing AI agent for a Dutch logistics client last quarter, the CFO walked in with her own number for fully-loaded cost. It was eighty cents higher than ours. The meeting took eighteen minutes, the build took five weeks, and the agent has been chasing invoices since.

The five-minute thing to do today: open last month's accounts receivable, or your support inbox, or your viewing-request log. Count the events of one specific repeating type. Multiply by your fully-loaded cost per event. If the monthly burn surprises you, the next meeting to book is not with engineering.