Building an owner's report that assembles itself

What should actually be in an owner's report?

Only the things you would act on before the following Friday. Everything else is reference material, and reference material belongs in a quarterly review where you have time to think about it.

For most professional firms the useful set falls into five groups:

1. Money in and money owed. Cash at bank, invoices raised this week, invoices paid, total debtors, and the value of anything past your standard terms. If you look at one section, it is this one.
2. Work won and lost. New enquiries, proposals sent, work accepted, work declined or gone quiet. Numbers plus the names, because in a boutique firm the names are the information.
3. Work in progress against capacity. Open jobs or matters, hours or days committed, and how that compares with the capacity you actually have next month. This is the number that tells you whether to sell or to hire.
4. What has slipped. Anything past a promised date, anything sitting untouched beyond a threshold you set, anything waiting on a client for too long. Exceptions only.
5. A short list of things needing a decision. Three lines at most, generated from the exceptions above.

Resist the urge to add. A report with forty numbers gets skimmed and then ignored, and an ignored report is worse than none. If you cannot say what you would do differently because of a number, take it out.

Where does the data come from?

From the systems people already use to do the work, read through their own reporting or interfaces, with one system nominated as the authority for each number.

In a typical practice the sources are:

• Accounting software for cash, invoices raised and paid, debtors ageing
• Practice management or CRM for jobs, matters, stages, promised dates, owners
• Timesheets or job tracking for hours, work in progress, capacity
• The inbox or shared mailbox for enquiries that never made it into the CRM
• Calendars for meetings held, which is a decent proxy for pipeline activity in advisory work

That fourth one is where most of the mess lives. Enquiries that arrive by email and get answered by a partner without ever being logged are invisible to every other system, and they are frequently the ones that matter. If the report shows six enquiries and everyone knows the real number was nine, the report loses authority immediately.

You have two honest options. Either fix the intake so enquiries get logged automatically, or have the report count enquiry-shaped emails and label that number as an estimate. What you should not do is quietly report the CRM number as though it were complete.

How do you handle systems that disagree with each other?

Decide in advance which one wins, write it down, and have the report show the disagreement rather than hide it.

Every firm running more than two systems has definition drift. The CRM thinks a job is won when the proposal is accepted; the accounting file thinks it is won when the deposit clears. Neither is wrong, but a report that mixes them produces numbers no one can reconcile.

The fix is unglamorous. For each metric, write a one-line definition and the source system: "Work won = proposals marked accepted in the CRM, dated by acceptance date." Put those definitions in a footer on the report itself. When someone questions a number six months from now, the definition is right there, and the argument takes two minutes instead of an afternoon.

Where two systems should agree and do not, show both and flag the gap. A line reading "invoices raised this week: 14 (CRM) / 12 (accounting)" is more useful than a confident single figure that is wrong.

Should AI write the commentary?

It can draft it. It should not calculate anything, and its explanations should be read as suggestions rather than conclusions.

The split that works is simple. Code or a query engine produces every figure, deterministically, the same way each week. A model then receives those figures alongside last week's and writes a short plain-English summary of what moved and what sits outside normal range. Models are good at that, and it saves the reader comparing columns.

Two guardrails. First, the model gets the numbers, not the raw data, so it has nothing to compute and no opportunity to invent. Second, the commentary sits in its own clearly marked block, so nobody confuses "debtors rose 18%" with "debtors rose because two clients are waiting on their own funding", which the model cannot know and will sometimes assert anyway.

If you use a hosted model, check what client information ends up in the prompt. Aggregate figures are usually low risk. Client names and matter detail are a different question, and one worth putting to whoever handles your privacy obligations before you send them anywhere.

Why does a human still need to read it?

Because an automated report that is wrong is more dangerous than no report at all, and you only find out it is wrong by checking it against the source.

Run a calibration period of at least four weeks. Each Friday, one person opens the report and the source systems side by side and confirms every figure. It takes twenty minutes, finds the definition errors that only surface with real data, and builds the confidence that lets you stop checking later.

Keep a light human step permanently. Whoever receives the report first should be able to add two lines of context and hold it back if something looks wrong. In a small firm that is about five minutes.

How do you stop it quietly reporting stale numbers?

Make every section state where its data came from and when, and make a failed connection produce a loud gap rather than a zero.

This is the failure that costs people money. A connection expires, the report keeps arriving, a section quietly shows zero, and everyone reads it as a slow week. Three weeks later someone notices that debtors have not moved since the credentials broke.

Build the report so it cannot do that:

• Timestamp each section with the time its source was last read successfully.
• Distinguish zero from unknown. A genuine zero prints as 0. A failed pull prints as "source unavailable" and the section is visibly incomplete.
• Alert on failure, immediately and to a person. Not into a log nobody opens.
• Refuse to send a report that is missing money data. If accounting did not respond, the report holds and someone gets a message. A late report is a minor annoyance; a confidently wrong one is not.

The same principle covers a workflow that has stopped firing entirely. If the report has not been generated by a set time on Friday, something should say so.

What to do next

Write the report by hand once. Open every system, pull every number, and type it into a document. That exercise tells you which numbers you actually reach for, which ones you skip, and which sources are painful to get at. Almost everyone cuts their list by a third after doing it.

Then automate the easiest three sections first, leave the rest manual, and send it. A partly automated report that arrives every Friday is worth more than a complete one that is still being built in six weeks.

Add the commentary layer last, once the figures have been correct for a month. If you would rather have the pull built in your own accounts and handed over documented, that is a typical Shift build, and the sequence is the same either way: numbers first, narration later, and a person reading it before anyone relies on it.