Why does our monthly report take days to put together?

Where do the days actually go?

Rarely on the report itself. They go on everything before it.

Someone exports last month's figures from the accounts package, then the CRM, then the job system. Each export lands in a different layout, so the columns get rearranged by hand. Last month's report gets copied, the old numbers get pasted over, and the formulas that broke in the process get patched. Then somebody notices that sales and accounts disagree about a total, and the afternoon goes on finding out why.

By the time the report reaches the directors, most of the effort has gone on moving data, not reading it. And the person who builds it is usually the only one who knows which of those steps can be skipped and which cannot.

Why does nobody trust the numbers?

Because every hand step is a chance for the figures to change without anyone meaning them to.

A row pasted twice. A filter left on when the totals were copied. A customer's name spelled two ways, so they appear twice in the top ten. A correction made directly in the report one month, which never made it back to the source, so the next month quietly undoes it.

Spreadsheets add a subtler trap. Google's help page for the QUERY function explains that where a single column holds mixed data types, the majority type decides the column's type for the query, and minority types are treated as null values. In plain terms, if most of a column is numbers and a few cells hold numbers stored as text, those few can drop out of a QUERY summary as blanks. The total is just slightly wrong, and nothing on screen says why.

Once people have caught a report being wrong a couple of times, they stop believing it. Then they build their own version on the side, and now there are two reports to argue about.

What is the alternative?

One source of data, and many reports that read from it.

The raw data comes into one place, ideally straight from the systems that create it, and nobody edits it by hand. Every report is built on top with formulas, pivot tables or a reporting tool, so it recalculates from the source rather than being rebuilt each month. If a number is wrong, you fix it at the source, and every report that uses it is right from then on.

This is less about tools than about discipline. The rule is that the report never holds a figure someone typed.

	Built by hand each month	Built from live data
Where the numbers come from	Exports pasted into a copy of last month	One source tab or database, fed automatically
How long it takes	Days, depending on who is in	A quick check, once it is set up
What happens to a correction	Made in the report, lost next month	Made at the source, carried into every report
Who can produce it	The person who built it	Anyone who can open it
Why people doubt it	Nobody can trace a figure back	Any figure can be traced to its rows

What can Google Sheets do here?

More than most monthly reports use. Three features cover a lot of ground.

The first is importing rather than pasting. IMPORTRANGE imports a range of cells from another spreadsheet, so a report can read from the sheet where the data actually lives. Google's guidance is to limit chains of IMPORTRANGE across several sheets, because each link adds delay, and it notes that spreadsheets must be explicitly granted permission to pull data from each other. Read from the source, once, and keep the chain short.

The second is the pivot table. Google's guide to pivot tables says the pivot table refreshes whenever the source data cells it is drawn from change. It also lets you look at the source data rows behind any cell in a pivot table, by double clicking the cell with the pivot table editor open. That second part is what rebuilds trust. When a director asks where a number came from, you can show them the rows instead of promising to check.

The third is a schedule. Apps Script's time driven triggers let a script run at a particular time or on a recurring interval, anywhere from every minute to once a month. A short script can pull the latest data in overnight, check it for the obvious problems, and have the report ready before anyone logs on.

If the data lives outside Google, the same principle holds with different plumbing. Many accounts packages and CRMs can export data or be read through an API, so check what yours offers. We build that kind of feed as process automation, and the Google side through our Apps Script service.

What should you ask before building a dashboard?

Three questions, and it is worth answering them on paper before anyone opens a tool.

Who reads it, and what do they decide from it? A report that changes no decision is just expensive typing. If the honest answer is that it gets filed, shorten it or stop producing it.

Where does each figure come from? Name the system for every number. If two systems both claim to hold the same figure, decide which one wins before you build, or the dashboard will automate the argument.

What would make someone stop trusting it? Usually it is one known problem, such as a missing category, a manual adjustment or a figure that needs a judgement call. Fix that first, or show it plainly, and the rest of the report gets believed.

Where do people get this wrong?

The common mistake is automating the copy and paste instead of removing it. A script that faithfully recreates the old monthly ritual, export, paste, rearrange, will reproduce the old errors faster.

The second is building a dashboard before the data is clean. Charts make bad data look confident. If the customer list has the same company under three names, a beautiful chart will show three companies.

The third is leaving manual adjustments in the report. Every business has some: a one off credit, a late invoice that belongs to last month. Those belong in the source, with a note, so they are applied the same way every time and anyone can see them.

The fourth is one person owning the whole thing. If the report only works when its builder is in, it is a risk, however good it is. Write down where every figure comes from, on the report itself.

When is this not the answer?

When the report is your statutory accounts or your VAT return. Those come from your accounting software and your accountant, not from a homemade dashboard. A management report can sit alongside them, but it is no substitute.

When the report is produced once a year. The effort of setting up live feeds is unlikely to pay for itself.

When the source data is genuinely poor. If nobody records job costs consistently, no reporting tool will fix that. Start with how the data is captured, and the report gets easier on its own.

And when nobody reads it. Then the answer is not automation. It is deleting it.

Where do you start?

Take last month's report and, for each figure, write down where it came from and how many times it was touched by hand. That list tells you which parts can come from live data straight away and which need fixing at the source first.

If you have the list and want to know what it would take to build the report once and stop building it every month, tell us what's stuck and we'll map the quickest fix. Time to talk yet?