Workflow teardown · 2026 · Accounting & bookkeeping firms

The document chase: every firm runs this loop, almost nobody has mapped it.

By Daniel Sinukoff · Published August 12, 2026

You need a document from a client. You ask. They don't send it. You ask again. Below is that loop written out in full — where the elapsed time actually goes, what is safe to automate, and what has to stay a human decision. If yours works differently, tell me where I've got it wrong.

Tell me where this is wrong AI for accounting firms

A T4. A bank statement. The receipt for the thing they expensed in March. The signed engagement letter. The one invoice that makes the reconciliation balance.

Chasing client documents is the single most repeated process in most accounting and bookkeeping practices, and it is almost never written down as a process. It lives in individual inboxes and individual heads, which is exactly why it is hard to improve — you cannot fix what nobody has drawn.

So here it is, drawn. This is how the loop usually runs. Some of it will be wrong for your firm, and the parts that are wrong are the interesting ones.

The loop

Ten steps, per document, per client, per engagement

Read down the list and note which steps in your firm are owned by a named person, which are owned by a system, and which are owned by nobody in particular. That third category is usually where the trouble is.

01Someone notices a document is missing
02Someone works out who to ask
03Someone writes the request
04The request goes out
05Nothing happens
06Someone remembers to follow up
07Something arrives
08Someone checks whether it is the right thing
09Someone files it and updates the status
10Repeat

Step 1 is a person noticing. Usually mid-task: a preparer is working a file, hits a gap, and stops. Because the trigger is human attention, it happens at different times on different files and depends on who is working that day.

Step 2 is longer than one hop more often than people expect. The client contact, sometimes their bookkeeper, sometimes whoever actually holds the login. For a corporate client it may be a controller who then has to ask someone else.

Step 3 gets rewritten from scratch most times, because the previous request is buried in a thread. Tone gets adjusted for the client, and adjusted again if it is the third ask.

Step 4 frequently happens twice. Email, usually. Sometimes a portal the client does not check. Sometimes a text, because that is the only channel that works for that person. More than one channel for the same document creates a second problem: now there are two threads and no single answer to "did we ask yet?"

Step 5 is the load-bearing one. Most of the elapsed time in this workflow is spent here, waiting.

Step 6 is where it actually breaks. The reminder lives in someone's memory, a task list, a spreadsheet, or a flag in practice management — which one depends on the person. Some follow-ups never happen. Some happen twice from two different people, which the client notices and remembers.

Step 7 rarely produces exactly what was asked for. A phone photo of a page. Three months when you asked for one. A reply on the wrong thread.

Step 8 is judgement, and it requires knowing what the file actually needs.

Step 9 is often a different person than the one who asked: rename, file, tick the checklist, tell the preparer they are unblocked.

Where the cost is

Not in writing the email

Writing the request is fast. The expense sits in waiting, remembering, and multiplying — steps 5, 6 and 10.

One document is trivial. The workflow gets expensive because it runs hundreds of times in parallel, each instance holding a small piece of someone's attention, and because the state of every instance lives somewhere different.

The single most expensive failure is a request that is never followed up and gets discovered late, when the deadline is closer and the client is less patient.

05Waiting — most of the elapsed time
06Remembering — where it breaks
10Multiplying — why it costs

What automates, and what genuinely does not

This split matters more than the automation itself. Getting it wrong is how these projects fail.

Mechanical — safe to automate: detecting that a request has gone unanswered for a set number of days; sending the follow-up on a schedule, in thread, through the channel that client actually responds to; preventing two people chasing the same document; holding the state of every outstanding request in one place; routing an arrival to the right file and telling the person who was blocked; flagging when what arrived does not match what was asked for.

Judgement — has to stay human: deciding a document is required in the first place; deciding whether what arrived is actually sufficient; deciding when chasing should stop and a conversation should start; anything touching a client relationship that is already strained; anything with a filing or compliance consequence.

The honest version of this does not remove the person. It removes the remembering, and it makes the state visible. A person still decides what is needed and whether what arrived will do.

Two systems, one approval gate

In most firms this workflow touches exactly two systems: wherever the request goes out — email, or a client portal inside practice management — and wherever the answer has to end up, the document store or the ledger.

Two systems and one approval gate is deliberately the smallest useful unit. It is a boundary that can be scoped, tested, and then accepted or rejected on evidence, rather than a platform migration that takes a year and cannot be evaluated until it is too late to change course.

A controlled version of the loop looks like this: every outstanding request is one row with a state — asked, chased, arrived, verified, filed. Follow-ups fire on a schedule, in the original thread, unless a person has paused that client. A person approves anything client-facing that is not a plain reminder. Arrival routing is automatic; sufficiency checking is not. Every action is logged, so a partner can see what went to whom and when. And there is a stop control a person can hit per client, immediately.

Note what is absent: any promise about how much time this saves. That depends on your volume, your client mix, and how your firm works today. Anyone quoting a number before looking at your file list is guessing.

Is this how it works at your firm?

Genuinely — the parts I would expect to be wrong somewhere:

Whether step 6, the follow-up, is owned by a person, a system, or nobody.
Whether the request channel and the filing destination are really two systems, or more.
Whether "the wrong thing arrived" is a real problem for you or a rare one.
What your busiest month does to this loop.

Tell me where I have got it wrong. If it is useful, I will write up the same teardown for whichever workflow you would actually want mapped, and you will get it in writing — no call required.

I will also tell you plainly if a workflow is not worth automating. That answer is free, and it is frequently the right one.

Tell me where this is wrong How process mapping works