Draft an Audit Evidence Request with AI at the Cursor

Short answer: speak the four facts an evidence request depends on (the control, the period, the requested document and the reason) into a compatible text field on Windows. Then use the supported AI Task workflow, giving the instruction and the four facts together in that one request, to turn them into a structured draft that flags what is missing. Review the draft line by line before anything leaves your hands. The reason is an element that can easily drop out of a hurried request, and speaking it while the walkthrough is fresh is one way to keep it.

This article covers what a request needs to carry, a fictional worked example, a reusable spoken template, a review checklist and a method for measuring time to reviewed output without relying on anyone's claimed savings. The writing practice is useful with any tool, including a keyboard and a blank page.

An evidence request is a short document that may be read days later, forwarded and queried. The recipient could be in finance, IT or operations. If any part is vague, the likely results are the wrong document, a late document or a round of clarifying emails.

This workflow uses four example fields:

• Control: the specific activity or check you are asking about, described in the client's terms where you can.
• Period: the dates the evidence should cover.
• Requested document: the exact item, extract, report or record, and in what form.
• Reason: why you need it, in plain language.

The reason is easy to omit. You know it from your understanding of the process, yet it may never reach the written request. Stating it helps the recipient choose the right report, date range and system.

Your firm will have its own templates and conventions, such as reference numbering, request lists and portals. Treat everything here as an illustrative writing practice. It is not a methodology, a standard or professional advice, and it does not replace your firm's guidance or your own judgement.

The first draft of a request is mostly recall and explanation: what you saw in the walkthrough and what you want to see next. Speaking lets you capture that in the order you remember it.

Spoken input has a cost. It arrives with false starts, filler and details out of sequence. This is where AI contextual formatting fits. You speak, SpeakLingo transcribes online, and an AI request can organise the content into a clear professional structure at the cursor, in the field where you were already working. Where the workflow fits, this can remove the separate AI window and the copy-and-paste step.

SpeakLingo calls this way of working Syping: speaking and typing used together, with text landing at your cursor. You can speak a request, correct a figure or name by keyboard, or speak an instruction to the AI and have the resulting text appear in the focused field. The features page gives wider product context.

Some boundaries apply:

• The workflow is designed for compatible focused Windows text fields and is not universally compatible. Test the applications you use for requests, such as your email client, your request portal's text box or your working paper tool, before relying on it.
• SpeakLingo is not an autonomous agent. It does not decide what to send or where to file it. Some apps can be set up with an optional Enter keypress after text is delivered, and in a chat box or a send-on-Enter field that could send the message. That is why the setup below turns it off.
• AI requests need an internet connection, an enabled service, your consent and the right access.
• Online transcription covers 99+ languages. Choose a supported language that suits you and your reader. This describes transcription only. It does not promise translation or equal AI output quality in every language, so read the output in whichever language it appears.

1. Check your delivery settings first. Turn off any automatic Enter or send behavior, so text arrives in the field as a draft and nothing is submitted without you. This matters most in fields where Enter sends a message.
2. Gather the facts. Have the control description, period, document name and your reason in front of you. The AI can only structure what you give it.
3. Place your cursor in the field where the request will live, such as a draft email body or a request-list comment box.
4. Prepare the inputs in plain order, as you would explain them to a colleague: control, period, document, reason. Include anything undecided, such as “sample not yet selected”. You will speak these inside the AI request in the next step, not as separate dictation beforehand.
5. Speak a constrained instruction that forbids invention. For example: “Using only these verified inputs, draft an audit evidence request. Inputs: [Control, period, requested document, reason]. Use a clear professional structure. Flag missing facts; do not invent them.”
6. Review the draft against your inputs before sending. Check every sentence for anything you did not say.
7. Complete the flagged gaps yourself. Supply the due date, contact and format from your own knowledge of the engagement.
8. Send or file through your normal route. That step is yours.

One boundary to keep in mind: ordinary dictation does not turn on AI. To get a structured draft, use the supported AI Task workflow and speak the instruction and the facts the draft needs (control, period, requested document, reason and any unknowns) together in that single request. Earlier dictations, text already in the field and whatever is on your screen are not automatically available to the AI. Screen context is a separate opt-in and may be sent to remote services, so leave it off unless you have decided it is appropriate for the engagement. If a fact is not in the request, the AI cannot use it and should flag it as missing.

The following example is fictional and illustrative. The company, control and details are invented to show the shape of the workflow. The draft below is an example of what a good result could look like, not output observed from a real session, and it is not drawn from any real engagement.

Scenario: An auditor is preparing a request to the finance systems team at a fictional company, Northbridge Components Ltd, about how changes to supplier bank details are approved.

Before: the spoken input, as transcribed

ok so for Northbridge the supplier bank thing, um, the control where somebody approves changes to supplier bank details before they get put in the system, we're looking at January through March, I need the log of changes for the period and then the approval evidence for the ones we pick, the reason is we want to understand who approved each change and whether it happened before the change went live, I think the finance systems team has it, we haven't picked the items yet

