Flowstate - The CapEx/OpEx discipline

Your CFO is asking whether the new platform rebuild counts as CapEx or OpEx. You don’t know. Your engineering managers don’t know. Nobody documented the split when the project kicked off, and now finance is trying to classify six months of work retroactively by reading Jira ticket titles. It’s 10pm on a Thursday, the auditors want answers by Monday, and you’re staring at a spreadsheet wondering how you got here.

This is how it goes for most engineering organisations. CapEx/OpEx classification is boring right up until the moment it becomes terrifying.

The job

Capital expenditure (CapEx) and operating expenditure (OpEx) are accounting categories that determine how costs hit the books. CapEx gets capitalised on the balance sheet and amortised over time. OpEx hits the P&L immediately.

For engineering, the distinction roughly maps to: building new stuff (CapEx) vs. keeping existing stuff running (OpEx). New feature development, new platform capabilities, new products — that’s capital investment. Bug fixes, maintenance, support, infrastructure upkeep — that’s operating cost.

Why does this matter to you? Because it fundamentally changes how the business sees engineering spend. A team that’s 70% CapEx is investing in future value. A team that’s 70% OpEx is treading water. Same budget, same headcount, completely different story.

And here’s the thing: most engineering leaders don’t tell that story because they never tracked the data.

Why it matters

Get this wrong and three things happen.

First, finance makes it up. If you don’t classify your work, someone in the finance team will. They’ll do their best, but they’re reading project names and guessing. I’ve seen organisations where finance classified an entire platform migration as OpEx because the project was called “Platform Improvements.” That’s potentially millions in capitalised development hitting the P&L as an immediate expense, making engineering look far more costly than it actually is.

Second, you lose a strategic lever. When the board asks “what are we investing in vs. maintaining?”, your CFO should be able to answer that cleanly. If they can’t, engineering becomes an opaque cost centre. You lose the ability to make the argument that increasing engineering spend is an investment, not a cost.

Third, auditors get uncomfortable. Public companies have strict requirements around capitalisation under IAS 38 and ASC 350. Even private companies going through due diligence will face scrutiny. If your classification is inconsistent or undocumented, it raises questions about everything else in your books. I’ve watched an acquisition due diligence get extended by three months because the target company couldn’t produce clean CapEx records for their engineering organisation.

When you get it right, the dynamic shifts. Finance sees engineering as a partner that speaks their language. Board presentations show investment allocation, not just cost. And when you need to make the case for more headcount, you can point to concrete data showing that new hires will increase your capitalisation rate — which is a very different conversation from “we need more people.”

What good looks like

In a mature organisation, CapEx/OpEx classification is structural, not manual. It’s built into how work is organised rather than tracked through timesheets or retrospective surveys.

Good looks like:

Work is organised into projects or initiatives that have a clear classification from the start
Engineers don’t fill in timesheets — classification flows from the work management system
The split is reviewed monthly, not annually
Finance and engineering agree on the classification methodology before the financial year starts
New projects get a CapEx/OpEx designation at kickoff, not at quarter-end
There’s a clear, documented policy for grey areas (refactoring, tech debt, platform work)

Struggling looks like:

Annual panic to reconstruct what teams worked on
Engineers asked to estimate percentages from memory (“how much of Q2 was new development?”)
Finance and engineering disagree on classifications after the fact
No documented policy — decisions made ad hoc by whoever’s in the room
CapEx rate bounces wildly quarter to quarter because methodology isn’t consistent

The difference between these two states isn’t sophistication. It’s discipline.

The approach

You don’t need a massive process overhaul. You need three things: a classification policy, a project structure that maps to it, and a monthly review cadence.

Step 1: Agree the policy with finance

Sit down with your CFO or FP&A lead and agree on what counts. The broad strokes are usually straightforward:

CapEx: New feature development, new product development, new platform capabilities, major system rebuilds where the output is a new asset
OpEx: Bug fixes, maintenance, support, minor enhancements, infrastructure operations, management overhead

The grey areas are where it gets interesting. What about refactoring? If you’re rewriting a service to add new capabilities, that’s likely CapEx. If you’re rewriting it purely for maintainability with no new functionality, that’s OpEx. What about tech debt? Usually OpEx, unless the remediation enables genuinely new capability.

Write this policy down. One page. Get finance to sign off on it. This document will save you hundreds of hours over the next three years.

Step 2: Structure work to match

Your project or initiative structure in Jira, Linear, or whatever you use should map cleanly to CapEx/OpEx classification. This doesn’t mean tagging every ticket — it means organising work into initiatives or epics that are clearly one or the other.

A project called “Payments Platform v2” is CapEx. A project called “Production Support — Payments” is OpEx. An engineer working on both will have their time implicitly split based on where their tickets sit.

