mbfinotti/revops-skillsMIT5 files

Revenue Reporting

Define the metric set and narrative structure for an executive or board revenue report so it tells one coherent story - a small stable metric spine, locked definitions, an answer-first narrative around plan vs actual vs forecast, presenting a miss without surprising the board, the reconciliation and sign-off chain, and weekly vs monthly vs quarterly cadences. Use whenever the user mentions a board revenue report, exec deck metrics, the QBR revenue section, a monthly revenue review, an investor update, or a board deck that reads as a data dump - even if they never say "reporting". Covers B2B subscription, B2C, transactional, usage-based, and PLG. Do NOT use for designing the org-level KPI hierarchy - use mbfinotti/revops-skills@revenue-kpi-framework instead.

Specification
Skill ID
mbfinotti/revops-skills/revenue-reporting
Publisher
mbfinotti
Repository
revops-skills
Installs
808
Files
5
License
MIT
Synced
Oct 23, 2026
How to use it

Open any RiverX project, open the Skills panel in the chat, and search for this identifier. The files are fetched from the source repository at install time.

mbfinotti/revops-skills/revenue-reportingInstalls these files
  • SKILL.md
  • evals/evals.json
  • references/metric-dictionary-entry.md
  • references/metric-spine.md
  • references/worked-report-example.md

What this skill tells the agent

Revenue Reporting

Build the executive or board revenue report as one coherent story: a small, stable metric spine wrapped in an answer-first narrative organized around plan vs. actual vs. forecast. The hard part is rarely the arithmetic - it is agreeing on definitions, reconciling the CRM record against the finance record, and making sure the board never learns bad news live.

Scope boundary, stated up front:

In scope:

  • What goes in the report and how it reads.
  • The number and its confidence.

Out of scope:

  • Building a dashboard in any specific BI tool.
  • Designing the org-level KPI framework (which metrics matter at which org level and how they roll up) - a separate strategy exercise outside this repository.
  • Investigating why a forecast was wrong - hand that to mbfinotti/revops-skills@sales-forecast-diagnostic, then use this skill to turn the finished diagnosis into the board narrative.

Interview

Ask before proposing anything. One question per message; offer multiple-choice options when possible. Skip anything already answered.

  • What is the business model - B2B contract subscription, usage/consumption-based, PLG/self-serve, B2C/transactional/marketplace, or mixed?
  • Which artifact is being built - quarterly board deck, monthly executive review, weekly revenue review, an investor update, or the whole cadence stack?
  • What stage is the company - pre-institutional, early venture, growth, or late? (The spine tightens and shifts with stage.)
  • What exists today - nothing, an ad-hoc deck rebuilt each period, or a recurring report people have stopped trusting?
  • Do written metric definitions exist anywhere, and do any two dashboards currently disagree on a spine metric (recurring revenue, retention, coverage)?
  • Who produces the numbers today - RevOps/ops, finance, a founder - and does finance certify them before they ship?
  • What is this period's story - on plan, a miss, a beat, or unknown until reconciliation?
  • Which data is reachable - CRM/pipeline record, billing system, general ledger, product usage events?
  • By when must this land - the next board meeting, this month's close, or no fixed date?
  • One-off artifact, or a recurring asset rebuilt every period from here on?
  • What is the effort ceiling - analyst hours per period, whether finance will reconcile on request, and whether a warehouse or semantic layer already models revenue?

The last three questions set the spine ranking before any metric is chosen:

  • Deadline inside the finance close: drops every metric needing certification (payback, growth-plus-margin, the three-basis lines) out of this cycle.
  • Compounding mandate: builds the recurring-revenue waterfall and the dictionary first despite their cost, since every later period reuses them.
  • One-off artifact: skips both and reports the bridge from a billing export.
  • Low effort ceiling: caps the spine at five single-system metrics.
  • Existing revenue model in the warehouse: promotes every cohort metric to the top of the order.

