Why bookkeepers still rebuild the same client report every month
Thirty to forty-five minutes per client, twenty clients deep, and none of it is billable. It persists because the work sits in the gap between systems that will never be integrated.
Ask a bookkeeper what the last week of their month looks like and you get a version of the same answer. Pull the P&L out of QuickBooks or Xero. Pull the bank transactions. Pull the payroll register. Open last month's workbook, save a copy, rename it, paste the new numbers in, check the formulas didn't shift, fix the chart that broke, export a PDF, write two sentences of commentary, send it.
Thirty to forty-five minutes. Then do it again for the next client.
At twenty clients that is north of thirteen hours a month. Almost none of it is billable, because no client pays for the assembling — they pay for the interpretation, which is the part that gets squeezed when the assembling runs long.
Why it hasn't been automated already
The obvious question is why software hasn't eaten this. Reporting tools exist. Accounting platforms have report builders. There is no shortage of dashboards.
The answer is that every one of those tools works by integrating with data sources one at a time, and each integration has to be paid for by the customers it unlocks. QuickBooks has millions of users, so everyone integrates QuickBooks. Xero, the same. Stripe, Shopify, Gusto — all fine.
Now think about your actual client list. There is one on a regional point-of-sale system with four hundred installs nationwide. One whose inventory lives in an industry ERP you had never heard of before you took them on. One who runs a wholesale portal that exports a CSV and nothing else. One who maintains a spreadsheet by hand and emails it to you on the third.
Nobody is ever going to build a connector for those. The engineering cost is the same as building one for QuickBooks and the payoff is four hundred businesses, most of whom will never buy reporting software. The maths does not work and it never will.
And those are precisely the clients whose reports take all afternoon. The work that survives automation is the work sitting in the gap between systems that will never be integrated.
What actually gets rebuilt
It is worth being precise about the monthly work, because "building a report" hides several different jobs:
- Fetching. Logging into three or four systems and exporting files.
- Understanding. Working out that this export's "Net" column means something different from last quarter's because someone changed a setting.
- Joining. Lining up the payroll register against the P&L against the bank feed, usually on date and sometimes on a code only you know the meaning of.
- Computing. The formulas, which have not changed in two years.
- Presenting. Making it look like something a client should pay for.
- Interpreting. The two paragraphs at the top that are the only part the client actually reads.
Steps 3, 4 and 5 are identical every month. They are also the ones eating the time. Step 6 is what you are being paid for, and it gets whatever is left.
The thing that makes it hard to fix badly
The obvious fix is to write it down once — a template, a macro, a saved workbook — and most people have tried. It works until an export changes shape. A column gets renamed, a report gets split in two, a date format flips, someone exports with a different set of fields ticked. Then the template either breaks loudly, which costs an hour, or keeps working and quietly computes the wrong number, which costs a client.
That is the actual bar for automating this work: not "can it produce a report" but "can it notice when the file underneath it changed, and say so in language a human can act on."
Anything that cannot do that is a template with extra steps.
Early access
We are building this.
Databoat rebuilds recurring reports from the files your systems export — no connector required. Tell us which report you rebuild every month; it shapes what we support first.