Reporting Systems in New Zealand

Send the spreadsheet

Almost every reporting project starts with a pack somebody rebuilds by hand each week or month. That file is the specification, and it is worth more than any requirements document.

Send the actual file, with real numbers in it, and say who receives it and what they do with it. It shows a developer exactly which numbers matter, how they are currently derived, and — in the formulas — the rules nobody has written down.

Also send the version from six months ago. The differences between them are the parts of the report that keep changing, which is useful to know before designing anything.

Exhaust the tools you already have

A surprising share of commissioned reporting already exists in software you are paying for.

• Xero does more than most businesses use — tracking categories, custom report layouts, budget comparisons.
• Power BI, if you are on Microsoft 365, may already be substantially licensed to you.
• Your job or inventory system probably has reports nobody has explored.

Custom development earns its place when reports go to your customers, when tool licensing becomes painful at your viewer count, or when reporting has to live inside software your staff already use. A consultant proposing a custom build for internal reporting should be able to say why the tool would not do it.

Agree what the numbers mean

This is the part that decides whether the project succeeds, and it is not technical work.

Ask three people in your business what "revenue" means and you will get three answers. Invoiced or paid? Including GST? Including freight? What happens to a credit note raised in a later month? Is a refund negative revenue now, or a correction then?

The same applies to "active customer", "margin", "utilisation", "on-time" and "open job".

These are decided by your people, written down somewhere the next person can read, and then encoded. A reporting system built without them produces numbers that finance and operations argue about — and the moment that happens, both go back to their spreadsheets and you have bought nothing.

It takes about a week. It is the cheapest week in the project.

Attach a decision to every report

Before agreeing to build any report, answer: who reads this, when, and what do they do differently because of it?

Reports fail for predictable reasons:

• They answer the question management asked rather than the one the team has.
• They arrive monthly for a decision made weekly.
• They contain thirty numbers, so nobody knows which two matter.
• Somebody spotted a wrong figure once and nobody has trusted them since.

A report with no decision attached is decoration, however accurate. Ask each developer to walk you through who uses each report and what changes as a result — it is a better test of their thinking than any technical question.

Get the licensing number for year two

This catches New Zealand businesses out regularly, because the design happens before anyone works out what it costs to share.

Ask for the licence count and cost at the number of viewers you expect in two years, not one. Reporting has a habit of spreading: it starts with four managers and ends with sixty people who "just need to see it". Per-viewer licensing that is trivial at four is a real line item at sixty.

Above roughly a hundred viewers, capacity-based licensing usually becomes cheaper. Ask each consultant to price both.

Make failure visible

The dangerous failure is not a report that breaks. It is one that quietly goes wrong — a source system changes a field, a refresh half-succeeds, and the report still renders, with last week's numbers or a category silently missing.

Nobody notices for a fortnight, and then nobody trusts anything.

Insist on:

• A refresh failure alert that reaches a person, not a log entry.
• A visible "data as at" timestamp on every report.
• Two or three totals that reconcile against your accounting system, checked automatically.
• A named owner in your business.

Decide who can build the next one

There will always be a next report. Whether that is an afternoon or an invoice depends on how this is built.

Ask directly: can our own people create a new report from the model you build, or does every request come back to you? A well-built reporting layer means someone in finance can answer their own question next quarter. A collection of hand-crafted reports means a support arrangement you did not intend to buy.

Ask what training and documentation are included, and who at your end will own it.

Comparing five quotes

Read for:

• Who asked for the current spreadsheet?
• Who raised agreed definitions before you did?
• Who checked whether your existing tools would do it?
• Who priced licensing for year two?
• Who described what your own team can build afterwards?

Send the report you rebuild by hand, say which systems the numbers come from, how many people need to see the result, and which figure your business currently argues about. Consultants who do this work will spend most of the conversation on that last point.