Maintenance
Can a reporting pack survive contact with its own audience?
Reporting built to survive: agreeing the close, reconciling to an anchor, automating the pull but writing the narrative, and retiring a pack on purpose.
Reporting is the part of analytics that runs whether or not anyone is paying attention. A dashboard that breaks gets noticed when someone opens it. A monthly report that breaks gets noticed in a leadership meeting, by the person least able to work around it.
That difference (a fixed audience, a fixed date, and no room to say "give me another day"), is what makes recurring reporting its own discipline rather than an analysis you happen to repeat.
What to take away
- Operational data does not stop moving when the month ends.
- Pick one close policy (hard close, restating, or frozen with a note) and state it on every artifact.
- If your report touches revenue, orders, headcount, or anything that also lives in a system of record, decide which system wins and check against it every cycle.
- When your figure and the anchor figure differ, publish the bridge instead of adjusting one to match the other.
- The recurring parts of a report (extract, transform, format, deliver), should be code that runs on a schedule with no human in the loop.
Before you agree to build one
Every recurring report is a subscription you are selling, and the maintenance bill arrives forever. Establish these before the first send:
- Who reads it, and what decision does it drive?
- What period does it cover, and when does that period close?
- Which close policy applieshard close, restating, or frozen with a note?
- Which system of record is the reconciliation anchor?
- Who maintains it, and what would make you retire it?
Pre-build report checklist
- Name every reader, not the team
- Name the decision it feeds
- State cadence and why
- Define the close rule
- Define the escalation path
Write those down in the report itself. In a year, nobody will remember the answers, and the report will still be running.
The close rule is the whole game
Operational data does not stop moving when the month ends. Refunds post late. Invoices get corrected. Offline events sync days after they happened. Attribution windows stay open. This means the same period, queried twice, gives two answers, and both are correct.
You have to choose a policy and state it on every artifact:
How it works
- Hard close
- Figures stop at a stated cut-off date, and later corrections are excluded.
- Restating
- The published figure is replaced when the underlying data changes.
- Frozen with a note
- The original figure stands, with a footnote explaining known later movement.
Best for
- Hard close
- Contracts and regulated reporting, where a published figure must not move.
- Restating
- Readers who value the most accurate number over a stable version history.
- Frozen with a note
- A stable headline that still needs a visible audit trail.
Trade-off
- Hard close
- Accuracy is capped, and late refunds never appear.
- Restating
- Every restatement costs a conversation, and old screenshots stop matching.
- Frozen with a note
- Someone has to write that note every cycle.
Three close policies compared
Hard close
- How it works
- Freezes on stated date
- Best for
- Finance reconciliation
- Late data
- Goes to next period
Restating
- How it works
- Recomputes all history
- Best for
- Operational accuracy
- Late data
- Changes prior periods
Frozen with note
- How it works
- Snapshot plus change log
- Best for
- Finance and operations
- Late data
- Logged visibly
The failure mode is having no policy. Then one month someone reruns an old report, gets a different number, and the credibility of everything you publish takes a hit that takes quarters to recover.
Reconciliation: pick your anchor and check against it
If your report touches revenue, orders, headcount, or anything that also lives in a system of record, decide which system wins and check against it every cycle. The check is short:
Reconciliation cycle check
- Pull same measure from system of record
- Compare totals against stated tolerance
- Find cause before the report goes out
- Log the reason for future lookup
- Document the bridge, never adjust silently
Reconciliation: pick your anchor
- Name the anchor, the system whose figures win.
- Pull the same period from the anchor and from your report.
- Compare totals, then compare the two or three line items that normally drift.
- Explain each difference as timing, a definition change, or an error.
- Publish the bridge with the report, or log a zero gap when the two agree.
Do not silently adjust one number to match the other. Document the bridge instead: the operational figure, the finance figure, and the differences that explain the gap.
If a figure must be revised later, the published approach to revisions and corrections used by statistical offices is a workable internal model. A visible bridge earns trust; a quietly reconciled number destroys it the first time someone notices.
Automate the pull, write the narrative by hand
The recurring parts of a report (extract, transform, format, deliver), should be code that runs on a schedule with no human in the loop. Anything a person does by hand every cycle will eventually be done wrong, on the cycle where they were rushed.
What human commentary must cover
- What changed that matters
- Why, or that you do not know
- What is being done, and by whom
- What changed about the report itself
But the narrative should not be automated, and attempts to generate it produce sentences that restate the chart. What a reader actually needs from the human:
Automate the pull
- What changed that matters.Not everything that moved. The two or three movements worth a reader's attention.
- Why, or that you do not know why."Signups fell week over week, and the drop is concentrated entirely in paid search, which paused mid-week" is useful. So is "we do not yet know why, and here is what we are checking."
- What is being done, and by whom.If nothing is being done, say that too.
- What changed about the report itself.Definition changes, backfills, and new exclusions belong at the top, not in a footnote.
A good rule: if the commentary could have been written without looking at this cycle's numbers, delete it.
Design the layout to be boring and identical
Readers of a recurring report build muscle memory. They learn where the number they care about sits and they look straight at it. Every layout change costs them that, so:
Keep the layout boring
- Same section order every cycle
- Same chart types and axis ranges
- Structure changes in a marked note
- Summary on a single screen or page
Consistency also makes errors visible. When the shape of a familiar report looks wrong, a regular reader spots it faster than any automated test you will write.
Delivery: push the summary, link the detail
Most reports die because they require the reader to go somewhere. Put the headline in the channel where the reader already is (the email body, the message itself), and link out to the full artifact. A message that opens with an attachment and no numbers gets archived.
Four lines on every delivery
- Period covered
- Run timestamp
- Close policy
- Name to contact
Include on every delivery: the period covered, the run timestamp, the close policy, and a name to contact. Those four lines answer most of the questions that would otherwise come back to you individually. The four lines on every delivery are themselves a small data analysis checklist you can run before the send.
Retire reports deliberately
Reporting portfolios grow and never shrink unless someone makes them. Once or twice a year, take the list and go through it:
Retirement review questions
- Ask named readers if they still use it
- Check whether anyone opens the detail
- Find reports tied to departed staff
- Merge overlapping reports
- Did anyone open it in the last quarter?
- Does it drive a decision, or does it only satisfy a habit?
- Is that decision still made, and by the same team?
- Can the same numbers be read somewhere the audience already looks?
Announce retirements with a date and a contact, then actually stop. A report you keep running "just in case" is a report you keep maintaining forever.
Related reading on this site
The chain behind each figure in the pack is described in analytics foundations, and the analysis that produces a commentary is in how to work through a question. The queue these obligations grow out of is read in business intelligence.
Common questions
Report or dashboard?
A report is pushed on a schedule, covers a closed period, and carries commentary. A dashboard is pulled by the reader and reflects now. If people screenshot your dashboard into a document every month, they needed a report.
How do we handle a missed run?
Send something. A short note saying the pipeline failed, what is affected, and when the report will arrive keeps trust intact. Silence on report day is what damages it.
Should we include forecasts in a recurring report?
Only if you also show how the previous forecast did. A forecast published without accountability for the last one trains readers to ignore both. See forecasting for how to structure that comparison.
What is the right level of detail?
One page that the whole audience reads beats twelve pages that two people read. Build for the median reader and put everything else behind a link.
In this guide
- Grading a reporting explanation properly before it ships out the doorReporting commentary that earns its place: how to grade an explanation, decompose a movement before narrating it, and say what you cannot explain yet.
- Reporting mistakes: the ones that outlive perfectly correct arithmeticReporting faults that outlive correct arithmetic: publishing before the close, packs that only grow, comparisons quietly restated, and unowned numbers.
- Twelve reporting formats: what each one is actually built to answerReporting shapes worth knowing: twelve recurring report types, the question each one answers, and what each of them costs to produce every period.
- Fifteen reporting questions: which ones are worth asking before you buildReporting requests priced honestly: fifteen questions about the decision, the numbers, the reader and the standing obligation, asked before you build.
- Inside a reporting rebuild: why the average was the wrong numberReporting rebuild worked through on invented figures: why a rising average meant a mix shift, and what replaced the headline number afterwards.
