Legal, Finance & People · Chapter 3 of 4
Finance in a technology business
SaaS metrics, revenue recognition, and why the finance analyst is expected to write SQL.
Technology finance has its own vocabulary and its own failure modes, and data and analytics language appears in 91% of these postings for a concrete reason: the numbers live in systems, not in a ledger anyone can read.
The metrics you must be fluent in
| Metric | What it is | The trap |
|---|---|---|
| ARR / MRR | Recurring revenue, annualised or monthly | Non-recurring revenue quietly included |
| Net revenue retention | Revenue from existing customers, including expansion, minus churn | Above 100% is the headline; segment it or it hides churn in one cohort |
| Gross margin | Revenue minus cost to serve | AI features change this materially — inference cost is COGS |
| CAC payback | Months to recover acquisition cost | Sensitive to which costs you include; compare like for like |
| Rule of 40 | Growth rate plus profit margin | A heuristic, not a target, and easy to game short term |
| Burn multiple | Cash burned per unit of net new ARR | Increasingly the number investors actually look at |
The AI-specific point worth carrying: a product whose marginal cost per use is meaningful changes the software margin assumption that most SaaS financial models rest on. Finance people who can model that — cost per resolved task, distribution rather than mean, and what the tail does to margin — are unusually valuable right now.
The three statements, for people who will never prepare one
| Statement | Answers | The thing engineers most often miss |
|---|---|---|
| Profit and loss | Did we make money over a period? | It is on an accrual basis — revenue is recognised when earned, not when the cash arrives |
| Balance sheet | What do we own and owe at a point in time? | A prepaid annual cloud commitment sits here as an asset and moves to the P&L over the year |
| Cash flow | Where did the cash actually go? | A profitable company can run out of cash, and this is the statement that shows it coming |
The distinction that matters most for technical work is capital versus operating spend. Operating spend hits this period's profit. Capital spend goes on the balance sheet and is charged against profit gradually over the asset's life.
Which is why cloud migration is a finance conversation as much as a technical one: buying servers was capital — a large number once, spread over years. Renting them is operating — a smaller number every month, hitting profit immediately. The total may be similar and the shape of the profit line is completely different, which is why finance teams sometimes resist a migration that is obviously correct technically. Understanding that is how you have a useful conversation rather than a frustrating one.
Building a business case that survives finance
Name the baseline. ‘This will save money’ is unfalsifiable. ‘We currently spend X on this; this reduces it to Y’ can be checked, and being checkable is what makes it credible.
Separate cost avoidance from cost reduction, and expect to be challenged on the difference. Reduction means a line goes down and someone can see it. Avoidance means a line would have gone up. Both are real; only the first shows up in a budget, and presenting the second as the first is the fastest way to lose a finance audience.
Include the cost of the change itself — engineering time at a loaded rate, dual running, migration risk. A business case without an implementation cost is read as naive, and it is the first thing a finance partner looks for.
State the payback period. Most organisations have an implicit threshold — often around a year for infrastructure work — and a proposal that never mentions payback invites the question rather than answering it.
And say what happens if you are wrong. A range with a stated downside is treated as more credible than a point estimate, not less, because the person reading it knows the point estimate is wrong and is trying to work out by how much.
Check yourself