Accounting Firm SOPs: Writing Procedures Your Team Follows

Why most firm SOPs die in a binder

Most SOPs fail because they are written for an imagined auditor, not for the person doing the work: too long, stored away from the work, owned by nobody. A procedure that takes longer to find than the task takes to perform will not be opened a second time.

The failure is rarely visible. The document sits in a shared drive looking like governance while the actual process lives in one senior person's head — which is exactly the situation SOPs were meant to fix.

Which processes to document first

Start with work that recurs, crosses more than one person, and hurts when done inconsistently: client onboarding, monthly bookkeeping, T1 intake, GST/HST preparation, payroll runs, year-end assembly. Skip anything performed once a year by one person who never changes — the return is not there.

A useful filter: if a new hire would do this task differently than your best person does it, and the difference would reach a client or the CRA, document it. If the difference stays internal and harmless, leave it alone.

Write at the level of decisions, not keystrokes

Document the order of operations and the judgement calls, not every click. Screenshots of software menus go stale within a version; 'confirm the fiscal year-end on file matches the ledger before opening the file' stays true for years. A good SOP is a checklist with judgement notes attached.

Each step should say what to do, what 'done' looks like, and what to check before moving on. Anything a competent person would figure out in ten seconds does not need a line.

• One sentence per step, imperative voice
• Judgement notes where the step involves a decision
• A definition of done for the final step
• No screenshots of menus that will move

Give every procedure one named owner

An SOP without an owner decays silently: the process changes, the document does not, and six months later the document trains people to do the work wrong. The owner is not necessarily whoever performs the work — the owner is whoever fixes the document when the work changes.

Put the owner's name and the last-reviewed date at the top of every procedure. A document that cannot say when it was last true should not be trusted.

Put the SOP where the work happens

A procedure stored beside the work gets read; a procedure stored in a policies folder gets archived. The strongest move is to convert each SOP into the ordered task list of the project it governs, so the checklist appears every time the work does.

This is how practice-management software earns its keep here. In SpidNums, a project carries its tasks in order for a given client and period, so the procedure is not a document someone must remember to open — it is the sequence the work moves through, visible in table or Kanban view.

Roll out with the team, not at them

Draft each SOP with the person who performs the process most often, then have the second-most-frequent performer run the work from the draft alone. Where they stall or improvise, the document is wrong. Two passes of that loop produce a procedure people follow because they recognise their own work.

Announcing a binder of procedures written by a partner over a weekend produces the opposite: quiet, permanent non-compliance.

Review on a fixed cadence and prune ruthlessly

Review every SOP twice a year, plus immediately after any software change or CRA process change that touches it. The review question is not 'is this still accurate' but 'is anyone still doing it this way' — when the answer is no, the document or the behaviour has to change.

Delete steps nobody performs. A procedure that contains known-dead steps trains the team to treat the whole document as optional, which is worse than having no document at all.