Why FinOps still lives in Excel

I visited Big Ben recently. Inside one of the most precise mechanical systems ever built, the adjustment mechanism is visible and almost modest. Engineers place old pennies on the pendulum to fine-tune the clock’s accuracy. The objective is stable. The engineering is deep. The correction is small.

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

That detail matters because it exposes a misconception that runs through FinOps. Quality is not the absence of adjustment. Quality is the reduction of adjustment amplitude. The better the engineering and the clearer the objective, the smaller the correction required.

FinOps still lives in Excel not because tools are weak, but because the discipline has never stabilised its foundations long enough for deep engineering to occur.

Tools are rational. Vendors optimise against whatever narrative the market rewards. If there is no prescriptive narrative, there is nothing stable to optimise for. Every organisation defines its own allocation logic. Every dashboard looks slightly different. Forecast tolerances are implicit. Semantics shift between teams. When the tool does not quite match the local interpretation, data is exported, recalculated, reshaped, and sometimes re-imported. 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 constraint.

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 upward. Ratios, commentary, and context sit on top of shared structure.

FinOps has, yet, not taken 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 point-in-time statement of what is running, what is committed, what is reserved, and what exposure exists.

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

A cloud cash exposure view. A statement of when money actually leaves, where commitments are locked in, and where liquidity risk accumulates.

These are illustrative, not exhaustive. The point is not the exact labels. The point is that such views should be mandatory and structurally consistent across tools and organisations.

Once the base layer is standardised, vendors can engineer deeply against it. Education compounds because practitioners are speaking the same language. Benchmarking becomes meaningful. Comparison becomes possible without translation.

More importantly, value moves upward.

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 commoditised base. Without a commoditised base, every organisation rebuilds the same layer. Adjustment remains large. Custom dashboards multiply. Education never ends. FinOps feels busy but unstable.

Without prescriptive standards, FinOps cannot move towards commoditisation. Without commoditisation, 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.