The monthly query chase: one email instead of six

The monthly query chase is the job of finding every transaction you cannot classify and asking the client what each one was. Done by hand it becomes six separate emails over a fortnight. Written down as a workflow it becomes one email per client per month, drafted in minutes, with the amounts computed by a script rather than read off by eye. Build this one first: it repeats more than any other job in the practice and it is almost entirely templated once written down.

What counts as a query

A transaction is a query when its account is blank or sits in a holding account: Ask My Accountant, Uncategorised Expense, Uncategorised Income, Suspense, Unassigned, To Be Classified. Those names differ by platform and by whoever set the file up, so the workflow checks all of them rather than one.

What it is not is anything you could code by looking at the ledger yourself. Every avoidable question you send costs the client's patience, and patience is what you need when the query genuinely matters.

The procedure

1. Export the period. In Xero: Accounting, Reports, Account Transactions, set the date range, export to CSV. In QuickBooks Online: Reports, Transaction List by Date, same approach.
2. Run the script. It reports the source file, the row count, a control total and the exceptions, then every unclassified transaction grouped by contact with a line number on each.
3. Read the exceptions before the queries. A non-numeric amount or a missing date is a data problem. It belongs on your list, not in the client's email.
4. Draft one email per client. Grouped by contact, ordered by value, with a suspected duplicate flagged as a suspicion rather than a fact.
5. Check last month's answers first. Asking a client something they already told you is the fastest way to make the whole process look careless.

Why the model must not do the arithmetic

Language models handle twenty numbers well and a hundred badly, and the failure is quiet: the total comes back looking reasonable and wrong. On a query email that matters twice over, because the client checks the figure against their own bank and you lose the argument before it starts.

Every amount and count in this workflow comes from a bundled script. The model reads the request, runs the code, and writes the email around the result.

What the email looks like

Short, specific, and easy to answer in one line each.

A one-line answer against each is plenty, and saying so in the email gets you a faster reply than a polite paragraph.

What it cannot do

It cannot send. There is no email tool in the Xero connection at all, so the output is a draft for a human to send.

It cannot code the transactions. It asks the question. A person applies the answer to the ledger.

It does not watch the ledger. Nothing fires when an unknown transaction appears. The workflow runs when you run it, which for a monthly job is exactly right, and it sits naturally at the start of the month-end close.

For the wider picture of that boundary, see AI for accountants. Anything that has to happen on a schedule without a person present belongs in accounts receivable automation rather than an assistant.

Common questions

How long does this workflow take to build?

About an afternoon, and most of that is writing down how you already ask the question. The skill above is the finished version if you would rather start from something working.

Can it run across all my clients at once?

Through CSV exports, yes. Every live connection holds one organisation at a time, so a bookkeeper with twenty clients would reconnect twenty times. The export route is the one that scales across a book.

What if the client never answers?

That is a practice management problem rather than a workflow one, and it is the reason the email is short and ordered by value. Chasing the answer is the same job as the client email desk.