Reporting: what beginners should know in 2027

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.

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, by name. Not "the leadership team". Names. You will need them when you propose a change or a retirement.
What decision it feeds. A report that informs a monthly resourcing call has a deadline that matters. A report that goes into an inbox unread has none, and should not exist.
The cadence, and why that cadence. Weekly because the decision is weekly, not weekly because Monday feels natural. Most reports are produced more often than the decisions they support.
The close rule. What date does the period officially close, and what happens to late-arriving data after that?
The escalation path. If the pipeline fails at 6am on report day, who is told, and what goes out instead of nothing?

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:

Policy	How it works	Best for
Hard close	The period freezes on a stated date; later corrections go to the next period	Anything that must reconcile to finance
Restating	Every run recomputes history; prior periods can change	Operational reporting where accuracy beats stability
Frozen with a restatement note	Snapshot at close, plus a visible log of what later changed	Reports that feed both finance and operations

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:

Pull the same measure from the system of record for the same window.
Compare totals, and be explicit about the tolerance you accept and why.
When they disagree, find the reason before the report goes out: timezone boundaries, currency conversion timing, cancelled-versus-refunded handling, and test accounts are the usual suspects.
Log the reason. The same four causes recur, and a log turns a two-hour investigation into a five-minute lookup.

Do not silently adjust one number to match the other. Document the bridge instead: here is the operational figure, here is the finance figure, here is the list of differences that explains the gap. 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.

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:

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 same order of sections every cycle.
Keep the same chart types and axis ranges where you can: a rescaled axis makes a small move look dramatic.
Put changes to structure in a clearly marked note rather than letting readers discover them.
Keep the summary to a single screen or page. Depth goes in an appendix that only some readers open.

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.

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.

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:

Ask the named readers if they still use it. Some will say no immediately. That is a free win.
Check whether anyone opens the linked detail. If the summary is enough, stop building the detail.
Look for reports that exist because of a person who has left. These are common and can usually be stopped outright.
Merge overlapping reports. Two reports covering the same ground with different definitions is worse than either one alone.

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.

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.