Automation patterns
The shapes automation takes
Every workflow has a shape. Some steps have to wait for the step before them; some can run at the same time; some logic gets repeated across dozens of files. Match the automation to that shape and it feels natural; fight the shape and it stays fragile. Three shapes cover most of tax work, from a single repetitive workbook to a whole group of entity workbooks.
Serial: the pipeline
- The shape
- Steps run in a strict order, and each one uses what the step before it produced. One piece of work moves down the line: the output of one workbook becomes the input of the next.
- Where it fits
- Work where each step depends on the one before it, and calculations feed other calculations. Capital cost allowance is a clear example: the inputs go into the CCA schedule, the schedule produces the deduction, and that deduction flows into your book-to-tax adjustments. You cannot make the adjustment before the deduction exists, or the deduction before the inputs are in.
- A tax example
- In our SR&ED automation, the back half of the work is strictly in order: the extracted figures are used to prepare a workbook, the workbook populates an upload template, and the template is loaded into the tax software, one step at a time. Each step needs the finished result of the step before it, and the part that drives the tax software has to be worked one screen at a time.
- Watch for
- When a step is blocked, the whole line stops, and that is the design working: a checkpoint that prevents bad work from moving forward catches the problems that should be resolved before the work reaches your reviewer. Build each step so that if it stops, it tells you plainly what failed and why, so the problem is easy to find and fix.
Parallel: fan out, fan in
- The shape
- Several tasks that do not depend on each other run at the same time, then their results come together at the end. The whole job takes as long as the slowest task, not the sum of all of them.
- Where it fits
- Work that splits into pieces that do not need each other: one document per reader, one entity's numbers per calculation, one jurisdiction at a time, where no piece needs another piece's result before it can start.
- A tax example
- In our SR&ED automation, several source documents are read at the same time. The financial statements, the project write-up, and the prior notice of assessment each go to their own reader, and each reader simply pulls out the numbers and facts it finds. They can run together because they do not depend on each other: reading one document never changes what another reader sees. Once every reader is finished, the results are combined and checked before anything moves on.
- Watch for
- The pieces have to be genuinely independent. If one secretly needs another, or they share a file, or one assumes the other has already run, doing them at the same time will produce wrong numbers. So do the checking where the results come back together: reconcile the combined result before it goes any further, because that is the first place a hidden dependency will show up.
Hub and spoke: build once, roll out to everyone
- The shape
- One central workbook, the hub, holds the master copy of the logic, plus a simple list of every workbook and the version it is running. The entity workbooks, the spokes, each pull their updates from the hub, and they never talk to each other. Fix or improve the logic once at the hub, and every workbook picks up the change.
- Where it fits
- A group where many entities or divisions run the same calculations: one place to fix a problem, one version history, and one clean way to roll a change out to everyone. The same shape also handles consolidation, where many workbooks feed a single one.
- A tax example
- A corporate group where more than forty entity tax-provision workbooks share their automation from one hub. Each workbook checks the hub, sees what has changed, and installs the update once its owner approves, so nothing changes underneath anyone without their say-so. Because each workbook updates itself rather than being changed from the centre, one bad update can never break all forty at once.
- Watch for
- The hub is the one thing everything depends on, so keep it easy to see into: a clear list of what each workbook is running and which version it is on, a status you can read at a glance, and failures that say what went wrong. And decide on purpose how far a single change is allowed to reach, so one mistake touches one workbook, not all of them.
Most real systems mix the shapes
The quick way to automate is to copy what a person does, step by step. The better way is to look at how the work actually flows, what has to wait, what can run at the same time, what gets repeated across many files, and build to that. Most real systems use more than one shape. Our SR&ED automation reads several documents at once, keeps the part that drives the tax software strictly in order, and puts a review step between each stage. The provision demo is a hub whose refresh mostly runs in order, but whose imports can happen in any order. Getting the shape right is most of the work; once it is right, the automation almost writes itself.
Not sure what shape your process is?
Describe the workflow that hurts. We will read how the work actually flows and suggest the smallest automation that fits it.