This is the key insight: you don’t need timesheets if your work structure is clean enough. If 80% of an engineer’s tickets in a month sit under CapEx projects, that’s an 80/20 split. Your work management tool already has this data.

Step 3: Monthly review

Once a month, pull the data. Look at the allocation by team and by project. Review it with finance. This takes 30 minutes if your structure is clean.

What you’re looking for:

Is the overall split roughly where you’d expect?
Are there any projects that seem misclassified?
Are there engineers showing 100% CapEx or 100% OpEx? (This is almost never accurate — even on a pure new-build project, there’s some operational overhead.)
Has anything changed that would shift the classification? (A project that started as new development but is now in maintenance mode.)

Step 4: Adjust at project boundaries

When a project shifts from development to maintenance, update the classification. This is the moment most organisations miss. That payments platform you spent nine months building? The day it goes live, the ongoing work flips from CapEx to OpEx. If you don’t mark that transition, you’ll overcapitalise and your auditors will have words.

The conversations

With your CFO

Trust-building: “We’ve aligned our project structure so CapEx/OpEx classification flows from the work itself. Here’s the methodology we’re using — can we review it together so we’re on the same page before the quarter closes?”

Trust-eroding: “Yeah, we can probably reconstruct the split if you give us a couple of weeks.”

With your engineering managers

Trust-building: “When you set up a new project in Linear, make sure the classification is clear from the name and description. If it’s genuinely mixed, split it into two initiatives. This saves everyone a headache at quarter-end.”

Trust-eroding: “Finance needs you to fill in this spreadsheet estimating how much of your time was development vs. maintenance last quarter.”

With the board

Trust-building: “Engineering’s capitalisation rate this quarter was 62%, up from 55% last quarter. That reflects our shift toward the new lending product and away from the legacy migration maintenance.”

Trust-eroding: “Our engineering costs were $4.2 million this quarter.” (With no context on what was investment vs. maintenance.)

Common failure modes

The timesheet trap. Some organisations try to solve this with timesheets, asking engineers to log hours against CapEx and OpEx categories. This is almost always a disaster. Engineers hate it, the data is unreliable (people fill them in on Friday afternoon from memory), and it creates a surveillance dynamic that kills morale. Structure your work properly and let the data come from the tools your team already uses.

The 90/10 fantasy. Leadership sometimes wants to show a high capitalisation rate to make engineering look more like investment. So they classify everything as CapEx. This is a short-term win and a long-term nightmare. Auditors will challenge inflated capitalisation rates, and if your CapEx split doesn’t pass scrutiny, you’ll be restating financials. Be honest about the split.

The forgotten transition. A project launches, moves into BAU, but nobody updates the classification. Six months later, you’re still capitalising work that’s clearly maintenance. This is the most common failure mode, and the monthly review exists specifically to catch it.

The missing policy. Without a written, agreed policy, every classification decision is a debate. “Is this really new development or is it an enhancement to something existing?” Without a policy, these questions consume hours and create friction between engineering and finance. With one, they take seconds.

Ignoring contractor and vendor costs. CapEx isn’t just salaries. If you’ve got contractors building new features or paying for SaaS tools used exclusively in development, those might be capitalisable too. Most organisations miss this entirely.

Getting started

If you’re not doing this today, here’s how to start this quarter:

Week 1: Meet with your CFO or FP&A lead. Tell them you want to establish a clean CapEx/OpEx tracking methodology. They will be delighted — this is something finance has probably wanted for ages. Agree the broad classification rules.

Week 2: Audit your current project structure. Can you look at your initiatives or epics and clearly tell which are new development and which are maintenance? If not, restructure. You don’t need to retag every ticket — just make sure the top-level groupings are clean.

Week 3: Pull the first month’s data. Calculate the split by team and overall. Share it with finance. Expect it to be messy — that’s fine. The point is establishing the baseline.

Month 2 onwards: Monthly review. 30 minutes. Finance and engineering in a room, looking at the numbers. Adjust classifications where needed. Within two months, this will feel routine.

Ongoing: Every new project gets a CapEx/OpEx classification at kickoff. Every project that transitions from build to BAU gets reclassified. This becomes part of how you operate, not something layered on top.

Downloads

The CapEx Classification Tracker provides a straightforward template for recording project-level classifications, tracking monthly splits by team, and logging classification decisions and rationale. Use it as a starting point until you’ve automated the data pull from your work management tools — then it becomes your review template rather than your data entry tool.

Capacity Planning — Once you know your CapEx/OpEx split, you can forecast it. Understanding how investment allocation shifts over time is fundamental to capacity and cost modelling.
R&D Investment Documentation — CapEx and R&D tax credits are closely related. The same project structure that enables clean capitalisation also supports R&D claims.
Investment Framing — CapEx classification is the accounting lens. Investment framing is the strategic lens. Together they tell the complete story of where engineering spend is going and why.