What this automation does
The numbers come from code and the words come from the model, and nothing goes out until both have been checked.
- Pull final numbers. Once the period is closed, the workflow pulls the P&L, balance sheet and cash summary for the period, the prior period, the same period last year and the budget, from QuickBooks Online, Xero or NetSuite.
- Build the fact sheet. Code computes every number the summary might mention, including changes in dollars and percent, gross and net margin, operating expense ratios, days sales outstanding and cash runway, and gives each fact an ID and a label.
- Add context. The controller adds a few bullets of known events in a short form, and the workflow attaches the largest movements by customer, vendor or account.
- Draft for the audience. The model receives the fact sheet, the context and an audience template, and writes the summary in that structure, using only facts it was given.
- Verify the numbers. A check extracts every number from the draft and confirms each one matches a fact in the sheet, allowing for rounding. Drafts with unmatched numbers are regenerated or flagged.
- Edit and send. The draft lands in a Google Doc next to the statements. The controller edits and sends it, and the final version is saved so next month’s draft can follow the same voice.
When it is worth building
It is worth building when someone spends hours each month writing the same kind of commentary, or when the commentary never gets written and owners receive a spreadsheet they do not read. It also helps when several audiences need different versions of the same numbers.
If you produce one short summary a quarter, writing it by hand with an AI assistant open next to you is fine. If your books close late or keep changing after close, fix that first with month-end close reporting, because a well-written summary of the wrong numbers is worse than none. If leaders mostly want to ask questions of the data rather than read a summary, natural-language SQL reporting may fit better.
Architecture
| Layer | What we use | Why |
|---|---|---|
| Statement pull | QuickBooks Online and Xero report endpoints through n8n, NetSuite through its REST web services | Final, closed numbers straight from the ledger |
| Fact sheet | A code step that writes labeled facts to Google Sheets or Postgres | Every figure the model may cite is computed exactly and reviewable |
| Context form | A short form or doc the controller fills in at close | Gives the model real causes instead of guesses |
| Drafting | Claude Opus 5.5 or Sonnet 5.5 through the API | Strong at structured, restrained business writing that follows a template |
| Number check | A code step that parses numbers in the draft and matches them to facts | Catches invented or mis-transcribed figures before a person reads the draft |
| Output | Google Docs, or email for internal audiences | Easy to edit, comment on and keep a history of what was sent |
How to build it
- Collect three past summaries. Use the best summaries your team has written. They define the target structure, length and tone better than any instruction.
- List the facts. From those summaries, list every kind of number that appears. That list becomes the fact sheet specification, computed in code for every period.
- Set materiality rules. Define when a change is worth mentioning, such as a dollar floor and a percent change together. Mark small-base percentages, like a 400 percent rise on a $200 line, as not reportable.
- Write audience templates. For each audience, specify sections, length, what to include and what to exclude. Department heads, for example, should not see payroll detail outside their area.
- Write the prompt. Tell the model to cite fact IDs inline (they are stripped before display), to say “cause unconfirmed” when no context explains a change, and to describe direction correctly for expenses, where down is usually good.
- Build the number check. Parse numbers, percentages and currency from the draft, normalize rounding and match each to a fact. Fail on any unmatched number.
- Run three periods back. Generate summaries for past months and have the controller compare them with what was actually sent before going live.
What breaks in production
- Invented causes. Without context, the model explains a revenue drop with a plausible story. The “cause unconfirmed” rule and the context form are what prevent this. Watch for vague causal phrases in review.
- Direction errors. “Expenses fell 12 percent, a concern” is a common slip. Label each fact with whether an increase is favorable and include that in the fact sheet.
- Rounding mismatches. The statement shows $1,248,503 and the draft says $1.2 million. The number check must understand rounding conventions or it fails good drafts.
- Fiscal calendars. A fiscal year that does not match the calendar year leads to wrong labels such as “Q3”. Pass period labels as facts and forbid the model from computing them.
- Pulled before close. A draft built on preliminary numbers gets sent. Trigger only on the closing date or an explicit “final” flag.
- Tone drift. Summaries become steadily more upbeat. Keep past approved summaries as examples and refresh them every quarter.
Timeline and cost
A single company with one or two audience templates usually takes one to three weeks, including the back-test. Lumeor builds it for $3,000 to $9,000, depending on the number of entities and audiences and whether you want board or lender versions with extra review steps. Model usage is a handful of calls per period, so running costs are negligible next to hosting. If you are choosing an AI assistant for your finance team more generally, ChatGPT vs Claude for business compares the two for everyday work.
How to measure success
- Controller minutes from final numbers to sent summary
- Sentences changed during review, trending down over the first few months
- Drafts blocked by the number check, and why
- Summaries delivered by the agreed day of the month
- Follow-up questions from readers, which should shift from “what happened” to “what should we do”