Workflow

  1. Run the Interview; fix the artifact, audience, model, and cadence before touching metrics.
  2. Choose the metric spine: five to six core metrics, eight at the absolute cap. Rank candidates by decisions changed per unit of production cost - analyst hours, data the systems already emit, reconciliation burden against finance, how often it must be rebuilt - never by how standard the metric looks. Default B2B order, highest ratio first: pipeline coverage > win rate > recurring-revenue waterfall > retention pair > attainment distribution > growth-plus-margin > acquisition payback > bookings/billings/recognized lines. It is a default, not a law: re-rank it against the Interview answers and against everything else already known about the user, and delete a metric their data rules out rather than ranking it last. Full axes, justified ties, per-model orders, stage deletions and the durability metrics this order starves are in references/metric-spine.md. The same spine repeats every period so trends stay visible; a metric enters only by replacing one, with the swap footnoted.
  3. Lock definitions: write a dictionary entry for every spine metric - formula, inclusions/exclusions, source of truth, owner, window, and every contested rule resolved in writing (entry shape and worked example in references/metric-dictionary-entry.md). Field ownership and source-of-truth rules come from mbfinotti/revops-skills@crm-data-governance - reference them, do not redefine them here. Freeze the dictionary before drafting; definition changes mid-cycle are what make numbers move between meetings.
  4. Reconcile before narrating: the CRM read (bookings, pipeline) and the finance read (billed, recognized) diverge by design and only tie at the contract level over the full term - the check is that billings minus recognized revenue equals the change in deferred revenue, and that the headline number matches what finance will certify. When the harness can execute code, script the bridge and the reconciliation from a two-file export (billing/GL revenue by account, CRM bookings by deal); otherwise request the finance-certified totals and reconcile by hand. Never ship a number finance has not seen.
  5. Build the plan-vs-actual-vs-forecast table for every spine metric - the three columns every discussion hangs from. Show movement bridges (beginning, additions, losses, ending) rather than netted deltas, and distributions rather than averages wherever a distribution exists (attainment, deal size, cohort curves).
  6. Write the narrative answer-first: verdict, cause, response, ask - on the first page. Structure per the Narrative section below; worked report, and a good-vs-bad opening, in references/worked-report-example.md.
  7. If the period is a miss, follow the Presenting-a-miss section: quantify it, state the cause at the confidence actually held, name the fix and its proof metric. Root-cause depth belongs to mbfinotti/revops-skills@sales-forecast-diagnostic, not to this report.
  8. Assemble to cadence (see Cadence): short main body, everything backward-looking and detailed in the appendix, deck shipped as a pre-read days before the meeting. Optionally pass the narrative prose through a humanizer skill before sign-off.
  9. Run the sign-off chain:
  • RevOps publishes to a deadline.
  • Finance certifies against the ledger.
  • Each functional leader validates their section.
  • CEO/CFO approve.
  • The pre-read ships three to four days ahead.
  • Short pre-wire calls surface reactions before the room does.
  1. Check the Measurement thresholds below; fix and re-check until every one holds.
  2. When the harness has persistent memory, store the locked dictionary, the spine, and a restatement log - the next period starts from them instead of re-deciding. Otherwise keep the dictionary as a versioned document wherever the team already keeps documents.

Narrative structure

  • Answer first, evidence beneath (Pyramid Principle / BLUF): the first page states the period verdict, the single biggest driver, the response underway, and the decision being asked of the audience. A reader who stops there has the whole story.
  • Plan vs. actual vs. forecast is the organizing spine; every section is "what happened, why, what we are doing about it" - never a tour of charts.
  • The deck is a pre-read; the meeting is for decisions. Aim the live agenda at forward decisions - practitioners converge on roughly two-thirds of board time forward, one-third backward - and let the backward detail live in the pre-read and appendix. The silent-read narrative memo practice pushes the same direction: prose forces complete arguments where bullets hide gaps.
  • Keep the main body short. A main body that has grown past roughly twenty to thirty slides has become the pre-read; split it and rebuild the summary.

More from mbfinotti

Use this skill in a project

Open any RiverX project, search the Skills panel for mbfinotti/revops-skills/revenue-reporting, and install it in one click.

Use this skill