When I took over an accounts payable team, one of the first things I did was ask someone to show me how the invoice approval process works from A to Z. The answer was roughly: "Well, it depends on who's doing it."
So I asked whether it was written down anywhere. Silence. Eventually someone shared a Word file from 2020. Half of the steps were out of date, and the other half described a system we no longer used.
That was the moment I realised that the biggest risk in our department wasn't accounting errors. It was knowledge that lived only in people's heads.
Knowledge in someone's head is not a safeguard
In AP, we work with processes that look simple at first glance: an invoice comes in, someone checks it, someone approves it, someone pays it. In practice, every one of those steps has dozens of exceptions – a different supplier, a different currency, a different approval path, a different system, and country-specific rules on top. When that knowledge exists only "in Ania's head in accounting", it isn't a team competence. It's a single point of failure.
I saw this first-hand when a key person on the team went on extended sick leave. For two weeks, the number of "how did we do this again?" questions grew faster than the pile of invoices waiting for approval. Not because the rest of the team wasn't competent – simply because nobody had ever taken the time to write it down in a way people could actually use.
AP procedures that actually work, not ones that merely exist
In many companies, process documentation is treated as a formality – something you need to have in case of an audit, which then sits on a shared drive and nobody opens again. For documentation to really help someone, it has to meet a few conditions. I learned most of them by trial and error.
1. Write for someone doing it for the first time
An instruction has to be written from the perspective of someone doing the task for the first time, not someone who has been doing it for five years. What is obvious to me is not obvious at all to a new team member. Instead of writing "verify the supplier's data", it's better to say exactly where to click, what to look for and what to do if something doesn't match.
2. Cover the exceptions, not just the happy path
Reality in AP rarely looks like a textbook case. If the documentation only describes the situation where everything matches, it is useless in most real-life cases.
3. Shorter is better
This is something I had to be convinced of myself. For a long time I was a fan of detailed, multi-page procedures. In practice, nobody read them. The team is far more likely to reach for a short checklist or a simple diagram than for a document they have to scroll through for ten minutes.
Who should write AP process documentation
A common mistake is giving the job of writing instructions to one person – usually whoever happened to have the most time, not whoever knew the process best. Now I make sure that documentation is written by the person who actually performs the process every day. Then someone else on the team tests it by trying to complete the task using only the instruction. If the question "what now?" comes up during the test, something has been left out.
This approach has one more advantage. When people write procedures for their own tasks, they start noticing things they used to do on autopilot. Sometimes it turns out that a step isn't needed at all, or that two people do the same thing in two different ways.
Documentation is not a one-off project
The biggest trap is treating documentation as a project with an end date. Done, ticked off, forgotten. AP processes change along with systems, suppliers and regulations, so an instruction that isn't updated becomes more confusing than helpful within a year.
What worked for us is a simple habit: whenever a process changes, the last step is updating the documentation – not a nice extra "when there's time". We also introduced a quarterly review of our instructions. Not to rewrite everything from scratch, but to check whether they still match reality.
Archiving is part of the process, not an add-on
There's one more element that's easy to forget when talking about documentation in AP. It's not only about "how to do it" instructions, but also about keeping order in everything the process leaves behind. The invoice, the approval email, the note summarising an agreement with a supplier – all of it is as much a part of the process as the payment itself, yet it is often treated as an afterthought.
It happens more often than you'd think that approvals live in individual people's mailboxes. That looks fine until someone needs to go back to them. The problem appears when you have to reconstruct the history of a payment from six months ago, and the person who approved it has just moved to another department or left the company. Today we have clearly defined where and in what form every document supporting a posting is stored – the invoice, the approval, the correspondence with the supplier – so that anyone on the team, not just the person who posted it, can reconstruct it in a few minutes.
This translates directly into how an audit goes. Well-organised supporting documentation means that when an auditor asks "show me the justification for this posting", we answer in minutes, not after several days of searching mailboxes and drives. I've seen both situations, and the difference in how stressful an audit is for the whole team is huge.
SOX in accounts payable is not a box-ticking exercise
In companies subject to Sarbanes-Oxley requirements, documenting AP processes and controls is not a "nice to have". It is a requirement the team is accountable for – not once a year during the audit, but on an ongoing basis. Every control in our process – segregation of duties in payment approvals, approval limits, a system audit trail showing who did what and when – must not only be performed, but also be provable.
In practice, this means that the instruction describing the process and the evidence that the process really runs that way must match. More than once I've heard "well, obviously we do that" – but at audit time, "obviously" isn't enough. You need evidence. That's why whenever a process changes, I check not only whether it runs more smoothly, but also whether it still meets the controls required by SOX and whether that can be shown to an outsider in a simple way.
Key takeaways: how to document AP processes
- Treat knowledge held by one person as a risk – a single point of failure, not a competence.
- Write instructions for someone doing the task for the first time: where to click, what to check, what to do if something doesn't match.
- Describe the exceptions, not only the happy path.
- Prefer short checklists and simple diagrams over long procedures.
- Let the person who performs the process write the instruction, and have a colleague test it.
- Make updating documentation the last step of every process change, and review instructions quarterly.
- Define where every supporting document is stored: invoice, approval, supplier correspondence.
- In SOX-regulated companies, make sure the procedure and the evidence of how the process runs match.
It simply pays off
Good AP documentation isn't spectacular. Nobody gets an award for it, and it doesn't make it into the board presentation. But it is what makes onboarding a new team member go faster, holiday cover not turn into chaos, and an audit not become an archaeological dig.
If I had to give one piece of advice to teams just starting to put their documentation in order, it would be this: don't try to describe everything at once. Start with the process that causes the most questions or errors, and turn it into one good, tested instruction. The rest will come with time – but that first step shows the team that it really makes sense.
