The reporting system: the monthly report that compounds, and self-serve analytics

Your team already has the analysis-report and analytics-system playbooks — the worked recipes for building one repeatable monthly report and standing up one self-serve system. This module is the layer above the recipe. It’s where the two stop being a half-day scramble and a one-time build, and become one operating habit: a report that comes out the same way every month, and a system that means a teammate can get most of their answers without waiting on you.

It’s Module 5 of the certifiable Data & Analysts track — the last of the five, and the one where the other four finally pay off together. The reporting system doesn’t invent anything new; it runs what you already built. It pulls together the foundation (M1) — the profiled dataset and the metric dictionary every number inherits — the query & join engine (M2), quality & root cause (M3), and experiments & charts (M4), into a recurring deliverable and a standing system, running on the same three gates the whole track uses: PROFILE FIRST, RECONCILE, DATA SAFETY — except now they run every period, on a schedule, whether or not you’re watching.

An analyst who can answer a question is useful for exactly as long as they’re in the room. A system that answers the same question the same correct way every month — and lets someone else ask a new one without waiting on you — is infrastructure. The gap between those two is the entire value of this module: not “did the report ship,” but “would it ship the same way, with the same trustworthy number, if you were on leave.”

The recurring report — comparability is the whole product

A report is easy to build once. The discipline this module teaches is keeping it identical enough to compare, month after month, which is a different and harder problem than getting one month right.

• Comparability is the product, not the chart. The headline isn’t “MRR is AED 508,000” — it’s “MRR is AED 508,000, computed the same way as last month’s AED 497,000, so the +AED 11,000 is real growth, not a method change wearing a growth number’s clothes.” Change the query, the date boundary, or the chart type mid-series and every comparison built on it quietly stops meaning what it looks like it means.
• RECONCILE doesn’t get to retire because it’s the twelfth month. Every period, every headline figure ties to a second source — a prior total, a row count, increasingly Finance’s own general ledger — before it’s reported. The discipline that catches a query bug in month one is the same discipline that catches a billing-export change in month twelve; familiarity with the pipeline is exactly when a quiet, plausible-looking error is most likely to slip through unchecked.
• The caveats section is what survives a second look. A data gap, an unused new column, a metric that’s explicitly out of this period’s scope — name them in plain English next to the numbers, not buried in a footnote nobody opens. A report that hides its gaps reads more confident right up until someone finds one you didn’t mention; a report that names them reads more trustworthy from the first sentence.
• The runbook is what turns a half-day into a thirty-minute review. Once the method is locked and written down — exactly which files, which queries, which charts, in which order — the next period stops being a rebuild from memory and becomes Claude re-running a known pipeline while you review the diff and sign off.

The self-serve system — the guardrails live in the folder, not in your head

A query library answers questions. A system answers them safely, for someone who isn’t you, on a day you’re not online.

• Self-serve is only as safe as what’s actually in the folder. The CLAUDE.md, the query library, and the data contracts have to carry the guardrails themselves — always use metrics.md’s definition, always reconcile, never invent a metric on the fly — because the whole premise of self-serve is that the person asking doesn’t have your judgment to fall back on. A system that’s safe only when you’re supervising it isn’t self-serve; it’s you, slower.
• Monitor the few numbers whose breakage is expensive, not everything. A threshold on every metric trains everyone to mute the channel within a week. A threshold on logo churn (it feeds a save-flow decision) and on data freshness (a stale source poisons everything downstream silently) gets trusted, because it only fires when something is actually worth Maya’s attention.
• A system with no owner rots back into the mess it replaced. Name one custodian and a real change process — propose, review, log it — before you open the doors, or within a quarter you’ll have two slightly different definitions of “active” again and nobody who remembers why.
• Don’t automate a pipeline you haven’t verified by hand first. A scheduled monitor on an unreconciled query just broadcasts a wrong number on a fixed cadence instead of a one-off mistake. Every query earns its place in the library — and every monitor earns its place on the schedule — only after a human has checked it manually at least once.

Why Finance’s board pack starts here

