Metrics layers, explained with one MRR definition

Here is a scene from almost every Series B company. The CEO opens the board deck: MRR is €1.42M. The VP Sales shares the pipeline review: €1.51M. Finance closes the month at €1.37M. The product dashboard, built two years ago by an intern, says €1.46M. Everyone is right. Nobody is aligned.

This post walks through those four numbers, why each exists, and how to encode them in a metrics layer so that “MRR” on any chart means one documented thing.

Strip away the vendor vocabulary and a metrics layer is three things: a named measure with an owner, the SQL that computes it from modelled tables, and the dimensions it can legally be sliced by. Tools query the name, not the SQL. That indirection is the whole trick.

Without it, every dashboard embeds its own sum(amount) with its own filters. With it, dashboards say measure: mrr_recognised and the definition lives in one reviewable place.

We recommend picking one default and making the others explicit variants. For most companies the default should be the finance definition, because it is the one that reconciles with the books.

1234567891011121314151617measures:
  - name: mrr
    label: MRR
    description: Recognised MRR. Reconciles with the monthly close.
    sql: sum(recognised_amount_monthly)
    filters:
      - status in ('active', 'past_due')
      - days_past_due <= 30
      - line_type = 'recurring'
    owner: finance
    default: true

  - name: mrr_contracted
    label: MRR (contracted)
    description: Signed ARR / 12, including future-dated starts. Sales view.
    sql: sum(contract_value_annual) / 12
    owner: revops

Two details matter more than they look. The description is shown in every tooltip and every Ask Kimo answer, so people see what they are reading. And default: true means that when someone asks for “MRR” without qualification, they get the finance number — not whichever one was created first.

The underlying SQL

123456789101112131415select
    date_trunc('month', p.period_start)          as month,
    s.customer_id,
    s.plan_interval,
    case
        when s.plan_interval = 'year' then p.amount / 12.0
        else p.amount
    end                                          as recognised_amount_monthly,
    s.status,
    greatest(0, current_date - i.due_date)       as days_past_due,
    p.line_type
from stripe.invoice_lines p
join stripe.subscriptions s on s.id = p.subscription_id
left join stripe.invoices i on i.id = p.invoice_id
where p.line_type = 'recurring';

The failure mode of metrics layers is not technical, it is social: definitions drift because nobody owns them, or they freeze because everyone must approve a change. A few lightweight rules keep it healthy:

1. 1Every measure has one owner — a team, not a person — who approves changes.
2. 2Changes are versioned and shown as a diff in the activity log, with the before/after value for the last closed month.
3. 3Variants are cheap — creating mrr_contracted should take two minutes, so nobody is tempted to fork a dashboard instead.
4. 4Deprecate, do not delete — old definitions stay queryable with a warning badge for a quarter.

The meetings get shorter. The question moves from “whose number is right?” to “why did it move?”, which is the only question worth spending an hour on. And when someone asks Ask Kimo for MRR by region, the answer comes back with a footnote that says exactly which MRR it is.

If you want to see a working revenue model with these definitions, the revenue workspace in the live demo uses the exact structure above on simulated data.