BeaksWhy an outdated SOP is worse than no SOP at all
An outdated SOP in an accounting or finance team does quiet damage. Why manuals typed once go wrong, and how to keep them alive as the work happens.
Most finance teams have a folder called "Procedures". Inside it sit documents written in a burst of enthusiasm two or three years ago, after a bad close or an audit comment. They look reassuring. The trouble is that an outdated SOP in an accounting firm is not harmless clutter. It is a confident set of instructions that is wrong, and it will be followed by whoever is newest and least able to tell.
No manual at all is at least honest. The new starter knows they have to ask someone. A stale manual hides the gap. They follow step six, the bank has changed its export format, the numbers do not tie, and nobody understands why.
How a manual goes stale
Take a hypothetical firm with 25 people. In the spring someone spends a weekend writing up the monthly payroll check: 14 steps, with screenshots. It is good. By autumn, three things have changed. The payroll software moved a report to a different menu. One client now pays a monthly allowance that needs its own line. The reviewer who used to sign off has left, and a different person does it with a different checklist in their head.
Nobody decided to let the manual rot. Nobody was assigned to update it, and updating it was never part of anyone's week. That is the real failure: a document written as a project, and a task that lives on as routine work.
The pattern is the same everywhere:
- The manual is written after the work, from memory, by someone with spare time.
- The work changes during the work, in small ways nobody records.
- The gap between the two widens until the manual is a historical artefact.
Why stale is worse than missing
There are three costs, and the first is the least obvious.
- False confidence. A partner sees a procedure exists and assumes the task is covered. It shows up as "documented" on a list when it should show up as a risk.
- Wrong work, done carefully. A new colleague who follows the steps exactly will produce exactly the wrong result, and will not question it, because the document told them to.
- Distrust of all documents. After one bad experience, people stop opening the folder. The good manuals go unread along with the bad ones.
That third cost compounds. Once a team learns that the procedures cannot be trusted, the only reliable source of know-how is the person who has done it before. You are back to single-owner tasks, which is the problem the manual was meant to solve. If that worries you, the single-owner tasks in your month end close are a good place to see how fast it adds up.
Write it while the work happens
The fix is not a better template or a stricter review calendar. Those help for a quarter. The fix is to change when the manual gets written.
A manual written during the work is closer to a by-product than a project. The person doing the task captures the steps as they go, once, and the next person to do it checks them against reality and corrects them. Concretely:
- Attach the manual to the task, not to a folder. If the checklist lives on the recurring task itself, whoever picks it up this month sees it at the moment they need it. A document in a shared drive has to be remembered and found.
- Make correction a normal act. The person doing the task fixes the step that was wrong, on the spot. A manual that can be edited in ten seconds gets edited. One that needs an approval workflow does not.
- Record the exceptions. The allowance for one client, the supplier that always sends a PDF instead of a CSV. Those are the details that never make it into a typed-once procedure and are exactly what hurts later.
- Date the last real use. "Last followed on 3 September by Priya" tells you more than "reviewed annually".
None of this is clever. It is a matter of putting the manual where the work is.
A manual is what an agent runs on
There is a second reason to care, beyond onboarding. If you ever want an AI agent to take on a recurring task, the written instructions are the only thing it has. An agent does not ask the colleague at the next desk. It follows the document, and it follows it faithfully, including the step that stopped being true in July.
So the quality of your documentation sets a ceiling on what can safely be handed over. A task with a live, recently used manual can start with an agent drafting the output while a person approves it. A task with a stale one cannot, and no tool changes that. We come back to this in how a finance team should let AI in, drafts first. The honest first step is to make the documentation true.
It is also why Beaks is built around the task as the place where the manual lives. The manual is attached to the recurring work, and it is as current as the last person who did it. It is a modest idea, and in our view the right place to start.
What to tell the team
Be plain about why you are doing this. Fresher manuals protect people from covering for an absent colleague with no guidance, and spare them the repetitive half of the job being re-explained every time somebody joins. They also make it possible, later, for some tasks to be handed to software. Say that out loud. A team that is told the truth will keep the manuals current. A team that suspects another motive will leave out the details that matter, and you will be back to a manual nobody can trust.
One thing to do this week
Pick one recurring task with a written procedure, and find the next person due to do it. Ask them to follow the document exactly and mark every step that no longer matches reality, in a different colour. Do it on a real run, not a rehearsal.
Count the marks. That number is the honest age of your documentation, and it is the best argument you will find for writing manuals while the work happens.