This is the dependency that makes the reporting system more than a tidy internal habit: Maya’s recurring report is the upstream source for a second team’s most scrutinized artifact. In the Foundation module, the MRR definition in metrics.md already named its owner as Finance, reconciled monthly against the general ledger close — that single line is the contract. When Youssef Hamdan builds the May board pack, the MRR and logo-churn rows in his KPI table aren’t recomputed from scratch; they’re pulled straight from the figures Maya already reconciled and published this period.

That’s why the RECONCILE gate carries more weight here than it did when the audience was Mizan’s own leadership. A wrong or late number in an internal readout is an awkward Slack thread. A wrong or late number in this report is a wrong number in front of the board, with Maya’s name nowhere on the slide and Youssef’s name on the line. The fix isn’t a heavier process — it’s the same discipline, taken seriously because a second team is now standing on it: profile before you query, reconcile before you publish, and if a number can’t be verified this period, it goes in as a named gap, not a confident guess that someone downstream will trust without checking.

The bilingual monthly narrative — authored every period, not once

For a team that reports to bilingual leadership, the Arabic standard M1 set for a single brief now has to hold up on a recurring cadence — which is a stricter test, because there’s a new chance to drift every single month.

• Author the Arabic narrative fresh each period — never carry forward a translation. The English and Arabic narratives are both written from that period’s reconciled numbers, each in its own register, each time. A narrative that’s “this month’s numbers dropped into last month’s Arabic sentence structure” reads foreign, and a reader notices on the second month even if they missed it on the first.
• Both languages cite one reconciled appendix, every period. The discipline that keeps English and Arabic from quietly disagreeing on a figure is structural, not a matter of care: one appendix, built once a period, that both narratives reference. Numbers stay Western numerals; currency stays AED.
• The self-serve layer needs the same twin. The how-to-self-serve.md guide and the guardrail language in CLAUDE.md ship in Arabic too, so a non-analyst typing a question in Arabic gets the same definitions, the same reconciliation habit, and the same honest “I don’t have a trustworthy answer for that yet” — not a system that’s only safe in one language.

Your assignment

Build the reporting system for one recurring report and one self-serve system — your own (recommended: this becomes the infrastructure your team actually runs on) or the sample brand Mizan, continuing Maya Haddad’s story from the earlier modules. Open the folder with this period’s sources and your M1–M4 files in Claude Desktop, approve each read in the “Ask permissions” prompt, and work in the chat — no terminal needed.

Module 5 deliverable — the reporting system

