Why FinOps still lives in Excel

I visited Big Ben recently. The tuning mechanism is clear to see inside this complex (and very precise) mechanical system. It looks modest, almost too simple: engineers place old pennies on the top part of the pendulum to fine-tune the clock’s accuracy. The objective is stable (show accurate time). The engineering is deep. The correction is small.

The pennies are not a flaw. They are the connection between precision and reality.

That detail matters because it exposes a misconception that runs through FinOps. Quality is not the reduction of corrections. Quality is the reduction of the size of the corrections. The better the engineering and the clearer the goal, the less correction needed.

FinOps still relies on Excel, not due to weak tools, but because the discipline hasn't stabilised its foundations long enough for deep engineering to happen.

Tools are rational. Vendors optimise against whatever narrative the market rewards. If there is no prescriptive narrative, there is nothing stable to optimise for. This is why every organisation defines its own allocation logic and every dashboard is a little different. If the tool doesn’t fit the local approach, data goes to Excel. There, it is recalculated and reshaped. Sometimes, it is re-imported in the tool. Excel is not the disease. It is the pressure valve for a discipline without agreed primitives.

Mature domains did not begin with flexibility. They began with constraints.

Financial reporting stabilised around three mandatory lenses: balance sheet, profit and loss, and cash flow. They are imperfect. They omit things that matter*. They are often criticised. But they are stable enough that an ecosystem can engineer deeply against them. Because everyone understands the base numbers, narrative and interpretation move upwards. Ratios, commentary, and context sit on top of the shared structure.

FinOps has yet to make that step.

For FinOps to mature, this author feels that it should define mandatory reporting primitives at the statement level. For example:

A cloud position view. A snapshot of what’s running, what’s committed, what’s reserved, and what exposure is present.

A cloud performance view. A period statement of spend versus forecast, allocation versus budget, and variance explained.

A cloud cash exposure view. A statement showing when money leaves, where commitments are set, and where liquidity risk builds up.

They are illustrative, not exhaustive (I made them up). But such views should be mandatory and consistent across tools and organisations.

Once the base layer is stable, vendors can engineer deeply against it. Knowledge compounds because practitioners and other stakeholders are speaking the same language. Benchmarking becomes meaningful. Comparison becomes possible without translation.

More importantly, value moves upwards.

You can build your own ratios. You can define unit economics that matter to your business. You can tweak forecast tolerances. You can choose between defined allocation methods. Those become the pennies. Small, controlled adjustments on top of a stable mechanism.

Without prescriptive standards, there is no standard base. Without a stable base, every organisation needs to rebuild the same layers. FinOps feels busy but unstable.

Without prescriptive standards, FinOps cannot move towards stabilisation. Without stability, it cannot mature. It remains quicksand.

The question is not whether we want flexibility. The question is where that flexibility should live. If it sits at the foundation, everything above it shifts. If it sits at the top, the structure can hold.

The pennies do not threaten the clock. They prove that the clock is worth tuning.

• CEO will happily say that "People are our greatest assets", yet people are not in the asset section of the balance sheet. People are nowhere in financial documents, as far as I know.