The End of Email Attachments: Fixing the Client Document Exchange Workflow in Audit
Every audit begins the same way: with a list. The “prepared by client” schedule — the PBC list — goes out to the client, itemising the trial balances, reconciliations, contracts, board minutes and supporting schedules the engagement team needs. And then, at almost every firm, a curious thing happens. The engagement that will be planned in specialist software, executed against a rigorous methodology, and reviewed through formal quality gates conducts its single most important information flow through the same tool used to circulate the office bake sale rota: email.
Everyone involved knows it is wrong. The partners know, because they sign engagement letters promising confidentiality and then watch draft financial statements travel as attachments. The seniors know, because they spend fieldwork evenings hunting through inboxes for the latest version of a schedule that exists in four. The clients know, because they are asked for the same file twice by two different team members. Audit client collaboration is the workflow where audits leak the most time and carry the most avoidable risk, and it has stayed broken not because firms are careless but because, until recently, fixing it properly meant building document infrastructure nobody had. This article is about what the fix looks like now — and why secure document exchange for audit has become a buildable feature rather than an aspiration, for firms in the audit and compliance sector and for the platform vendors who serve them.
The Life of an Evidence Request, As It Stands
Trace one line of a PBC list through a typical engagement and the problem explains itself.
The request goes out in a spreadsheet attached to an email. The client’s finance manager saves it, works through it over two weeks, and returns files in batches — some attached to replies, some to fresh emails with new subject lines, one through a personal file-sharing link because it was too big for the mail server. A junior saves the attachments to the engagement file, renaming them according to a convention that exists mostly in their head. Then the debtors reconciliation turns out to have an error; the client sends a corrected version; the correction lands in a thread only the senior is on. Three weeks later, a manager reviews testing performed against the superseded version. Nobody did anything unusual. Nobody broke a rule that was written down anywhere. The workflow itself produced the failure.
Multiply that by the eighty or two hundred lines of a real request list, then by every concurrent engagement in the office, and the aggregate is startling. PBC evidence collection is not a peripheral administrative chore; it is the supply chain of the entire audit, and it is being run through a tool with no inventory, no tracking and no controls.
What the Inbox Actually Costs
It is worth separating the damage into its four distinct strands, because they land on different desks.
Version sprawl lands on the engagement team. When evidence arrives as attachments, every copy is a fork. The question “is this the final version?” has no authoritative answer, only a social one — ask the client, ask the senior, compare file dates and hope. Time spent reconciling versions is pure waste, and testing performed against a superseded document is worse than waste.
A missing chain of custody lands on the firm when something is challenged. An inbox can prove that a file was sent; it cannot reliably prove which version the conclusion was drawn from, who altered a schedule between sending and filing, or when a correction actually arrived. In a fee dispute or a regulatory inspection, “we believe this was the version” is a sentence no partner wants to say.
Deadline chasing lands on everyone. Without a live view of what has been requested, received, and accepted, chasing is manual: seniors maintaining a tracking spreadsheet alongside the actual work, status meetings that consist of reading that spreadsheet aloud, clients receiving duplicate requests because two team members each own half a picture. Fieldwork weeks are lost not to auditing but to logistics.
Breach exposure lands on the firm’s risk register, and it is the strand that should worry leadership most. Financial statements, payroll data and board minutes travelling as email attachments are one mistyped address away from a reportable incident, and copies accumulate in personal inboxes and download folders on both sides — outside retention policy, outside access control, and effectively unfindable when a deletion obligation arrives. The confidentiality promised in the engagement letter is being undermined by the mechanism used to perform the engagement.
What Good Looks Like
None of this requires imagination to fix; the target workflow is easy to state.
The request list stops being a spreadsheet and becomes the system of record: every requested item is a tracked object with an owner on each side, a due date and a status. Each request is tied to a governed document workspace, so when the client’s finance manager responds, the file lands in the engagement’s container — not in an inbox — already associated with the request it satisfies.
From that moment there is one copy. If the client corrects the reconciliation, they update the same document; versioning is automatic, every version is attributed to a named person with a timestamp, and the superseded state is preserved rather than orphaned in a thread. The audit team works on the same copy the client can see. The entire category of “which version?” questions disappears, not through discipline but through architecture.
Around that single copy sits the governance the inbox never had: access limited to the engagement team and the client’s named participants, retention applied from the day the file arrives rather than retrofitted at archiving, and a record of who supplied and who accessed each piece of evidence. Status is visible to both sides — the client sees what is outstanding without waiting for a chasing email; the manager sees at a glance that thirty-one items of forty are in, six are overdue, and three await review.
Context arrives with the content, too. Because each file lands against a specific request, it carries its meaning with it: which item on the list it satisfies, which entity and period it relates to, who supplied it and who accepted it. The junior’s private filing convention — the fragile thread that used to connect an attachment to its purpose — is replaced by structure that survives the junior moving to another engagement.
And critically, good must be effortless for the client. The finance manager is doing this in the margins of a day job. If the portal demands new software, IT approval on the client side, or training, they will fall back to email within a week — and the firm’s carefully designed workflow will die politely of non-adoption. A browser, familiar Office documents, and access through the identity they already have: that is the adoption bar.
The Shape of a Build on SharePoint Embedded
What has changed recently is that this workflow no longer requires building document infrastructure from the ground up. SharePoint Embedded gives an application its own governed document containers inside Microsoft 365 — we have written an introduction to what SharePoint Embedded is — and its container model happens to fit the audit engagement almost exactly. Whether you are a firm commissioning a portal or a vendor adding this to an audit platform, a build using SharePoint Embedded for audit software takes a recognisable shape.
A container per engagement. The engagement is the natural boundary: its own container holds every requested item, working copy and supporting file, isolated from every other engagement and every other client. That isolation is structural rather than procedural — a misconfigured permission on one engagement cannot expose another — and it makes end-of-engagement archiving a clean, whole-container operation instead of a filing exercise.
A deliberate client access model. The client’s participants are external users, and their access is scoped: named individuals, invited to their engagement’s container and nothing else, contributing documents and updating their own submissions without seeing the audit team’s internal working area. Designing this boundary — what the client sees, what they can change, and when their access ends — is the most sensitive design decision in the build, and it deserves more care than any screen.
Requests as first-class data. The PBC list lives in the application as structured data — items, owners, due dates, states — with each item linked to the documents that satisfy it. This is what turns a document store into a workflow: the container holds the evidence, the request list gives it meaning, and the link between them is what managers, clients and eventually reviewers actually navigate.
Notifications and status doing the chasing. With requests as data, the chasing that consumes senior time becomes machinery: reminders as due dates approach, escalation when items go overdue, a dashboard replacing the status meeting. The aim is not to nag harder than a human; it is that the state of the engagement is always visible without anyone compiling it.
A defined close. When the engagement ends, client access is withdrawn, the container is frozen under the firm’s retention policy, and the evidence file — complete with its versions and attribution — becomes the archived record. The end of the engagement is a state transition, not a scramble.
For engineering teams, the implementation mechanics — container types, permission grants, Microsoft Graph — are covered in the technical walkthrough we published last week; this piece is deliberately about the workflow rather than the API surface.
A word on rollout, because workflow change in an audit firm succeeds or fails on adoption rather than architecture. The builds that stick start deliberately small: one office, one or two engagement teams, and clients chosen because the relationship can absorb a change of habit. That pilot does two jobs — it shakes out the client-side friction that no internal testing finds, and it produces the internal advocates who will carry the workflow to the rest of the practice far more effectively than a mandate from the executive. Scaling firm-wide is a decision to take after the pilot has proved the client experience, not before.
We would also note, from experience, that the hard-won lessons here are about inter-organisational data flow rather than documents per se. When we built the Orak integration hub for Workplace Pensions Direct — a system accepting sensitive pension data from many payroll systems in many formats and delivering it securely to many providers — the problem was the same shape: multiple organisations, disparate systems, sensitive data, and an ad hoc exchange process whose replacement had to be more secure and faster for every party, or it would not be used. Evidence exchange between an audit firm and its clients is that problem wearing different clothes.
Counting the Return
The business case assembles itself from the costs already described, but it is worth stating in the language of a partners’ meeting.
Recovered chargeable time is the headline. Hours currently spent reconciling versions, hunting attachments, maintaining tracking spreadsheets and chasing by email are hours of senior and manager time — the most constrained resource in the firm — returned to actual audit work or to margin. Even a conservative estimate of that overhead, multiplied across an office’s engagement portfolio, tends to dwarf the cost of the fix.
Risk reduction is the quieter half. Every evidence file that never travels as an attachment is breach exposure removed; retention applied from day one turns deletion obligations from an archaeology project into a policy; and a complete, attributed record of what was received and when is the difference between asserting your position in a dispute and demonstrating it.
The case is also unusually measurable, which helps it survive a partners’ meeting. Before building anything, baseline the current state on a handful of live engagements: count the evidence-related emails, the versions per key schedule, the days between request and acceptance, and the hours the senior’s tracking spreadsheet consumes. Those numbers give the project a target, and re-measuring the same things on the pilot engagements gives it a verdict — a far stronger position than justifying the investment on assertion.
And there is a commercial edge that firms consistently underrate: the client experience. The finance director who spends March in three different auditors’ inboxes notices the firm whose process was a clear list, one place, and no duplicate requests. For platform vendors the same logic applies at product level — evidence workflow is now a differentiator that procurement teams score, not a nice-to-have.
How McKenna Consultants Can Help
McKenna Consultants brings the two halves this problem actually requires: more than 25 years of building secure software for regulated data — including inter-organisational exchange systems like Orak, and a development partnership with share scheme administrators Howells Associates that has run since 2010 — and current, hands-on SharePoint Embedded engineering. We understand both why the inbox audit persists and precisely what it takes to replace it with something clients will actually use.
If your firm is ready to retire the attachment-driven PBC process, or your platform needs an evidence exchange capability your competitors cannot match, get in touch. We are happy to start with the workflow, not the technology — that is where the value is decided.
