How to build SOPs in an accountancy practice

Why SOPs matter for an accountancy firm

Standard operating procedures turn “how we do it” from something in a few people’s heads into something the whole firm can follow consistently. They cut errors, speed up onboarding, reduce founder dependency and make quality repeatable — which is why they’re usually one of the first things a fractional COO builds.

1. Start with the critical few

Don’t try to document everything. Begin with the processes that are highest-risk or most repeated: client onboarding, the core compliance jobs, delivery and review. Twenty solid SOPs that people follow beat two hundred that gather dust.

2. Keep each one short and visual

A good SOP is a clear checklist or short flow, not an essay. Steps, owner, inputs, outputs, and where to go if something’s unusual. If it’s hard to read, it won’t be used.

3. Give every SOP an owner

Each procedure needs a named person responsible for keeping it accurate. Ownerless documents rot.

4. Store them where the work happens

SOPs live or die on accessibility. Keep them in or next to your practice-management system, not buried in a shared drive nobody opens.

5. Make them living documents

Review SOPs on a regular cadence and update them when the process changes. A documented process the team helped shape and keeps current is one they’ll actually follow.

Common mistakes

• Documenting everything at once and burning out before any of it embeds
• Writing them too long, too technical, or in one person’s voice
• Treating them as a one-off project rather than an ongoing habit
• Storing them somewhere the team never looks

Getting this right across a whole firm is a big lift — sequencing it, embedding it and making it stick is a core part of the Optivo method.

Which ones to write, and in what order

The commonest failure is starting an SOP project rather than writing an SOP. A practice that sets out to document everything produces four excellent documents, loses momentum, and concludes that SOPs do not work for them.

Write them in this order, and write one before starting the next.

Notice that none of these is “the thing only one person knows how to do”, even though that is the obvious candidate. Start there and you are asking somebody to document a process while feeling that they are writing themselves out of a job, which is the hardest version of this conversation. Do it third or fourth, once SOPs are visibly normal.

How to write one in forty minutes

Do not write it at a desk. Sit with the person who does the job and watch them do it once, writing as they go. You will capture the three steps they would never have mentioned because they do not experience them as steps.

Then keep to this shape: what triggers it, who owns it, the steps as a numbered list, what “done” looks like, and the two or three exceptions with what to do about each. Screenshots for anything involving software, because a sentence describing where to click is always worse than a picture of it.

One page. If it runs past two, the process is too big and should be two SOPs — and the fact that it ran long is itself useful information about why that job is inconsistent.

The test that matters

Give the SOP to somebody who has never done the job and watch them attempt it without asking questions. Every question they have to ask is a gap, and you fix it there and then.

This takes half an hour and it is the step almost everybody skips, which is why most practices have a folder of documents that only make sense to the person who wrote them. An SOP that is clear to its author has not been tested; it has been drafted.

Why they get ignored, and what to do about it

They live somewhere nobody goes. A shared drive folder is where SOPs go to be forgotten. Attach them to the job in whatever system holds the work, so the document appears at the moment the task does. If that is not possible, a link in the job template is the next best thing.

There is no consequence. If work that ignored the SOP is accepted anyway, the SOP is advisory, and everybody learns that within a fortnight. This is the uncomfortable part: the document is not the mechanism, the review standard is. An SOP without a reviewer who declines work that did not follow it is a wish.

They went stale. Software updates, a rule changes, and the SOP now describes something that no longer exists. One wrong step is enough to discredit the whole document. Give each one a named owner and a review date — annually is enough for most, immediately after any software change for the ones that involve it.

They were written as a compliance exercise. If the team believe these exist to satisfy a regulator or to enable outsourcing, they will be written defensively and used never. Be straight about why you are doing it: so the work does not depend on anyone's memory, including yours.

What they are actually worth

The obvious benefit is consistency. The three that owners notice later are usually bigger.

Training collapses. A new starter with documented processes reaches useful output in a fraction of the time, and the cost of that time falls on the managers who are your scarcest resource.

Holidays stop being events. A practice where a week off requires a handover briefing is a practice where the work lives in people. Where it lives in documents, someone covers.

The firm becomes sellable. A buyer paying for documented processes is paying for a business. A buyer looking at undocumented ones is paying for a job and prices it accordingly — which is the substance of succession-proofing.

And there is a fourth that arrives quietly: writing a process down is the only reliable way to notice how daft parts of it are. A good proportion of the improvements in any practice come not from the SOP being followed, but from somebody having to write out what they actually do and hearing themselves say it.