The day the numbers stopped adding up

Most finance leaders can name the moment. A board pack showed one revenue figure, a saved search showed another, and a spreadsheet a controller maintained on the side showed a third. Nobody had done anything wrong, yet three credible numbers sat on the table for the same period. From that point on, every report carried a quiet asterisk: is this right, or do we need to check it again?

That erosion of confidence is the real cost. It is rarely a single catastrophic error. It is the slow accumulation of small discrepancies that nobody fully explains, until the team trusts a manually rebuilt spreadsheet more than the ERP the business invested heavily to implement. Once that happens, the system is still running, but it has stopped being the source of truth it was bought to be.

The instinct is to blame NetSuite, the ERP, or the implementation partner. Occasionally that is fair. Far more often the platform is calculating exactly what it was told to calculate. The trust problem lives in the layer above the software: how data gets in, who owns it, how reports are defined, and whether anyone checks the output against reality.

Why ERP and NetSuite reports drift out of trust

Reporting confidence usually fails for a small number of recurring reasons. None of them are exotic, and most are invisible until someone goes looking.

  • Unclear data ownership. When no single person owns a record type, whether customers, items or the chart of accounts, everyone edits it slightly differently. Duplicate customers, inconsistent subsidiaries and ad hoc item categories quietly distort every roll-up built on top of them.
  • Inconsistent definitions. "Revenue", "active customer" and "open order" mean different things to sales, finance and operations. If two reports use two definitions, they will disagree forever, and both can be technically correct.
  • Undocumented report logic. A saved search filters on a status nobody remembers setting. A formula excludes intercompany lines. The original author has left. The report keeps running, but no one can explain why it returns what it does.
  • Weak or absent reconciliation. Sub-ledgers, the general ledger and external feeds (bank, payment processor, CRM) are never tied out on a fixed cadence, so timing differences and posting errors go undetected until period end.
  • Manual workarounds layered on top. Every time a report is wrong, someone fixes it in Excel. Those fixes become permanent shadow processes that diverge from the system a little more each month.
  • Permission and process gaps at data entry. Free-text fields, optional categories and inconsistent posting periods let bad data in at the source, where it is cheapest to prevent and most expensive to fix later.

The pattern underneath all of these

Notice what the list has in common. Almost none of it is a software defect. ERP reporting trust is mostly an operational discipline problem wearing a technical costume. The platform faithfully reflects the quality of the data it is given and the clarity of the instructions it is asked to follow.

This matters because it changes the remedy. If the cause were the software, the answer would be a reimplementation or a migration, which is slow, expensive and disruptive. Because the cause is usually ownership, definitions and reconciliation, the fixes are mostly procedural. They are cheaper, faster and far less risky than another system project, but they require someone to own them deliberately rather than hoping the next upgrade sorts it out.

In our experience, teams that reach for a new system to solve a trust problem tend to carry the same habits into the new platform and recreate the same problem there. The discipline travels with the data.

A practical checklist to rebuild confidence

Rebuilding trust is methodical work, not a heroic clean-up weekend. The aim is a state where the same question always returns the same number, and anyone can explain how that number was produced. The following sequence works because it fixes causes before symptoms.

  • Assign clear data ownership. Name a single owner for each critical record type and each key report. Ownership means the right to change definitions and the responsibility to keep the data clean, not just access.
  • Agree and document definitions. Write down what "revenue", "active customer" and your other core metrics actually mean, then make every report conform. A short, shared glossary settles more arguments than any dashboard.
  • Reduce the number of sources. Decide which report or saved search is canonical for each metric and retire or relabel the rest. Competing "official" reports are how distrust starts.
  • Document the logic behind key reports. For each board-level number, record the source, filters, exclusions and the person who owns it. If the author left tomorrow, the report should still be explainable.
  • Establish a reconciliation cadence. Tie sub-ledgers to the general ledger, and the GL to external feeds, on a fixed schedule. Reconciliation is what lets you trust a number without re-checking it by hand.
  • Close the gaps at data entry. Tighten field requirements, restrict free text, control who can post and to which periods. Most reporting errors are entry errors that surfaced months later.
  • Migrate the spreadsheets back in. Once the system is trusted again, fold the shadow workbooks back into it. Every retired spreadsheet is one fewer place for the numbers to diverge.

What good looks like

You will know trust has returned when behaviour changes, not when a project plan says it is complete. The controller stops rebuilding the month-end pack by hand. The board stops asking which version of the number is the real one. New starters can find the canonical report and understand how it is built without a folklore session from someone who has been there for years.

None of this requires a transformation programme or a platform change. It requires deciding that reporting accuracy is owned by someone, defined in writing, reconciled on a cadence and protected at the point of entry. The software you already have is almost always capable of the job once those four things are true.

The hardest part is usually starting, because the discrepancies are diffuse and no single one feels urgent. A focused look at where your current reports disagree, and why, is enough to turn a vague unease into a short, ordered list of fixes.

Where to start

If your finance team has quietly begun trusting spreadsheets over the ERP, that is the signal worth acting on, not ignoring. The gap rarely closes on its own.

A Visibility Review is a low-pressure way to get an outside read on where your reporting trust is leaking, whether ownership, definitions, reconciliation or data entry, and what the most efficient fixes would be. No commitment to a wider engagement, and no assumption that the answer is new software. If that would be useful, it is a sensible first step.