Business reports need shared definitions

Agree what each operational measure includes before building reports that different teams will compare.

Team comparing matching report charts on paper and a tablet.

Two reports can use the same label and count different things. Jobs completed might mean work finished, paperwork approved or the invoice issued. When that definition is unclear, teams spend time debating totals instead of acting on them. A reporting project should begin with a short dictionary of measures and the decisions each measure supports, followed by a visible route back to the underlying records.

Define the event being counted

Imagine a Sunshine Coast service company reviewing completed jobs each week. Operations counts visits marked finished; administration counts jobs with approved completion notes. Both can be useful measures, but they need different labels. Write the inclusion rule in plain language and identify the relevant status and date field. Decide how reopened jobs, cancelled work and jobs with several visits are treated. Avoid relying on the report designer to infer these rules from existing spreadsheets, because those spreadsheets may already contain undocumented exceptions.

Agree the time boundary

Specify whether a report uses the date work occurred, the date it was entered or the date it was approved. For a business with staff across Australia, define the time zone that determines the reporting day. MDN's Intl.DateTimeFormat documentation shows that applications can format dates with an explicit time zone; the business still has to choose the right boundary. Display the report period and update time. A weekly snapshot and a continuously changing live report may legitimately differ, so label that distinction before people compare them.

Let the total explain itself

A useful operational total should open into the records that satisfy its definition. Preserve the same filters when moving from chart to list. Include enough information to explain unusual entries and identify records excluded by a relevant rule. Give reports named owners who can answer definition questions and approve changes. If a measure changes, annotate when the new definition begins rather than quietly rewriting the meaning of historical comparisons. Keep exploratory analysis available, but distinguish a personal filtered view from an agreed report used in a regular meeting.

Reconcile a deliberately small period

Choose one day or week and manually review a manageable sample of records. Explain every inclusion and exclusion, then compare the result with the report. The next deliverable should be a definition card for each important measure containing:

  • The business question and the event being counted.
  • Included statuses, excluded cases and the relevant date field.
  • The reporting time zone, refresh schedule and owner.
  • A link or route to the records behind the total.

Further reading

Discuss your software project with 110s

Related Insight