Inherits from M1–M4 (this orchestrates them, it doesn't re-invent them):
  - dataset-profile.md + metrics.md + analysis-brief.md (M1)
  - the saved, explained query library (M2)
  - the data-quality contracts + root-cause discipline (M3)
  - the chart and readout conventions (M4)

1. monthly-report.md   (one recurring report, for one real period)
   - profile this period's sources, flag anything changed vs last period
   - the locked metric list from metrics.md, queried the identical way
   - reconciled against a second source — a prior total, a finance figure
   - the key charts (active customers / MRR / churn, or your team's three)
   - a plain-English narrative + an explicit caveats section
   - report-runbook.md, so next period is a re-run, not a rebuild

2. analytics-system/   (the standing self-serve system)
   - metrics.md + data contracts at the root (from M1 + M3)
   - a query library: named, explained, reconciled, definition-linked
   - CLAUDE.md teaching Claude your conventions and guardrails
   - monitor-spec.md: 3-4 numbers that matter, each with a threshold and
     a named person who's alerted
   - a named owner + change process for the whole system

Bilingual teams: monthly-report-ar.md, AUTHORED fresh each period — not
carried forward in translation — citing the same reconciled appendix.

How it’s graded — the rubric

This is the part the free playbooks don’t have, and the part that makes the credential mean something. Your report and your system are scored against five criteria. Each is meets / nearly / not yet — and a “nearly” on any one is a revise, not a pass.

Reporting system rubric — five criteria, each meets / nearly / not yet.
A "nearly" on any one is a revise, not a pass.

1. The report is repeatable    Same method, same metric definitions, same
                                chart types as last period — a teammate
                                could rerun it from the runbook and get a
                                genuinely comparable result, not a rebuild
                                that happens to look similar.

2. Every number reconciles     Each headline figure ties to a second
                                source — a prior total, a row count, a
                                finance figure — not just stated. Anything
                                that moved meaningfully has a verified
                                cause named, not a guess.

3. Caveats are explicit        Data gaps, exclusions, and any definition
                                change are named in plain English next to
                                the numbers — not hidden behind a chart
                                that looks more confident than it should.

4. The system is genuinely     The dictionary, contracts, and guardrails
   self-serve                  live IN the CLAUDE.md and the query
                                library, not in the analyst's head. A
                                non-analyst's question routes to a vetted
                                answer or an honest "not yet covered."

5. Monitors and owner are real 3-4 numbers that actually matter are
                                watched, each with a stated threshold and
                                a named person who gets alerted. The whole
                                system has one named owner and a real
                                change process — not an unattended folder.

The discipline is what a skeptical analytics lead and a board both want at once: a report whose method drifts fails quietly, one period at a time, until a comparison that matters turns out to be meaningless; a self-serve system with no real guardrails just lets more people compute wrong numbers faster. Both gaps are invisible from the outside until this rubric goes looking for them.

The bar, shown — a worked model answer (Mizan)

You don’t have to guess what “meets” looks like. Here’s a passing excerpt for Mizan — Maya’s May 2026 report and the standing system underneath it. Yours doesn’t need to look identical; it needs to clear the same bar.

monthly-report.md — Mizan: May 2026 (excerpt)

Profiled against April: subscriptions.csv this period 9,530 rows vs
9,400 last period (one row per account, includes cancelled and trial;
the gap above the active count below is non-active rows); one new
column, plan_cycle_id, added by the billing team mid-quarter — present
but not yet used in this report. events.csv is missing 3 days (May
6–8, a logging gap engineering has confirmed) — doesn't touch any
metric below, all three are sourced from subscriptions, not events.

ACTIVE CUSTOMERS          9,460   (April: 9,350, +110 / +1.2%; continuing
  the trailing-6-month trend M2's query already reconciled through
  March's 9,240)
  Reconciled against: the subscriptions table's own active-status
  count, pulled independently. Both counts: 9,460.

MRR                       AED 508,000   (April: AED 497,000)
  Net-new MRR: +AED 11,000 (new + expansion − churn).
  Reconciled against: Finance's general ledger close for May (Youssef
  Hamdan) — ties within rounding. This is the figure Youssef pulls
  directly into the board pack's MRR row; it is not recomputed a
  second time downstream.

MONTHLY LOGO CHURN        1.2%   (April: 1.4%)
  Reconciled against: cancelled_this_month / active_at_month_start,
  cross-checked against the cancellation log row count — ties.
  The improvement traces to the save-flow Customer Operations launched
  in April — the Q2 priority the March analysis-brief identified.
  UAE Starter-tier accounts, the segment that brief flagged as highest
  churn with enough volume to justify it, show the sharpest drop:
  1.6% → 1.1%. The other three segments are flat. This is the save-
  flow working, not a data artifact — checked by segment before it
  was reported as a trend.

Caveats:
  - events.csv has a 3-day gap (May 6–8). Doesn't affect this report's
    three metrics; flagged for the query library in case a future
    metric is built on events.
  - plan_cycle_id is new on subscriptions.csv this period and unused
    here — flagged for M2's query maintainer, not yet incorporated.
  - Revenue churn (vs. logo churn) is out of scope for this report,
    same boundary the March brief set. Finance's board pack carries
    revenue churn separately, computed from the GL.

CLAUDE.md — Mizan data & analytics (excerpt)

## What we do
We answer data questions for Mizan's leadership and Customer
Operations. Sources: the `subscriptions` and `customers` tables
(daily export, refreshed 02:00 GST), `events.csv` (daily, known
3-day gap May 6–8 — see data-contracts.md).

## Standing rules
- Always use metrics.md's definitions. Never invent a metric on the
  fly — if it isn't in metrics.md, flag it as undefined and stop.
- Always reconcile a result against a second source before stating it
  as final, and show the working.
- Customer-identifying data stays in this workspace. Aggregates and
  patterns leave it; raw rows never do.
- For a recurring question, check query-library/ first — answer from
  a vetted, reconciled query before writing a new one.
- Owner: Maya Haddad. Propose any definition or contract change in
  changelog.md; Maya reviews before it ships.

## Query library (the recurring questions)
  active-customers.sql   "how many active customers" — metrics.md →
                          Active Customers, owner Maya
  mrr.sql                "what's our MRR" — metrics.md → MRR, owner
                          Finance, reconciled against the GL monthly
  logo-churn.sql         "what's churn" — metrics.md → Monthly Logo
                          Churn, owner Nadia Al-Sayed

monitor-spec.md — Mizan (excerpt)

1. Logo churn threshold
   Recompute weekly. Alert if churn moves >0.3pp week over week, or
   exceeds 1.8% in any week. Notifies: Nadia Al-Sayed (metric owner).
   Threshold basis: 0.3pp is roughly the noise band over the last two
   quarters — a move past it is signal, not wobble.

2. Data freshness — subscriptions + events
   Check on every scheduled load: did it land, is the date range
   current. Alert if a load is >24h late, or row count drops >15% vs
   the prior load (a likely truncated export). Notifies: Maya Haddad.

3. Billing double-charge pattern
   Check every billing run for the pattern M3 root-caused in March —
   11 annual-plan accounts charged twice, tickets 4421-4431. Alert if
   any account matches it, on any run. Notifies: Maya Haddad and
   Youssef Hamdan, same day — Finance's number is the first one this
   bug corrupts.

4. MRR reconciliation gap
   Check whether Maya's MRR ties to Finance's GL close within
   rounding. Alert if the gap exceeds AED 500. Notifies: Maya and
   Youssef — this is the number the board pack inherits, so a silent
   gap here is the most expensive place in the system for one to hide.

Owner: Maya Haddad. Reviewed quarterly. Any threshold change is
proposed, reviewed, and logged in changelog.md — never adjusted ad hoc
just to quiet a noisy alert.

Notice what the worked answer does: the report names exactly which figure reconciles against which second source, including the one that now reconciles against Finance’s own ledger; the churn improvement is checked by segment before it’s reported as a trend, tying back to the save-flow decision M1’s brief actually drove; the caveats name a data gap that doesn’t matter and an unused column that might, instead of staying silent on both; the CLAUDE.md makes the guardrails the folder’s job, not the analyst’s memory; and the monitor list watches exactly four things — the ones whose breakage is expensive, including the double-charge pattern M3 already root-caused once and which should never need a human to catch it manually again.

monthly-report-ar.md — Mizan (note)

Authored, not translated, fresh for May. Leads where Mizan's bilingual
leadership reads first — the customer count and MRR, then churn and
what's behind it (تحسّن نسبة فقدان الحسابات). Numerals stay Western,
currency AED, and both narratives cite the same reconciled appendix
above, so an Arabic reader and an English reader are never looking at
two different MRR figures. Register: direct, lightly-formal MSA with
Gulf-natural phrasing — the same standard M1 set for the analysis-
brief readout, now run every period instead of once.

What you’ve proven — and what’s next

Clear the rubric and you’ve done something the free path can’t certify: you’ve turned a recurring report from a monthly scramble into a system that produces the same trustworthy number every time, and a self-serve analytics system from a folder of one-off queries into infrastructure a non-analyst can actually use. That’s the Reporting-system stage of “Certified Data & Analysts with Claude” — the fifth and last.

Step back and look at what the five modules built:

• Module 1 profiled the data, defined the metrics, and scoped the request — the foundation every later number inherits.
• Module 2 built queries a stranger could audit, and turned messy files into one trustworthy joined dataset.
• Module 3 audited quality before it mattered and found out why a number actually moved.
• Module 4 read an experiment honestly and turned a CSV into a chart that survives a second look.
• Module 5 pulled all four into a recurring report and a standing self-serve system — including the one a second team now depends on.

That’s a complete analytics function — trustworthy data, defensible queries, audited quality, honest reads, and a reporting system that runs without you in the room every time.

One thing remains: proving you can run them together, as one system, for one brand. The capstone — Insight-in-a-Box is where Modules 1 through 5 integrate into a single data operating system for one company, taking one real investigation from raw export all the way to the verifiable certificate. Bring your own data and it doubles as real infrastructure your team queries from day one — you’ve now built every part, including the hardest one to keep running. The capstone is where you show they work as one.

Next: the capstone — Insight-in-a-Box. The Foundation toolkit and the operating guide are the layers that sit underneath the whole system.