Reading your Outscale invoice

You got the invoice. The number at the bottom is bigger than last month. Why?

If you don't know, you're not alone. Outscale's invoice is technically correct and operationally useless. It tells you how much you spent on each top-level service category — compute, storage, network, snapshots — but it doesn't tell you which workload, which team, which environment, or which forgotten dev VM was actually responsible.

That's the gap. Here's what the invoice actually shows you, what it hides, and how to bridge from "the number" to "what to do about it."

What's on the invoice

The standard Outscale monthly invoice is structured by service. Roughly:

• Compute (FCU) — every running instance, billed by vCPU-hour and RAM-GiB-hour. The biggest line for most accounts.
• BSU (block storage) — every attached or unattached volume, billed by GiB-month. Includes magnetic, gp2, and io1, with io1 also charging for IOPS.
• Snapshots — every snapshot, billed by GiB-month. Old snapshots accumulate silently.
• OOS (object storage) — billed by GiB-month, no per-request charges.
• Public IPs — every reserved or attached EIP, billed hourly.
• Network appliances — VPN gateways, NAT gateways, load balancers, DirectLink — each billed hourly or with setup fees.
• OKS — control plane hours per cluster.
• Software licenses — Windows, RHEL, SQL Server, billed per core-hour.
• Outbound traffic — egress data transfer, billed per GiB.

Each line is a sum across the month. The invoice does not tell you which instance, which volume, or which day drove that sum.

What the invoice hides

Three things, all of which matter:

The day-by-day shape. A €5,000 compute line could be five evenly-spent thousands across the month, or four thousand of background normal plus a thousand-euro spike on the 14th from a one-off batch job. Same total, very different decisions.

The per-resource breakdown. The compute line aggregates every instance. You don't know if the spike came from your 2 vCPU dev VMs running over the weekend or from a single 64 vCPU GPU instance someone provisioned for an experiment and forgot.

The trend. One invoice tells you about one month. Two invoices tell you about a delta. Six invoices tell you about a trend. The invoice doesn't surface trends; you assemble them yourself, usually in a spreadsheet.

From totals to drivers

The job of reading the invoice is to get from "compute is up €1,200 this month" to "the staging cluster started running 24/7 on April 14th when someone disabled the schedule, costing us €40/day." That's a 4-step path.

Step 1: which line. Identify which top-level line moved. Compute? Storage? Network? Outscale's invoice gives you this much for free.

Step 2: which resource. Within that line, which specific resources contributed the increase? This requires consumption data, not invoice data — per-resource per-day usage. Available via the Outscale API but not in the invoice.

Step 3: which day. When did the increase start? A specific date often points to an action: someone's commit, someone's deploy, someone's manual change in the console.

Step 4: who and why. Tie the date to a person, a ticket, or a deploy log. Now you have a story.

Steps 2–4 are what the invoice doesn't help with. That's the gap Cost Explorer fills — same data Outscale uses to compute the invoice, broken down by 8 dimensions including resource ID, instance type, region, day, and tag, with daily granularity and history retention.

Multi-account is its own problem

If you run more than one Outscale account — for environment separation, billing isolation, or tenant separation — each account gets its own invoice. The total bill is the sum, but each component invoice has its own surprises.

The naive approach: download all invoices, sum the totals, paste into a spreadsheet. The maintainable approach: aggregate at the consumption level, not the invoice level. Pull every account's daily usage into one place, normalize, dimension. That's what multi-account FinOps tooling does.

Tagging makes everything visible

The invoice doesn't carry tags. But the underlying consumption data does. If you tag your resources by team, project, or environment, you can reconstruct what the invoice should have said:

• How much does the analytics team's pipeline cost us?
• What's the dev environment vs production split?
• Which customer (in a multi-tenant deployment) is most expensive?

None of these questions are answerable from the invoice. All are answerable from properly-tagged consumption data.

The forecast nobody does

The invoice tells you what you spent. It doesn't tell you what you're going to spend. Yet by the 5th of the month, you have enough data to project the rest with reasonable accuracy. By the 15th, the projection is usually within 5% of reality.

Forecasting from current consumption is a habit worth building. It catches budget overruns while there's still time to do something — disable a cluster, archive a dataset, kill an experiment — instead of finding out 25 days too late.

The fast version

If you're staring at an unexpectedly large invoice right now: identify which line moved, find which resource contributed most, find which day it started, find who or what changed that day. The invoice gets you 25% of that journey. Cost Explorer (or your equivalent) gets you the rest.

If you're not staring at one yet but want to be ready: tag your resources, set budget alerts on the lines that historically move, and build the habit of looking at consumption weekly — not monthly when the invoice arrives. By then it's already too late.