A ninety-item query list is not a query list. It is an unranked exception report, and sending it to a client is how a firm loses a fortnight.
Key takeaways
You build a query list faster by separating two jobs that firms usually run together. Detection asks what in this file looks unsupported, inconsistent or out of pattern. Drafting asks how to put that to a client in a sentence they can act on today. Software is genuinely good at both, and it is good at them in different ways — detection wants rules and comparisons, drafting wants language.
The third job, ranking, stays with the professional. The reason is that the value of a query is not a property of the transaction; it is a property of the engagement, the materiality you set, and how much of the client’s goodwill you are willing to spend this week.
Most of what belongs on a query list can be found without any model at all. Unmatched items in a reconciliation. Ledger accounts with a balance and no supporting document indexed. Dates outside the period. Amounts that are suspiciously round. New counterparties that appear once for a large sum. Accounts whose balance moved by more than a threshold against the prior year with no explanation on file. Write these as deterministic rules, because a rule is reproducible, explainable to a reviewer, and does not change its mind next quarter.
Use a model for the residue that rules cannot express: reading a contract and noticing that its term does not match how the amount was recognised, or noticing that a director’s loan narrative in the prior-year file contradicts this year’s movement. That is where a language model earns its place — as a reader of documents, proposing candidates for a person to test.
The commonest defect in a query list is not that it misses things. It is that each line contains three questions and the client answers the easiest one. Enforce a structure and let the drafting step fill it: what we are asking for, why it matters in one plain line, who at the client is likely to hold it, and the date by which you need it. Ask for one artefact per query.
The second defect is vocabulary. “Please provide support for the accrual at 31 December” is a sentence written for the file, not for the owner of a plumbing business. “We have recorded $18,400 owing to a supplier at your year end. Please send the invoice or statement that shows what this was for” gets an answer. Drafting into client language is precisely the task generative tools do well and the one professionals most often skip because it feels like polish.
Rank on two axes. Materiality, obviously. But also latency — how long the answer takes to obtain. A small query that requires the client’s bank to retrieve an eighteen-month-old advice slip should be issued in the first batch even though it is immaterial, because it is the one that will still be open in three weeks. Firms that rank purely by dollar value discover this every season and rediscover it every season.
Then cut. If the first draft has ninety lines, the list that goes out has perhaps twenty-five, in two batches. The remainder either resolve themselves during fieldwork, or become a single conversation rather than sixty-five emails.
A query list is a working paper, and working papers get produced. Unlike a lawyer’s advice, an accountant’s file does not attract solicitor-client privilege — our sister firm’s article on solicitor-client privilege in a CRA audit explains what the privilege protects and, importantly, what it does not. So write queries as questions of fact, not as speculation about the client’s motives, and keep conclusions in the conclusions memo where they belong.
The same discipline reduces exposure on the other side. A query list that clearly records what was asked, when, and what was received is the contemporaneous evidence that the work was done — which matters if a file is ever tested against the standard applied in a professional negligence claim against an accountant. The records themselves remain the client’s obligation under section 230 of the Income Tax Act.
A firm in British Columbia runs its detection rules over a completed trial balance and the indexed file. The rules produce sixty-one candidates. The drafting step turns each into a client-readable sentence with an owner and a date. The manager then applies two filters: anything under the engagement’s materiality with no compliance angle is dropped, and anything requiring a third party to retrieve something is promoted to batch one.
Twenty-three queries go out in batch one on the day the file is received; nine follow after fieldwork. The two numbers worth tracking are the proportion of queries answered in full on first response, and the number of queries still open at the point where the file would otherwise be ready to sign. Both are measurable in your own practice without inventing anything. The standards set by the Auditing and Assurance Standards Board are the right reference for what the engagement type requires of the file itself.
Can AI decide when we have enough evidence?
No. Sufficiency is a professional judgment made by the person who signs, and no part of this workflow should be described to a client as the software concluding anything.
Should the query list go to the client automatically?
Not on the first engagement of the year. Review it, then automate the reminders on the accepted list — the chasing loop is a separate and safer thing to automate.
What about queries that repeat every year?
Those are not queries, they are a process defect. Move them into the request list issued at the start of the engagement and stop asking them at the end.
A 30-minute call is enough to tell you whether AI pays for itself here.
