Automation gets pitched, fairly often, as a way to skip the documentation work. Stop writing procedures nobody reads and just build the thing.
It is exactly backwards. Automation is documentation, with the property that it executes. And writing the procedure first is how you find out whether the process can be automated at all.
The order people want to skip is: document, then standardize, then automate. Skipping to the end on an undefined process does not produce a shortcut. It produces a system that encodes one person's version of the work and breaks on every case they never thought to mention.
Writing the SOP is the analysis
This is the part that gets missed. Documenting a process is not preparation for the real work. It is a large share of the real work.
The act of writing it down surfaces things that were invisible while the process lived in someone's head:
The variation. Two people do the same task differently and neither knew. Sometimes one way is better. Sometimes they are handling genuinely different cases that were never distinguished.
The workarounds. The report pulled manually because the automated one has been wrong since a system upgrade. The approval that technically happens over chat. These are absent from every aspirational description of the process and present in every actual run of it.
The steps that exist for reasons nobody remembers. A reconciliation performed because of a system limitation that was fixed two years ago. These are surprisingly common and they are free to remove once identified.
Frequently the SOP alone captures most of the available benefit and shrinks the automation scope substantially. You set out to automate a twelve step process and discover it is really a six step process plus six steps of compensating for an earlier problem.
What a usable SOP contains
Write for a competent accountant who has never performed this particular task at this particular company. That reader knows what a bank reconciliation is. They do not know which account you use, which report you pull, which two systems disagree by design, or what to do about the recurring variance everyone has learned to ignore.
So:
- Which system, which report, which parameters
- What correct output looks like
- The common exceptions and what to do about each
- Who to go to when the exception is not on the list
- What evidence to retain, and where
That last point is not bureaucratic. If the task supports a control, evidence retention needs to be a step inside the procedure rather than a separate filing task, or it will lose to whatever else is happening at month end.
Task sizing
A task in a usable procedure has one owner, one unambiguous completion state, and one place it happens.
"Close AP" fails all three. It is six or seven tasks with different owners and different failure modes. If two people can reasonably disagree about whether an item is done, it is too big.
Breaking things up feels like it makes the documentation worse. A tidy list of twelve items becomes an untidy list of sixty. It is the right trade, because the twelve item list was a summary, and summaries cannot be delegated or automated.
The test: hand it to a competent accountant who has never worked here. Every point where they stop and ask a question is a task that was too big or a procedure that was missing.
Attaching procedures to the work
Here is the part that determines whether any of this survives contact with a real month end.
Documentation stored separately from the workflow does not get consulted. Not because people dislike procedures, but because finding the right one costs more than guessing, and guessing usually works.
The fix is to attach the procedure to the task. In a close checklist, that means every task links directly to the SOP for that specific task. Not to a folder. Not to a forty page manual with a table of contents. To the procedure for the thing in front of you right now.
Two things follow from that, and the second is the more valuable one.
First, coverage during an absence stops being an event. Anyone can pick up a task they have never performed and complete it correctly by following the linked procedure.
Second, the documentation stays current. Procedures rot because nobody encounters them. When the procedure is opened every period by whoever performs the task, an out of date step gets noticed and fixed immediately, because it is blocking someone right now. That is the whole mechanism, and it is fixable purely by changing where the documentation lives.
From SOP to automation
Once the procedure is written, deciding what to automate becomes close to mechanical. Read it and classify each step:
Clerical. Gathering, formatting, routing, matching, chasing status. No judgment, nothing being decided. This is the automation scope, and it is usually most of the volume.
Assisted judgment. A system can propose an answer with its reasoning attached and a person accepts or rejects. Useful as long as the reasoning is visible and rejecting is as easy as accepting.
Control point. Approvals, exception resolution, anything that creates an obligation or moves money. Stays with an authorized person.
You cannot do that classification on a process that exists only in someone's head. Which is why the sequence is not negotiable, and why teams that skip documentation end up automating the interesting parts rather than the expensive ones.
The objection
The usual objection is that documentation is a lot of work for a process that is about to change anyway.
Sometimes true. The answer is to write the procedure at the level of what the work is, not the level of exactly which buttons get clicked. Button level documentation goes stale with every interface update. A procedure that states the system, the report, the expected output, and the exception handling survives a UI change and most process changes.
And if a process is genuinely about to be replaced, documenting it is still how you find out what the replacement needs to handle.
The short version
You cannot automate what you have not defined. Writing it down is the analysis, not the preparation for it. Size tasks so they can be delegated. Put the procedure where the work happens, which is the only thing that keeps documentation alive. Then classify the steps and automate the clerical ones.
Most failed automation projects are undocumented processes discovering this the expensive way.