FinOpsFinOps Move2Cloud — public documentation
Last updated: 3 November 2026
- Generated on
- 3 Nov 2026, 21:05
Attribute and steer your costs: allocation, unit costs, governance policies, FinOps maturity and Showback statements.
Last updated: 3 November 2026
Cost allocation
Cost allocation attributes your organisation’s cloud spend to those who incur it: teams, applications, products, projects, environments, cost centres or owners. It answers “who spends what?” without ever changing the raw spend read from your providers: it splits it, once, and says what is left to attribute.
Plans: the basic allocation (direct rules, on the Teams dimension, no shared cost) comes with Standard; the advanced allocation (fixed keys, metrics, shared costs, every dimension) with Pro and Enterprise. Starter has no allocation. Allocation applies as soon as a version of its rules is published.
Allocation rules
A rule selects costs through conditions — provider, account, sub-account, project, service, resource, tag, label, region or environment — and attributes them to one or more beneficiaries of the same dimension (teams, applications, cost centres…). Every condition must match; information absent from the source is never guessed.
- Direct assignment: the whole cost goes to one beneficiary. This is the basic allocation’s rule.
- Fixed percentages: a split key, for instance 40%, 25%, 15% and 20%, always totalling 100% (Pro and Enterprise).
- Metric-based split: in proportion to a measure of the period, such as a cluster’s CPU hours, with its source (Pro and Enterprise).
- Manual allocation, always with an explanation (Pro and Enterprise).
Each rule has a priority: the lowest wins. When two rules of the same priority target the same cost, it stays unallocated, with that reason. Each cost line is attributed only once, possibly split among several beneficiaries of the same dimension. The financial and technical owners of a team or an application are chosen among the organisation’s members.
Shared costs and unallocated costs
A shared cost — common services, backups, a Kubernetes cluster — is split by a fixed key or in proportion to a metric. For a €3,000 common service split 50%, 30% and 20%, the beneficiaries receive €1,500, €900 and €600; rounding always preserves the source amount.
What no rule attributes stays unallocated, and visible: its amount and share, its reason (no rule, priority conflict, metric without measure, currency not established), the provider, the account, the trend and the resource when known. For each currency, allocated + unallocated = eligible costs: the total never changes.
Simulate, then publish
A version of the rules is first simulated for a month: you see the amounts attributed, the unallocated costs, the conflicts and the difference with the previous publication, without changing anything. Publishing, explicitly confirmed, applies to the whole organisation for that month; the history keeps every version, simulation, publication and correction with its author and date. When a provider corrects its costs later, the console says a recalculation is needed and keeps the published results until the next publication. Analyses, budgets, recommendations and the Savings Tracker show the published attribution.
Example
In the fictitious organisation NovaRetail Cloud, October 2026 has €42,000 of eligible costs across six providers. Three direct rules attribute each team’s projects; shared services are split with a fixed 40/25/15/20 key between E-commerce, Data & AI, Back office and Platform, and the storefront’s Kubernetes cluster by CPU hours (70% E-commerce, 30% Data & AI). Published result: €14,662.74 for E-commerce, €12,502.43 for Data & AI, €10,775.02 for Back office and €700.01 for Platform, €38,640.20 in all. €3,359.80 stays unallocated — sandboxes and a promotion app with no owner: coverage is 92%.
Limits
- Currencies stay separate and are never converted implicitly; costs in a currency not established stay unallocated.
- A metric without a usable measure for the month leaves its costs unallocated rather than splitting them at random.
- Allocation works on the monthly costs read from providers: it creates neither an invoice nor an accounting entry.
- A month with many cost lines is computed in the background; the simulation opens as soon as it is ready.
Frequently asked questions
- Who configures allocation? The owner and administrators create rules, simulate and publish. Every member who can read costs views and exports allocations, as CSV with their publication reference.
- Can a rule share a cost between several teams? Yes, with Pro and Enterprise: fixed key, metric or an explained manual split. With Standard, a rule assigns a cost directly to a team.
- Does disabling a rule change the past? No: results already published stay as they are, and every version stays in the history.
- What if a provider corrects its invoice? The console asks for a recalculation; published results stay in place until the next publication.
In the console: Cost allocation, sign-in required. The console guide details creating dimensions, entities and rules, then publishing.
Unit Economics
Unit costs relate cloud spend to the activity it serves: a cost per active customer, per transaction, per order, per user or per thousand API calls. They tell whether the cloud costs more because activity grows, or because each unit costs more to serve.
Plans: with Pro, two metrics whose volumes are entered by hand, without target; with Enterprise, as many metrics as needed, the CSV import of volumes, the targets and their alerts. The module is disabled by default: the owner or an administrator enables it for their organisation.
The calculation
Unit cost = allocated spend ÷ volume of the same period, a calendar month. The spend comes from a published allocation, for the beneficiaries chosen (a team, an application, a product); the volume is a business metric you provide, with its provenance. Each metric keeps its unit, currency, scope and versions.
- Without a published allocation, the cost is unavailable, never zero.
- A missing volume stays missing; a volume of zero is measured absence of activity, for which the ratio is undefined.
- Unallocated costs are not added, currencies are not summed and no exchange rate is applied implicitly.
Business metrics and volumes
A metric is defined by its name, unit, currency, economic basis, owner and the source of its volumes: manual entry, or CSV import with Enterprise. Every line of an import is checked before it is saved, and incomplete collection stays visible. Correcting a volume creates a new observation without erasing the previous one; changing the definition creates a new version.
Targets and trend
With Enterprise, a metric gets a target, a unit cost threshold or a degradation percentage, month by month; once crossed, it notifies through the Notification Center. The trend reads from one calendar month to the next, with the same version, unit, currency, basis and scope: two incompatible series are never compared.
A result stays provisional until a financial review has reconciled it with a reference invoice or export; provisional or incomplete results trigger no alert. That review applies to one allocation publication and is not a provider certification.
Example
In the fictitious organisation NovaRetail Cloud, the Platform team follows the cost of its public API. In October 2026, the published allocation gives it €700.01 for 4,420 thousand calls: €700.01 ÷ 4,420 ≈ €0.16 per thousand calls, above the €0.15 target but below the €0.18 alert threshold. The E-commerce team’s cost per order has no value in July: that month’s volume was not provided, so the cost is unavailable, not zero.
Limits
- Business volumes are not collected automatically: they are entered or imported, with their provenance.
- The aggregate costs read from providers do not always allow a resource-by-resource analysis; a service name is never taken for a resource identifier.
- A comparison needs two consecutive months and the same definition; a change of scope starts a new series.
Frequently asked questions
- Is allocation needed to compute a unit cost? Yes: the numerator is the spend a published allocation attributes to the metric’s scope.
- Where do volumes come from? From your business tools: you enter them, or import them as CSV with Enterprise. The tool does not connect to your applications.
- Why is a result “provisional”? Because no financial review has reconciled it with an invoice or export yet; it is shown, but triggers no alert.
In the console: Unit Economics, sign-in required. The console guide details creating sources and metrics, the CSV import, the calculation and the review.
FinOps governance
FinOps governance turns your good practices into followed controls: policies read the data FinOps already tracks — budgets, recommendations, anomalies, allocations, savings — and flag the gaps, each with an owner and a due date. A policy never changes your cloud infrastructure.
Plans: FinOps governance comes with Pro (the predefined policies, their findings and how they are handled); exemptions and accountabilities come with Enterprise. The module is disabled by default: the owner or an administrator enables it for their organisation.
Policies and controls
Six controls are offered, each on a scope (the organisation, a provider or a project), with an owner and an evaluation frequency:
- every budget has an owner;
- important recommendations, above an amount, are assigned;
- important anomalies are reviewed;
- required tags are present;
- unallocated costs stay below a threshold;
- announced savings are verified.
Thresholds have an explicit currency. Editing a policy creates a new version without rewriting past results: each evaluation keeps its version, data and method.
Findings, owners and follow-up
Each evaluation gives a state: Compliant, Non-compliant, Not evaluable or Exempt. A finding is handled like a recommendation: it is assigned, given a due date and comments, then verified and closed with current evidence. With Enterprise, teams, applications and cost centres are linked to their technical and financial owners, who receive the findings that concern them through the bell, e-mail or Slack and Teams.
An exemption (Enterprise) needs a reason and an end date. It is not compliance: it stays visible, can be revoked, and normal evaluation resumes when it ends.
Method
Compliance = compliant ÷ (compliant + non-compliant); coverage = evaluable controls ÷ non-exempt controls. Not evaluable and exempt controls stay visible, and a missing denominator shows a dash rather than a misleading percentage. Missing data is never evidence of compliance: tags missing from collection do not prove resources are untagged.
Example
In the fictitious organisation NovaRetail Cloud, six policies are evaluated every month. In October 2026, unallocated costs reach 8%, above the 5% threshold: the finding is exempt until 30 November, the time to attribute the sandboxes. A recommendation above €200 has no owner: the finding is assigned, due on 27 November. Required tags are “not evaluable”: collection does not read them for every provider, and the tool does not conclude they are missing.
Limits
- The policies are the ones offered: there is no free rule written by the user.
- An evaluation creates neither a Jira, GitHub or GitLab ticket nor any cloud action; links to those tools follow their own permissions.
- The compliance and coverage shown are internal indicators, not a certification.
Frequently asked questions
- Can governance block spending? No. It reads and flags; decisions and actions stay yours.
- What about a legitimate finding? With Enterprise, exempt it with a reason and an end date; otherwise, handle and close it.
- Who receives findings? The policy’s owner, the declared owners of the entity concerned and the members chosen, according to their current rights and notification settings.
In the console: FinOps governance, sign-in required. The console guide details creating policies, accountability and handling findings.
FinOps maturity
FinOps maturity is a self-assessment of your practices, domain by domain: where do you stand on cost visibility, allocation, budgets, optimisation? It puts what you declare beside what the tool measures in your data, then proposes an improvement plan.
Plans: every plan has the diagnostic, the questionnaire and its score; Pro and Enterprise add the evidence, the improvement plan, the report and the comparison between assessments. The module is disabled by default: the owner or an administrator enables it, with no change of plan or price.
The questionnaire
The questionnaire is inspired by the FinOps Framework of the FinOps Foundation (2026 edition, CC BY 4.0 licence). It has ten domains of three questions: visibility and reporting, allocation, budgets and forecasts, anomalies, optimisation, governance, collaboration, savings tracking, business metrics and continuous improvement. Each question offers four described levels — practice absent, then practices inspired by Crawl, Walk and Run — as well as “I don’t know” and, for four questions, “Not applicable” with a reason.
Measured indicators
Seven measures are read from your data beside the answers: share of costs allocated, budget coverage, recommendations assigned, critical anomalies reviewed, savings verified, business metric coverage and policy follow-up. A measure without data is “unavailable”, never zero; a feature outside the plan makes it “not applicable”. A measure below the answer is shown as a gap, without replacing the answer.
The internal score and levels
Domain score = sum(weight × level) ÷ (3 × answered weight). A foundation question weighs 3, a practice 2, an extension 1; “Not applicable” leaves the calculation, “I don’t know” never counts as zero but lowers the coverage. A domain is scored only from two thirds of its weight answered. The score reads as internal appreciations: inspired by Crawl from 1/6, by Walk from 1/2, by Run from 5/6. Coverage and the evidence index always come with the score.
Worked example: a domain of three questions weighing 3, 2 and 2, answered at levels 3, 2 and 1, scores (3 × 3 + 2 × 2 + 2 × 1) ÷ (3 × 7) = 15 ÷ 21, that is 71.4%: a practice inspired by Walk.
Improvement plan and report
With Pro and Enterprise, each gap — a level below Walk, an unknown practice, a measure below the answer — proposes an action: its finding, the expected outcome, a priority, an estimated effort and the FinOps module concerned. Actions are assigned and followed like recommendations. A published assessment is frozen with its method; it exports as a report, a PDF and a CSV, and compares in points with another assessment of the same method.
Example
The fictitious organisation NovaRetail Cloud published an assessment in September, then in October 2026, with the same questionnaire: the two compare domain by domain. An “I don’t know” answer lowers the coverage without lowering the score. The improvement plan has two assigned actions, one of them overdue.
Limits
- It is an internal appreciation: neither a certification, nor an official score, nor an assessment published by the FinOps Foundation.
- Answers are declarative; evidence is a link or a note, no file is stored.
- Two assessments compare in points only when they use the same method and questionnaire.
Frequently asked questions
- Is the score recognised by the FinOps Foundation? No. The questionnaire is inspired by its framework, but the score is Move2Cloud’s own and helps you follow your progress.
- What does the Starter plan include? The diagnostic: the questionnaire and its score. Evidence, the improvement plan and the report come with Pro and Enterprise.
- Do the automatic measures hold amounts? No: they are shares and coverages, never amounts.
In the console: FinOps maturity, sign-in required. The console guide details answering, evidence, publishing and following actions.
Showback
Showback shows each team, application, product or cost centre what the cloud costs it, in a monthly statement. It makes spend visible to those who incur it, without billing: a statement is neither an invoice, nor an accounting entry, nor a payment request.
Plans: Showback comes with Enterprise. The module is disabled by default: the owner or an administrator enables it, with no change of plan or price.
The statements
A statement shows, for a calendar month (Europe/Paris time zone), the costs a published allocation attributes to the beneficiary: direct costs and share of shared costs, linked budget, change, anomalies, recommendations and verified savings. It cites the allocation publication and rules version used, each provider’s cost basis and the conversion policy. Totals are given per currency.
Periods, review and publication
Once the month’s allocation is published, the console prepares a draft for each beneficiary. Each statement goes to review, is approved, then published; a statement with reserves is published only once they are explicitly accepted, and they stay written in it. A published statement is frozen: if the allocation is corrected later, a new preparation creates a revision, and the old version stays readable.
Reconciliation and exports
Each statement reconciles with its source: “See source costs” finds the original allocation results, and the overview shows, per currency, the publication’s covered share — costs in the dimension, other dimensions, unallocated and eligible total. Unallocated costs stay visible in the overview and in each statement. A published statement exports as a report, a PDF and a CSV, and is distributed to the entity’s financial and technical owners as a summary and a link that requires signing in, with no amount in the message.
Example
In the fictitious organisation NovaRetail Cloud, the October 2026 allocation published by team gives four statements: E-commerce (€14,662.74, published), Data & AI (approved), Back office (for review) and Platform (draft). The four teams total €38,640.20; with the €3,359.80 unallocated, this gives back the month’s €42,000 of eligible costs.
Limits
- A statement is not an invoice: it creates no accounting entry, direct debit or rebilling (chargeback).
- A currency not established stays per cloud account, unallocated, and does not appear in beneficiaries’ statements.
- A statement depends on a published allocation; a source that is not fully split blocks the statement.
Frequently asked questions
- Can a statement be sent to a team? Yes: distribution rules name the recipients, who receive a summary and a link to the statement, once per version.
- What happens to a published statement if the allocation changes? It stays as it is; a revision supersedes it when published and the old version stays in the history.
- Are amounts in dollars converted? OVHcloud, Scaleway and Scalingo costs are in euros; an amount stated in dollars is converted at the European Central Bank rate, under the conversion policy cited in the statement.
In the console: Showback, sign-in required. The console guide details preparing, reviewing, publishing and the distribution rules.