Skip to contentAnemo
EN
Contact

Why Year-End Reporting Takes Three Weeks

· 4 min read

When year-end reporting takes three weeks, almost none of that time is spent producing reports. It is spent reconciling systems that disagree with each other, and then explaining the differences to people who need one number. That is a data problem wearing the costume of a reporting problem, and a dashboard built on top of it makes matters worse rather than better.

This guide is for a manager or owner deciding whether the fix is a reporting tool, better data underneath, or neither.

Key takeaways

Where the three weeks actually go

Break the time into four buckets and count them honestly for one cycle. The answer is usually the same everywhere.

Extraction. Pulling data out of the finance system, the operational system, the e-commerce platform and two spreadsheets, each in its own format and on its own schedule.

Reconciliation. Working out why the sales figure in one system does not match the other, and which one to believe. This is nearly always the largest bucket.

Definition arguments. Whether a return counts in the month it was sold or the month it came back, whether an order is revenue at checkout or at dispatch, whether a cancelled subscription counts. These are business decisions that nobody has written down.

Presentation. Actually building the report. Usually the smallest part, and usually the part people try to solve.

Why a dashboard does not fix it

A dashboard pulls from the same sources and applies the same definitions. If the sources disagree, the dashboard will display one of the disagreeing numbers, quickly and attractively, and people will act on it.

The damage is subtle. A slow spreadsheet process at least has a person in the middle who notices when something looks wrong. An automated dashboard removes that person and keeps the error.

So the order matters: agree definitions, fix the sources, then automate. Doing it in the other order produces a dashboard that gets quietly abandoned within a year, which is a common and expensive outcome.

Start with the definitions

This is the cheapest step and it is almost always skipped. Write down, on one page, how each key number is defined: revenue, orders, active customers, stock value, margin. For each, state the moment it counts, what is included, and what is excluded.

Circulate it and expect disagreement. That disagreement is the actual problem, and it is better to have it in November than in the middle of the close.

Then find where the sources disagree

For each number, identify the systems that hold a version of it and which one is the authority. Most organisations have never formally decided this, which is why the reconciliation exists.

Once one system is named as the source for each number, two things follow: the other systems can be corrected against it, and future reporting can be built from it rather than from a negotiated blend.

What to automate first

Automate extraction before presentation. Getting the same data out of the same systems, in the same format, on a schedule, removes the most tedious part and does not depend on resolving every definition question first.

After that, automate the reconciliation checks rather than the reconciliation itself: a report that flags where two systems disagree, run weekly, turns an annual crisis into a small weekly task.

If this year's close shows that the reporting problem is really a data problem, Discuss Your Plan.

Frequently asked questions

Do we need a data warehouse?

Possibly, but not as a first step. A warehouse is useful once definitions are agreed and sources are named, and it is an expensive way to store the same disagreement if they are not.

How do we know whether this is a tooling problem?

Count the hours. If most of the time goes into reconciliation and definitions, tooling will not help much. If most of it goes into manual extraction and formatting, tooling will help a great deal.

Who should own the definitions?

The business, not the technical team. Whoever is accountable for the number should decide what it means, and the technical work follows from that decision.

Related services

Related reading

Building the product for what comes next

We would rather deliver one product that holds up than three that have to be rebuilt. That standard is the same on every project, whatever its size.

Ali Boran GazelCEO

Contact us