This holds everything the auditor knows, but it is not ready to send. The order is arbitrary, the filler remains, and the reader cannot tell which parts are firm and which are open.

The instruction

Using only these verified inputs, draft an audit evidence request. Inputs: [Control: approval of supplier bank detail changes before they are applied; Period: January to March; Requested document: change log for the period, plus approval evidence for selected items; Reason: understand who approved each change and whether approval preceded the change]. Use a clear professional structure. Flag missing facts; do not invent them.

After: an illustrative draft to review

Subject: Evidence request: supplier bank detail change approvals (January to March)

Hello [Name],

We are requesting information about the approval of changes to supplier bank details at Northbridge Components Ltd.

Control: Approval of supplier bank detail changes before they are applied in the system.

Period: January to March.

Requested documents: 1. The log of supplier bank detail changes for the period. 2. For the items we select from that log, the evidence of approval, including who approved and when.

Reason for the request: We want to understand who approved each change and whether the approval took place before the change was applied.

Open items to confirm before sending: - Exact period dates (start and end). - Due date for the response. - Name and system of the person or team holding the log. - Preferred file format. - How and when the items will be selected, since selection has not yet been made.

What the auditor still does

In review, the auditor checks that the control name matches the client's own description, replaces “January to March” with exact dates, and adds the due date and contact. The auditor also decides whether to request the log first and the selected-items evidence after the sample is chosen. That sequencing is a professional judgement for the auditor to make. If the AI had added a closing disclaimer or a statement about the control, the auditor would check it against the inputs and the firm's house style and remove anything unsupported.

Keep this near your keyboard and fill in the brackets aloud. Say “unknown” for anything you have not verified, so the AI has a reason to flag it.

Draft an audit evidence request to [recipient role] at [entity]. Control: [description in the client's terms]. Period: [start and end dates, or “unknown”]. Requested document: [exact item, system or report name, and form: extract, screenshot, file]. Reason: [what you need to understand, in one or two sentences]. Selection: [full population, selected items, or “not yet selected”]. Due date: [date or “unknown”]. Contact: [name or “unknown”]. Use a clear professional structure, a short subject line and a numbered list of documents. Flag missing facts. Do not invent facts, dates, names or reference numbers.

Two habits help. Always include the short “do not invent” instruction. And say what you do not know, because a request that lists its unknowns openly is easier to complete than one that hides them behind plausible-sounding text.

Run this before the request leaves your control.

Fidelity to inputs - Every fact in the draft traces to something you said or a source you hold. - No dates, names, system names, reference numbers or quantities have appeared that you did not provide. - Every flagged gap is resolved from real information.

Scope and wording - The control is described the way the client describes it. - The period is exact and consistent across subject, body and any attachment list. - Each requested document is specific enough to be produced without a follow-up question. - The reason is stated without suggesting a result.

Boundaries of the document - The draft contains no assurance opinion, no conclusion about the control and no statement of compliance. - Nothing in the wording reads as a finding. - Any line describing your firm's procedures matches your actual procedures.

Confidentiality and handling - You have considered whether the content, and any screen context, is appropriate to send to an online service. - The recipient list is correct. - Anything attached or linked is the right version.

Final decision - Automatic Enter or send behavior is off, and nothing has gone out without a read-through. - A named person has read the whole request and takes responsibility for sending it.

How much time a workflow saves depends on your requests, your habits and your review standards. You can measure it for yourself.

Use one measure: time to reviewed output. This is the time from starting to compose the request until you hold a version you are willing to send. Draft time alone misleads, because a fast draft that needs heavy repair has not saved anything.

1. Pick one type of request you write often, such as a follow-up request for approval evidence.
2. Record time to reviewed output for several requests written your usual way. Note the start and end time and the number of corrections you made after a first read.
3. Use the spoken workflow for several comparable requests and record the same things.
4. Add a note each time on whether the recipient needed to ask a clarifying question. Request quality also shows in what happens after sending.
5. Compare like with like. A simple request and a complex one are not comparable.

Treat a small sample as a prompt for your own judgement. If the spoken draft saves typing but adds review effort, or the reverse, your notes will show it. You can then adjust, for example by tightening the instruction or being stricter about verified inputs.

• Connectivity and access: AI requests need internet, an enabled service, your consent and the right access. AI formatting and spoken AI requests do not work offline.
• Remote processing: audio and text may be sent to remote services, and so may screen context if you opt in. Weigh this against your engagement's confidentiality expectations and your firm's policies, which are yours to interpret.
• Fallback transcription: if the internet is interrupted, offline English transcription is a fallback only, and only where it has been configured. Transcription has its own mode, setup and access requirements, so AI being unavailable does not show that transcription is available. You would then structure the request yourself.
• Output needs review: AI-generated text can be wrong, over-confident or inconsistent. You are responsible for what is sent.
• Compatibility: the workflow targets compatible focused Windows text fields, not every application. Try your own tools first.
• Scope of the draft: a request draft is a communication. It is neither an assurance opinion nor a compliance certification, and it should never read like one.