Most accounting teams have a close checklist. Far fewer have one that works when the person who normally performs a task is unavailable.
That is the distinction worth caring about. A checklist that lists tasks is a memory aid for people who already know how to do them. The moment someone unfamiliar picks up an item, the checklist stops helping, because it records what has to happen and says nothing about how. The knowledge lives with a person, and the checklist only points at where that person would have started.
I ran into this directly. In my role managing accounting for a multichannel consumer products company, I built a close checklist where every task links directly to its SOP, so any team member can pick up an unfamiliar close task and complete it by following the documented procedure. That single structural change did more for the reliability of our close than any amount of encouraging people to document their work.
Here is how to build one.
Start by writing down what actually happens
Not what should happen. What does.
The first version of most close checklists is aspirational, because it gets written by someone describing the process from memory rather than watching it. The result is a tidy document that omits the three workarounds everyone actually uses, the report someone pulls manually because the automated one has been wrong since a system upgrade, and the approval that technically happens over a chat message.
Run one close with a blank document open and record the real sequence, including the parts that are inconvenient to admit to. You are not documenting the process in order to judge it. You are documenting it so it can be handed to someone else, and a handoff that omits the workarounds hands off a process that does not work.
Write each task as a task, not a category
"Close AP" is not a task. It is a heading covering six or seven tasks that have different owners, different inputs, and different failure modes.
A task on a good close checklist has one owner, one clear completion state, and one place it happens. If two people can reasonably disagree about whether an item is done, it is too big. Break it up until "done" is unambiguous.
This feels like it makes the checklist worse, because a tidy list of twelve items becomes an untidy list of sixty. It is the right trade. The twelve item list was never the real process. It was a summary of the real process, and summaries cannot be delegated.
Attach the procedure to the task
This is the part that matters, and it is the part most teams skip.
Every task should link directly to the written procedure for that specific task. Not to a shared drive folder. Not to a 40 page close manual with a table of contents. To the procedure for the task the person is looking at right now.
The reason this works is that documentation fails for a boring reason: it is stored somewhere other than where the work happens. People do not avoid procedures because they dislike them. They avoid them because finding the right one costs more than guessing, and guessing usually works. When the procedure is one click from the task, that calculation flips.
It also keeps the documentation current, which is the other half of the problem. Procedures rot because nobody encounters them. When the procedure is opened every month by whoever performs the task, an out of date step gets noticed and fixed immediately, because it is blocking someone right now.
Make the procedure specific enough to follow cold
Write each SOP 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 knows to ignore.
A usable procedure states:
- Which system, which report, and which parameters.
- What the output should look like when it is right.
- What the common exceptions are 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 worth emphasizing. If the task supports a control, the evidence needs to be captured as the task is performed, not reconstructed at audit time. Building retention into the procedure is the difference between a control you can demonstrate and one you can only describe.
Sequence it by dependency, not by department
Close checklists tend to be organized by team, because that is how the work is assigned. Dependencies do not respect that structure. A task in one area frequently blocks a task in another, and when the checklist is grouped by team, those cross dependencies are invisible until something is late.
Order the checklist by what blocks what. Mark the items that gate other items. If a task cannot start before another finishes, say so on the task itself rather than trusting people to know.
The practical payoff is that when the close slips, you can see immediately whether you have a problem or a delay. A late task with nothing downstream is a delay. A late task that three other items are waiting on is a problem, and it deserves attention now rather than on day five.
Make status visible in one place
If answering "where are we in the close?" requires asking three people, the checklist is a document rather than a system.
Status needs to be visible without interrupting anyone: what is done, what is in progress, what is blocked, and what has not started. This is less about tooling than it sounds. A shared spreadsheet with a status column works. What does not work is status that lives in individual inboxes and gets assembled into an update once a day by a manager.
The benefit is not primarily reporting. It is that the team stops spending the close asking each other for status, and the manager stops being a router for information that everyone could see directly.
Treat exceptions as information
Every close produces items that do not go according to plan. Most teams handle them and move on. The handling is necessary and the moving on is the mistake, because the exception was telling you something.
Keep a short record of what went wrong each period: what the item was, what caused it, and what was done. After three or four closes, the pattern is usually obvious. The same account, the same interface, the same two systems that disagree. At that point you are looking at a process fix rather than a recurring inconvenience, and you have the evidence to justify the time it takes.
This is also how a close gets faster. Not by asking people to work more quickly, but by removing the two or three recurring problems that consume a disproportionate share of the days.
What this buys you
The obvious benefit is coverage. When someone is out, the close does not stall, because the procedure is attached to the task rather than living in that person's head.
The less obvious benefits are bigger. Onboarding gets dramatically faster, because a new team member can be given real close tasks in their first month with the procedure in front of them. Audit preparation becomes lighter, because the documentation an auditor asks for already exists and is demonstrably in use. And the close stops depending on heroics, which is the underlying goal. A process that requires the right person to be available is not a process. It is a habit that has been working out so far.
None of this requires sophisticated tooling. It requires the discipline to write each task at the right size, attach the procedure to it, and keep both in the place where the work actually happens.