Document and reporting automation

What this actually solves

Somebody in your business makes the same document over and over. They open the last one, save a copy, change the name, change the numbers, change the dates, export a PDF and send it. It takes twenty minutes and it happens several times a week, which is annoying but survivable.

The failure mode is what actually costs money. Occasionally the previous client's name survives somewhere in the document — in the footer, in a paragraph halfway down, in the file name. It goes out. The recipient notices, because recipients always notice. That is not an embarrassment, it is a lost deal, and it happens for a completely mundane reason: a human performing a find-and-replace task under time pressure for the four hundredth time.

The larger effect is speed, and it is the one that shows up in revenue. A business that sends the quote the same day wins materially more of them than one that sends it three days later, because the buyer is comparing options while the problem is still urgent. When a quote takes two days to produce, the delay is not a service issue — it is a conversion issue, and the owner usually feels it without being able to name it.

Reporting has a third driver that is often the strongest. If you are an agency, your clients expect a monthly report each. Producing twenty of them by hand is a week of somebody's month spent copying figures between tools, doing work that is entirely mechanical up to the point where somebody has to explain what happened and why.

What we do, and in what order

1. Read the last ten of each document. Not the template you think you use — the actual last ten that went out. This is where you find that there are four layouts in circulation, that the terms paragraph differs between them, and precisely which fields genuinely vary against which ones are constant and should be baked in. One day.
2. Build one clean template with named placeholders. Google Docs or Slides where the output is straightforward, HTML where the design has to be precise. Every variable region marked explicitly, and every previously hand-edited region resolved into either a variable or a constant. One to three days.
3. Fix the data source and the single point of arithmetic. Where each field comes from — Airtable, Sheets, the CRM, a form — and, separately and deliberately, the one place any calculation happens. The document renders results; it never computes them. One day.
4. Build the pipeline. Fetch the record, populate the template, render the PDF, file it in the right folder with a consistent name, and send it by the right channel. Around that: an authoritative numbering sequence, and an approval hop for the document types you have nominated. Three days to two weeks.
5. Test the money paths separately. Tax, discount, shipping and rounding are tested one at a time rather than as a single happy-path sample, because they interact and the interactions are where the errors hide. Alongside them the layout cases — the company name long enough to wrap, the line-item table that runs onto a second page, the zero-tax export invoice, the item with no price. One to two days.
6. Close the loop on records and hand over. Every generated document stored in Drive and logged as a row with its number, recipient, date and status, so a question about what was sent to whom has an answer rather than a search. Half a day.

Tools we typically use: the Google Docs and Slides APIs through Make or n8n for templated output, PDFMonkey, Documint or CraftMyPDF where the PDF has to be visually exact, DocuSign or PandaDoc where signature is required, Looker Studio where a live dashboard beats a monthly PDF, and Drive for storage.

What moves the price

How many document types. A single invoice pipeline is at the bottom of the range. Eight distinct document types with different data sources, different approval rules and different recipients is a different scale of work, and each type carries its own edge cases.

How finished the template has to look. A functional internal document and a designed, branded proposal that has to hold its layout across variable content length are not the same deliverable, and the second involves genuine design work.

Signature, approval and how scattered your data is. Adding a signature flow, or an approval gate with a named owner and a fallback when they are away, are each real additions. So is the case where the fields you need are spread across three systems that disagree about how a customer is identified.

What usually goes wrong

The arithmetic ends up living inside the document. A total is pulled from a spreadsheet cell reference that later shifts, or generated by an AI step that produces a plausible number rather than a correct one. It is right in testing and wrong in production, and nobody notices, because a wrong total looks exactly like a right one. The rule is absolute — one calculation location, and tax, discount, shipping and rounding each tested independently.

Numbering is treated as cosmetic. Invoice numbers get generated from a row position, or from a date, or from a formula that recalculates when someone sorts the sheet. Now two invoices share a number, or a number is missing from the sequence, and this surfaces at reconciliation or at audit — months later, when reconstructing what happened is far harder than preventing it would have been.

The template is signed off on one tidy record. It looks perfect with a short company name, three line items and a round total. Then a real customer has a trading name that wraps to two lines and pushes the totals block onto a second page, a discount row appears that the layout never allowed for, and one item is quoted on request rather than priced. That malformed document goes directly to your customer, and the reputational cost lands on you rather than on whoever built the template. Every layout extreme has to be run through before the first real document is sent.