Cloud: expense or asset? Qualifying each contract component before comparing costs

The “cloud = OPEX” reflex deserves to be taken apart

The cloud is often presented as a natural shift from CAPEX to OPEX. That framing is convenient, but it conflates two things: the billing method on one side, the accounting nature of the spend on the other. A cloud contract actually contains components of different natures, and it is the nature of each component that determines its treatment — not the provider's label, nor the fact that payment is monthly.

Three distinct readings are needed. The first is accounting: is this a period expense or an amortised asset? The second is financial: when does payment actually occur, and what is the impact on cash? The third is economic: what full cost for what service delivered? These three readings do not contradict each other; they answer different questions and matter to different audiences — FinOps management, the finance function, executive management.

One essential point is often lost: an accounting entry does not reduce the cost of the service. It changes how the spend is recognised and spread over time. Confusing a purchasing decision with an accounting decision leads to trade-offs that look favourable on paper and are not in practice.

What the French accounting framework distinguishes

Regulation ANC 2023-05, dated 10 November 2023, whose page was published on 25 March 2024, distinguishes in particular continuous access services, recognised as expenses, and certain costs of bringing into a state of operational readiness, which can be capitalised when they meet the specified criteria. This marker is useful, but it is not an automatic rule transposable to any cloud purchase: the contract must be examined component by component.

The relevant question is therefore not “is the cloud OPEX?” but “what is the nature of this component, and does it meet the specified criteria?”. The answer may vary within a single project: one line is an expense, another may be an asset, a third remains to be qualified.

This is a qualification to be documented, not a slogan. The exact criteria and their application to the specific case must be checked against the applicable text and validated with the finance function. Caution is warranted here: a general announcement about the cloud does not remove the need for a line-by-line examination.

Two symmetrical pitfalls

First pitfall: a subscription paid in advance ties up cash, sometimes over a long contractual period. That early outflow is not enough to make it a capitalised asset. The cash outflow and the accounting nature are two separate questions, and neither can be deduced from the other.

Second, symmetrical pitfall: a project hosted in the cloud may include development costs to be analysed separately from the subscription. Integration, migration and even exit costs follow the same logic of separate analysis.

The frequent mistake is to apply a single treatment to a heterogeneous contract: either everything as an expense, or everything capitalised. In both cases, the information needed for an honest comparison between two options is lost.

Building the comparison on full cost

Before comparing two options, I would build a table with six lines: subscription, development, integration, migration, operations and exit. For each line, four columns: amount, due date, expected duration of use, and treatment validated with the finance function. This table has one simple virtue: it makes the assumptions visible instead of leaving them implicit.

The comparison itself must be made over the same horizon and at an equivalent service level. Changing the horizon or the service level changes the outcome of the comparison; both parameters must therefore be set out before the decision, not adjusted afterwards.

Hypothetical example: scenario A with a high subscription and little integration, against scenario B with a lower subscription but significant development and migration costs. The comparison is only meaningful with identical scope, duration and service level — otherwise it compares two different things.

The “exit” line is often forgotten. Yet it shapes the full cost and, beyond that, the real reversibility of the decision. A trade-off that ignores exit costs is not a complete trade-off.

Practical questions to settle before deciding

What is the exact scope of the contract: continuous access services, costs of bringing into a state of operational readiness, ancillary services? Which components are paid in advance, and over what contractual period? What duration of use is retained, and on what basis is it justified?

Has the retained treatment been validated by the finance function, and documented somewhere so it can be defended later? Is the service level genuinely comparable between the options, and over what horizon are they being compared?

Finally, is the accounting qualification being presented as a promise of tax savings? If so, the framing must be corrected: the accounting qualification does not constitute a promise of tax savings.

Operational checklist

Inventory the contract and project components, without grouping them too quickly. Qualify each component against the applicable framework, distinguishing what is an expense from what could potentially be capitalised. Map the cash outflows over time, independently of the accounting qualification.

Estimate and justify a duration of use per component. Have the treatment validated by the finance function and record the retained assumptions. Compare the options over the same horizon and at an equivalent service level, including the exit line.

Document the decision: the chosen scenario, the assumptions, the validated accounting treatment, and what could lead to revisiting it. This documentation is what distinguishes an owned decision from a default choice.

What the FinOps objective changes, and what it does not

The objective is not to obtain a favourable accounting qualification, but a documented decision: knowing why a scenario was retained, on what assumptions, with what treatment validated by the finance function. An accounting qualification is not a promise of tax savings, and on its own it says nothing about the full cost of the service delivered.

A choice can improve a period's accounting result while worsening the full cost over the horizon considered. Separating accounting result, cash outflows and full cost is therefore not an exercise in style: it is the condition for a comparison that bears on what is actually being decided.