A cloud cost review checklist is worked through once a month by the cloud owner, as soon as the previous month's invoices have arrived, together with the team leads and finance; it records which inputs are ready before the meeting, which questions are answered in which order, who owns each check and which decisions are minuted with a date. The decision it records sits in the last table: every variance, anomaly and recommendation ends with an owner and a date or a reasoned rejection. Why the month is the right cadence and what belongs in the week and the quarter is explained on reporting cadence; the flow of a review with examples is the article monthly cloud cost review.

Inputs ready before themeeting: exports andinvoices, statements,actual against budget,alerts, commitments,recommendations, lastmonth's actionsVariances first: eachwith a cause of one kind,usage, price or one-offThen anomalies, dataquality, commitmentsand savingsDecisions: every variance,anomaly and recommendationends with an owner anda date, or a reasonedrejectionOutputs: decisions log,action list, updatedforecast, purchase requests
Inputs come first, variances are explained before recommendations are decided, and every row leaves with an owner and a date or a reasoned rejection

The template

Monthly cloud cost review, month <YYYY-MM>, meeting <date>, led by <cloud owner>, attendees <team leads, finance>, minutes <person>

Inputs, ready <2> working days before the meeting

  • Billing exports of every provider complete to <last day of the month>; invoices <AWS, Azure, Google Cloud> received or marked provisional (<cloud owner>)
  • Showback statement per team produced and sent (<cloud owner>)
  • Actual against budget per team and in total, with the forecast to year end (<finance>)
  • List of the month's anomaly alerts with status open, closed, reviewed (<cloud owner>)
  • Commitment coverage and utilisation; commitments expiring within <90> days (<cloud owner>)
  • Open recommendations from the providers' recommenders, sorted by value per month (<cloud owner>)
  • Previous month's action list with a status per row (<team leads>)
  • Tag coverage per mandatory key and unallocated cost (<cloud owner>)

Agenda, <45> minutes

ItemMinutesQuestionInputLed by
1. Overall picture<5>Where does the month stand against budget, previous month and the same month last year?budget against actual<finance>
2. Variances<10>Which three variances per team are the largest, and is the cause evidenced?showback statements<team leads>
3. Anomalies<5>Which alerts are open, which have a post-incident review?anomaly list<cloud owner>
4. Data quality<5>Is coverage above target, and who owns the untagged cost?coverage report<cloud owner>
5. Commitments<5>Is utilisation above <percent>, and is a purchase or expiry due?coverage report<cloud owner>
6. Savings<10>What was verified, what implemented, what newly recommended?recommendation and action lists<team leads>
7. Decisions<5>Which row gets whom and which date?decisions log<cloud owner>

Checks

  • Every variance above <amount or percent> has a cause of exactly one kind: usage, price or one-off (<team lead>)
  • Every anomaly with status open has a person and a date; every closed one has the runbook's post-incident fields (<cloud owner>)
  • Unallocated cost is below <percent>; otherwise the cause is minuted with account and deadline (<cloud owner>)
  • Every commitment expiring within <90> days has a decision: renew, replace or let expire (<cloud owner>)
  • Every saving of the previous month with status implemented is visible in the invoice or is moved back to accepted (<cloud owner>)
  • Every recommendation above <amount per month> has a decision: accept with person and date, reject with reason, defer with date (<team lead>)
  • The forecast to year end is updated with this review's decisions (<finance>)
  • The minutes are sent on the day of the review (<minutes>)

Outputs

OutputFormatRecipientsDeadline
Decisions logthis table, versioned in <repository>attendees, <management>day of the review
Updated action list<tool>team leadsday of the review
Updated forecastbudget worksheetfinance, management<3> working days
Purchase requests for commitmentsone decision record per purchase<approver><date>

Decisions log

No.DecisionReason or evidenceOwnerDueStatus
<1><action, rejection or deferral><cause, amount, source><person><date><open>
<2><decision><evidence><person><date><status>

How to fill it in

Inputs: the first line decides whether the review works with final or provisional figures; when a provider closes a month is on freshness, restatements and finalisation. The showback statement per team follows the template.

Agenda: the minutes are a suggestion for six teams; the order is not, because variances must come before recommendations, otherwise actions get decided for cost that was a restatement. Item 2 uses the method from variance analysis, item 3 the alerts from anomaly detection.

Checks: the thresholds in amount or percent are set once by finance and changed in the annual budget, not in the review. The commitment check uses commitment coverage and utilisation; the savings check the vocabulary of estimated, accepted, implemented, verified. Coverage is measured as on tag coverage and untagged cost.

Decisions log: one row per decision, rejections included, because a rejected recommendation comes back next month; the owner column holds a person from the RACI.

acceptrejectdeferA variance, anomaly orrecommendation on the agendaAccept, rejector defer?A person and a datein the decisions logA reason in the log;it comes back next monthA date in the log
Every row leaves the review accepted with a person and a date, deferred with a date, or rejected with a reason that brings it back next month

How to adapt it

One team: items 2 and 6 merge, the review takes <20> minutes, and the minutes are the showback statement with a column for decisions. Several teams: item 2 is prepared per team, the review discusses only the three largest variances across all teams, the rest stays in the statements.

One provider: the commitment row names that provider's programme. Three providers: the input "invoices received" is ticked per provider, because the months close on different days, and item 1 shows the sum in one currency with its rate.

Startup: without finance, the founder takes items 1 and 7; budget against actual becomes previous month until a budget exists (template). Finance-led: item 1 becomes variance against budget and forecast with an explanation per cost centre, and the minutes feed the month-end close.

Sources

Read on 2026-10-21. FinOps Foundation, Reporting & Analytics and FinOps phases (CC BY 4.0), best practices for AWS Budgets, AWS Cost Anomaly Detection, cost alerts in Azure, analyse unexpected charges in Azure, budgets and budget alerts in Google Cloud, cost anomalies in Google Cloud.