A cost data pipeline is the plumbing that turns three or four clouds' worth of raw billing exports into one clean, queryable table that everything else, dashboards, allocation, anomaly detection, reads from. FOCUS, the open cost and usage specification, is what makes that pipeline tractable, because instead of maintaining a bespoke transform for every cloud's idiosyncratic schema, you map each source once into a single common shape. Build the pipeline well and every downstream tool inherits trustworthy data. Build it badly, or skip it and let each tool ingest raw exports its own way, and you spend the rest of the year explaining why three dashboards show three different totals.
To build a cost data pipeline with FOCUS, ingest each cloud's billing export on a schedule, map every source into the FOCUS schema so all clouds share one column set, reconcile each load against the provider invoice before you publish it, and serve the unified table from one store that every downstream tool reads. The point of FOCUS is that you write the hard mapping logic once per cloud instead of once per tool, so adding a dashboard or an anomaly detector later is a query, not another integration. The pipeline, not the dashboard, is where cost-data trust is won or lost.
This article is part of the complete guide to cloud cost visibility and tooling, and it is the engineering layer beneath how to normalize cost data across clouds. The build below mirrors how we stand up cost pipelines across the 500-plus environments we have optimized since 2019, where the durable ones all separated ingestion, mapping, and reconciliation into distinct stages rather than cramming them into one fragile script.
Start at the source. Each cloud publishes a detailed billing export, the AWS Cost and Usage Report, the Azure cost export, the GCP billing export to BigQuery, and the OCI cost reports, and several now offer a native FOCUS-formatted export option directly. Land each export into raw storage on a regular schedule, keeping the unmodified original so you can always reprocess. Confirm the current export formats and the availability of native FOCUS exports against each provider's documentation, because these options have expanded recently and what required a custom mapping last year may ship as FOCUS today. Raw ingestion is deliberately dumb: capture faithfully, transform later.
This is the heart of the pipeline. For each cloud, write the transform that maps its native columns into the FOCUS schema, so BilledCost, EffectiveCost, ServiceName, and the other FOCUS columns mean the same thing regardless of which cloud the row came from. Where a cloud ships a native FOCUS export, this mapping is mostly done for you and you only validate it; where it does not, you maintain the transform yourself. The discipline that pays off is writing this mapping once per cloud as a reusable stage, not re-implementing it inside every dashboard, which is exactly the duplication FOCUS exists to eliminate.
The failure mode FOCUS prevents is the same transform logic copy-pasted into a dashboard, a chargeback report, and an anomaly job, each drifting independently until they disagree. Map to FOCUS once in the pipeline and every downstream consumer reads the same normalized table. When the totals match everywhere, it is almost always because the normalization happened upstream, exactly once.
A pipeline that has not been reconciled is a pipeline nobody should trust. After each load, sum the normalized table per cloud and check it against the provider's own invoice or billing total for the period; if they do not tie out, the pipeline is wrong and you fix it before publishing, not after finance catches it. Build reconciliation in as an automatic gate, not a manual spot-check, so a bad load fails loudly instead of quietly poisoning every dashboard above it. This reconciliation gate is what lets you put the data in front of a CFO and have the numbers tie to the bill, the trust foundation under how to build a multicloud cost dashboard.
The output of the pipeline is a single, unified, FOCUS-shaped store, a warehouse table or equivalent, that becomes the one source of truth every tool reads from. Dashboards query it, the allocation engine reads it, anomaly detection runs on it, chargeback reports derive from it. The rule is that nothing downstream goes back to the raw exports; if every consumer reads the same reconciled store, every consumer agrees. This single-store discipline is what separates a real pipeline from a pile of one-off integrations, and it is what makes cost visibility for engineering teams possible without giving every team raw billing access.
We build FOCUS-based cost data pipelines across AWS, Azure, GCP and OCI, reconciled to the bill and serving one trusted store. It is the See step of our method, the data foundation that makes every later optimization measurable instead of arguable.
Get a FinOps implementation plan →You do not have to build this pipeline yourself. A third-party platform is, underneath the dashboard, exactly this pipeline run as a managed service, which is the real substance of the build versus buy for FinOps tooling decision and the native versus third-party comparison. Building gives you full control of the schema and the freedom to extend it; buying gets you a reconciled store faster without staffing a data team. Either way the FOCUS schema is the right target, because a pipeline built on FOCUS keeps your data portable whether you built it or rented it.
The pipeline is the invisible foundation under everything in cost visibility; nobody sees it, and everybody depends on it. Read the complete guide to cloud cost visibility and tooling for the whole stack, see how to normalize cost data across clouds for the normalization principles, and download The Multicloud Visibility and FOCUS Guide for reference pipeline patterns and FOCUS column mappings. When you want the pipeline built and reconciled for you, see our FinOps implementation service.
New commitment instruments, FOCUS changes, hyperscaler pricing shifts, and the plays that actually move a bill. No schedule, no filler.