Most process documentation fails for a boring reason: it describes the day the invoice is correct, the vendor is reasonable, and the payment clears on the first try. That's the happy path, and for a lot of teams it's the only path on the page. The moment something goes sideways, the document stops being useful and the decision bounces straight back to the person who wrote it. You.
You didn't write a bad procedure. You wrote an incomplete one, in exactly the place where completeness matters most.
Key takeaways
- Process documentation that only covers the normal case stops working the first time something goes wrong, and every exception quietly turns back into a question for you.
- Every exception needs four things written down: what the situation is, who may decide, what limit they can decide within, and when to escalate.
- A decision block turns a fragile procedure into one your team can run without you — for example, an invoice discrepancy under $100 is handled by the AP clerk, and anything over that goes to the finance lead.
- You can build an exception-ready SOP in about 15 minutes with a free template that includes the decision block most templates leave out.
Why happy-path process documentation feels like enough
When you sit down to write a procedure, you write it from memory of the last time it worked. The invoice came in, it matched the purchase order, you approved it, the payment went out, everyone was happy. Six clean steps. It reads well. Nothing on the page is factually wrong.
That's what makes it so convincing. The document passes the eye test because it describes a real thing that really happens. What it doesn't describe is everything else — the wrong amount, the duplicate invoice, the vendor who swears the terms were net 15, the transfer that gets returned three days later with no explanation.
Those are not edge cases. Within a few months of running any payables process, they are Tuesday.
The vendor payment SOP, and the three places it breaks
Picture the standard version. The steps say: invoice arrives, match it to the purchase order, approve it, pay it.
Now run three real scenarios through it.
The invoice is wrong. Wrong PO number, a line item nobody ordered, or a remit-to address that doesn't match what's on file. The written steps assume a correct invoice, so there is no instruction for a wrong one. Your AP clerk doesn't know whether they're allowed to ask the vendor to reissue it, or whether that counts as a change you need to approve. So they email you and wait.
The vendor disputes the amount. This is a negotiation, not a step, and there's no step for a negotiation. Nobody in the document has the authority to settle it. The payment sits. The vendor chases. Someone eventually forwards you a thread with nine messages in it and asks what you want to do.
The payment fails. It gets returned, the bank details don't match, or the vendor emails to say the account has changed. Nobody knows if they're allowed to retry, update the details, or pick up the phone. A changed bank account deserves a second look before anyone pays it, and without a written rule, the safest thing your team can do is nothing — which means another message to you.
Three exceptions, three interruptions. The cost isn't dramatic, it's cumulative: payments sitting past their terms, vendors chasing, and you acting as the approval layer for work you already delegated on paper.
The fix: one decision block for every exception
A step tells someone what to do when everything is normal. A decision block tells them what to do when it isn't. The format is four fields:
decision | who may decide | limit | escalate when
Here's how that looks for the vendor payment process:
| Situation | What to do | Who may decide | Escalate when |
|---|---|---|---|
| Invoice matches the PO and the amount is within tolerance | Approve and schedule payment | AP clerk | Nothing to escalate |
| Invoice is wrong (bad PO, missing line item, wrong remit-to) | Request a corrected invoice and hold payment | AP clerk | Vendor won't or can't reissue it |
| Amount discrepancy under $100 | AP clerk may request a corrected invoice and proceed | AP clerk | The discrepancy goes over $100 |
| Amount discrepancy over $100 | Hold payment, log the dispute, route it to the finance lead | Finance lead | Finance lead and vendor can't agree on the amount |
| Payment fails or is returned | Check the details with the vendor before retrying | AP clerk | Second failure, or any change to bank details |
That table is the whole difference. The steps haven't changed. What changed is that every place the process used to stop and wait for you now has a named person, a limit, and a trigger for escalation.
Writing decisions people will actually follow
A few rules make these blocks work in practice:
- Name a person, not a department. "Finance" can't decide anything. A finance lead can.
- Give the limit a real threshold. "Reasonable discrepancies" is not a limit. Under $100 is a limit, and so is "arrived within the last 30 days."
- Write the escalation as a trigger, not a judgment call. "Escalate when it goes over $100" is checkable. "Escalate when it feels significant" is not.
- Write the exception as a situation, not a feeling. Start with what the person is looking at — wrong invoice, disputed amount, failed payment — not with how annoying it is.
- Let the person doing the work review it. They already know where the gaps are. Hand them the draft and ask them to find the exception you left out.
This is the part of process documentation that actually buys you your time back. The document was never the point. The point is that the decisions currently queued in your inbox get a home somewhere else.
If you want to build one without starting from a blank page, the free SOP template walks you through it and includes the decision block most templates leave out. Click "Fill with an example" and you'll see the decision | who may decide | limit | escalate when format filled in for you. Your first SOP takes about 15 minutes.
Quick checklist
- Write out the process as it runs when everything goes right.
- For each step, ask "what could go wrong here?" and turn each answer into a separate exception.
- Add a decision block to each exception in the format decision | who may decide | limit | escalate when.
- Name a person in the "who may decide" field, never a team or a department.
- Give every limit a real threshold and write the escalation as a checkable trigger.
- Hand the draft to the person who does the work daily and ask them to find the gap you missed.
You don't need a perfect document. You need one that holds up on the day the invoice is wrong — because that day is coming, and the SOP should answer the question before it reaches you.