A company decides it needs better control of cloud spend. The first instinct is often to focus on data.
We need more detailed billing exports. We need better tags. We need to fix the CMDB. We need application ownership. We need utilisation data. We need Finance mappings. We need everything in one place.
All of those capabilities can be valuable. But they can also create a dangerous assumption: we cannot start meaningful FinOps work until the data is perfect.
That is rarely true.
The amount of data you need depends on the decision you are trying to make.
Understanding why the AWS bill increased last month does not require the same data as allocating shared Kubernetes cost to products. Identifying an idle resource does not require the same data as calculating cloud cost per customer. And measuring a material optimisation requires different evidence again.
The question is therefore not "do we have all the FinOps data?" It is "do we have enough reliable data to make the decision in front of us?"
Start with three levels of cloud cost data
Not all cloud financial data provides the same level of insight. A useful starting point is to distinguish between three levels.
1. The invoiceThe cloud invoice answers the most fundamental financial question: how much do we owe the provider? That matters — Finance needs an authoritative view of the amount being charged.
But the invoice is primarily a billing document. It is usually not sufficient to explain the underlying economics of the environment.
If the organisation receives an $800,000 monthly cloud invoice, Finance knows the financial liability. It may still struggle to answer: which workloads drove the increase? Which services are growing fastest? Which teams are responsible? What usage created the cost? Where is infrastructure inefficient? Which optimisation opportunities exist?
The invoice tells you what you paid. FinOps needs to understand what created the cost.
2. Cloud-native cost managementThe next level is the cost-management capability provided by the cloud platforms themselves. AWS, Microsoft Azure and Google Cloud all provide native capabilities for exploring and analysing cloud spend.
These can already answer many useful questions. You may be able to analyse cost by service, account, subscription or project, region, resource, tag or label, and time period.
For an organisation beginning its FinOps journey, this can be enough to start. You can investigate major cost movements. You can identify which services are driving spend. You can begin discussing ownership. You can investigate obvious areas of inefficiency.
You do not necessarily need a sophisticated FinOps data platform before creating value.
3. Detailed cost and usage dataAs the questions become more demanding, organisations often need more granular billing data. Examples include AWS detailed cost and usage data, Azure billing exports and APIs, and Google Cloud detailed billing exports.
These datasets can provide much deeper information about consumption, resources, pricing, discounts and commitments. They become particularly useful when an organisation needs to perform detailed optimisation analysis, build more sophisticated allocation, understand effective pricing, analyse commitment economics, establish detailed baselines, reconcile financial outcomes, or analyse multiple clouds consistently.
But there is a trade-off. More granular data creates more analytical potential — and more complexity.
More data does not automatically create more insight
A detailed cloud billing export can contain millions of records. That sounds powerful. But raw provider data is not the same thing as decision-ready FinOps data.
Cloud providers describe the world in terms such as accounts, subscriptions, projects, services, resources, SKUs and usage types.
Finance may think in budgets, cost centres and business units. Engineering may think in applications, platforms, environments and services. Product teams may think in products, customers and features.
Those views do not automatically align. An organisation can therefore have extremely granular billing data while still being unable to answer: who actually owns this cost?
This is where the work shifts from collecting data to creating context.
From raw billing data to decision-ready data
A practical FinOps data flow can be thought of as:
IngestNormaliseEnrichAllocateReconcileAnalyse
The objective is not the pipeline itself. Each step makes the data more useful for a business decision.
Ingestion brings together the relevant provider cost and usage information. Normalisation creates more consistent structures, particularly across multiple providers. Enrichment adds organisational context such as ownership, applications or cost centres. Allocation assigns costs to meaningful consumers where appropriate. Reconciliation creates confidence that the analytical view can be explained against the financial source. Analysis turns that trusted dataset into decisions and opportunities.
The sophistication required at each stage depends on what the organisation is trying to achieve.
Normalisation becomes important as complexity grows
A single-cloud organisation may be able to work effectively within the structures provided by its cloud provider.
Multi-cloud environments introduce another challenge. AWS, Azure and Google Cloud do not represent every billing concept in exactly the same way. If an organisation wants a consistent view across providers, those differences need to be addressed.
Standards such as FOCUS — the FinOps Open Cost and Usage Specification — can help by providing a common structure for technology billing data. That can make cost and usage information easier to work with consistently.
But normalisation solves only part of the problem. A perfectly standardised resource record still does not necessarily tell you which product uses it, who owns it or why the business needs it. That requires enrichment.
Context is what makes cloud data useful
Useful FinOps analysis often combines provider data with information from elsewhere in the organisation. Depending on the question, that context might include:
Tags and labels
Application ownership
Account or subscription hierarchy
CMDB information
Organisational structure
Finance cost centres
Environment classification
Pricing and commitments
Utilisation and performance data
At more advanced levels, relevant business-demand metrics may also be useful — for example transactions, orders, active customers, requests or data processed. That can allow the organisation to move beyond infrastructure cost and begin understanding cloud economics in business terms.
But there is an important principle: do not integrate every possible source simply because the data exists. Bring in context because it helps answer a question.
Data readiness is decision-specific
Consider four different FinOps questions.
"Why did our cloud spend increase?"You may be able to answer this using provider cost data, historical trends and basic service or account dimensions.
"Can we resize this workload?"Now you may need resource-level cost plus utilisation and performance information.
"Which business unit should pay for this shared platform?"Now ownership, allocation rules and organisational context become critical.
"What is our cloud cost per customer?"Now you need both reliable cloud allocation and a credible customer or demand metric.
The data requirement becomes progressively more sophisticated. This is why there is no universal threshold at which an organisation suddenly becomes "FinOps data ready". Readiness depends on the decision.
Do not let imperfect allocation stop obvious action
This principle matters particularly during optimisation.
Suppose 20% of an organisation's cloud spend cannot yet be cleanly allocated to individual products. That is a genuine FinOps issue. It may require better tagging, ownership mapping or allocation rules.
But imagine that within the same environment there is an idle resource costing $12,000 per month. Do you need to solve the entire allocation model before investigating it?
Probably not. The resource can potentially be identified, validated with the appropriate technical owner and addressed independently.
This is where FinOps programmes can become unnecessarily blocked. Data remediation matters when poor data prevents a reliable decision. It should not automatically become a prerequisite for every optimisation action.
Improve the foundations while continuing to act where the available evidence is sufficient.
Reconciliation creates trust
As FinOps data becomes more sophisticated, another issue appears.
The FinOps dataset shows one number. The provider console shows another. Finance's invoice shows something slightly different.
That does not necessarily mean one of them is wrong. Differences can arise from:
Timing
Credits
Taxes
Currency treatment
Commitment amortisation
Billing adjustments
Reporting conventions
The important capability is being able to explain those differences. Finance does not necessarily need every analytical view to reproduce the invoice identically. But stakeholders need confidence that the numbers are reconcilable and understood.
Without that confidence, even sophisticated analysis becomes difficult to use.
Build progressively, not universally
A practical FinOps data journey is progressive.
CrawlStart with available cloud billing and native cost-management data. Understand major spend drivers and establish basic visibility.
WalkIntroduce detailed cost and usage data where needed. Improve ownership, allocation, pricing context and utilisation analysis.
RunConnect cloud economics with stronger organisational and business context where it supports more advanced decisions. That might include sophisticated shared-cost allocation, business-demand metrics or broader technology-cost analysis.
The objective is not to reach the most advanced stage as quickly as possible. It is to build the level of data capability the organisation actually needs.
The best dataset is the one that supports the decision
FinOps can easily become a large data-engineering exercise. Cloud billing. Pricing. Tags. CMDB. Finance. Observability. Business metrics. Revenue. Customer data.
All of these sources can potentially contribute value. But connecting everything is not the objective.
The objective is to answer useful questions reliably:
What are we spending?
What is driving it?
Who owns it?
Is it efficient?
Where should we act?
Can we measure the result?
If the available data can answer the question with sufficient confidence, use it. If it cannot, identify the gap and improve it.
That is a more practical approach than waiting for a perfect FinOps dataset that may never exist.
Key takeaway. You do not need perfect cloud cost data to start FinOps. You need data that is fit for the decision you are trying to make.
Start with what is available. Increase granularity when the analysis requires it. Add ownership and business context where they improve decisions. Reconcile the numbers where financial confidence matters. And address genuine data gaps without allowing every imperfection to become a barrier to action.
The goal is not to build the perfect FinOps dataset. It is to build enough trusted context to make better cloud decisions.
Nooven helps organisations assess cloud data readiness, identify the information required for meaningful FinOps decisions and establish a practical path from available billing data to trusted, actionable cloud economics.
