Accounts Payable Policies and Procedures: Writing an AP Manual People Actually Follow

The Document Nobody Opens

Almost every finance function has an accounts payable policy. Comparatively few have one that changes what anyone does.

The typical document runs to thirty pages, opens with a statement of purpose and scope, describes a linear process in which invoices arrive, are matched, approved, coded and paid, and concludes with a record retention schedule. It is accurate in the sense that nothing in it is false. It is also useless, because it answers questions nobody was asking while remaining silent on the ones that come up constantly.

The test of an AP policy is narrow. Does it settle a decision that would otherwise be made inconsistently? Everything that passes that test belongs in the document. Everything that fails it is padding, and padding is what makes people stop reading.

A useful diagnostic costs nothing. For two weeks, log every question the AP team asks someone else. Not the complex judgement calls, the routine ones. Does this need a PO? Who approves this? Which cost centre? Can I pay this without the supporting document? Is this vendor approved? Should this be capitalised?

Each of those questions is an undocumented decision being re-made by whoever happens to be asked. The list you produce is the actual table of contents for your policy, and it will look very little like a generic template.

Policy and Procedure Are Different Documents

The most common structural mistake is merging two things with completely different lifespans.

A policy states a rule and the reason for it: invoices above a certain value require two approvers; vendor bank details may only be changed following independent verification by callback. These rules are stable. They survive system migrations and reorganisations, and they should be short enough to read in one sitting.

A procedure states how to execute the rule in your systems: which screen, which field, which button, which report. Procedures go out of date constantly, because software changes, and a policy document containing screenshots is obsolete within a release cycle.

When the two are merged, the whole document inherits the shorter lifespan. It falls out of date, people notice it is wrong about the screens, and they reasonably conclude it is wrong about everything else. Splitting them means the policy can remain authoritative for years while procedures are updated as often as needed.

The fourth row is the one most organisations lack. A policy with no record of when it was overridden provides no evidence about whether it works.

The Twelve Decisions an AP Manual Must Settle

A policy earns its length by resolving recurring decisions. These twelve account for the majority of the questions AP teams escalate.

1. When is a purchase order required? Define the value and category thresholds, and state explicitly what happens when goods arrive without one. Silence here is why non-PO invoice volume grows unchecked.

2. What matching tolerances apply? Acceptable price and quantity variance, in percentage and absolute terms, and who approves beyond it.

3. What are the approval thresholds? Value bands and the authority required at each, including delegation during absence.

4. Who owns GL coding? Whether AP codes and the approver confirms, or the requester codes and AP validates. Ambiguity here produces the coding inconsistency that surfaces later as unreliable management reporting.

5. How are vendors onboarded and bank details verified? Required documentation, tax status, and mandatory independent callback verification for bank changes. This single rule prevents the most costly category of payment fraud.

6. Which duties are incompatible? The combinations one person may never hold, particularly vendor creation and payment release, as set out in segregation of duties for AP.

7. When is spend capitalised rather than expensed? The threshold and the criteria distinguishing improvement from repair, which also governs how capital expenditure invoices are coded and approved.

8. What is the prepaid treatment threshold? The value and duration at which an invoice becomes a prepaid expense rather than a period cost.

9. When are payments made? Payment run frequency, timing relative to due date, and the criteria for an off-cycle or emergency payment, which is the route most commonly abused.

10. How are exceptions authorised? Who may deviate, what evidence is required, how it is recorded.

11. What documentation must be retained, and for how long? Including the format and location, which matters increasingly where e-invoicing mandates apply.

12. Who owns each rule? A named role against every policy statement.

Setting Thresholds That Survive Contact With Reality

Thresholds are where most policies quietly fail, and the cause is almost always that the numbers were borrowed rather than derived.

A threshold copied from a larger organisation routes almost nothing to senior approvers, so the control is theatre. A threshold copied from a smaller one routes almost everything, so approvers stop reading and approve on reflex. Both produce the same outcome, which is approval without scrutiny, and the second is more dangerous because it looks rigorous.

The correct method is empirical. Pull twelve months of invoice data and look at the actual distribution of values. Then set bands so that each approval level sees a volume it can genuinely consider. A director who sees six invoices a month will read them. A director who sees six hundred will not.

The same logic applies to matching tolerances. Tolerances set too tight generate exception volume that consumes AP capacity without improving control, since almost every exception resolves as acceptable. Tolerances set too loose permit systematic small overbilling that never triggers review. Both are visible in your own data: the current exception rate and the proportion of exceptions that resolve with no adjustment tell you immediately which direction to move. Tracking that alongside your broader AP performance metrics turns threshold setting into an evidence-based decision rather than a negotiation.

Why This Matters More Once You Automate

There is a persistent assumption that automation makes policy documentation less important, on the basis that the system now enforces the rules. The opposite is true.

A manual process with weak documentation is inconsistent, which is bad but self-limiting: each person applies their own judgement, errors vary, and someone usually notices. An automated process with weak documentation applies one embedded decision uniformly across every transaction, thousands of times, without anyone re-examining whether it is correct.

When a tolerance is configured at a certain percentage, that number came from somewhere. If it is not written down with its rationale and owner, then in two years nobody can explain it, nobody is willing to change it, and it becomes permanent by default. Automation converts undocumented decisions into permanent ones.

This is why documented policy is the precondition for automation rather than an afterthought. Encoding a rule requires stating it precisely, which surfaces the ambiguity that a prose manual can hide. Teams that write the policy first usually discover their process was less defined than they believed. Guidance on control documentation and governance expectations is available from the Institute of Internal Auditors, the Institute of Management Accountants, the IFAC and Deloitte, with practical framing from Corporate Finance Institute.

How Peakflo Helps

Peakflo turns AP policy from a document into enforced configuration. Approval thresholds, matching tolerances, PO requirement rules, duplicate blocking and role restrictions are applied automatically to every invoice, so the rule is followed by default rather than depending on whoever is processing the work that day, and delegation during absence is handled by the routing logic instead of by informal handover.

Just as importantly, every override is captured. Because the platform records which rules were applied, which were bypassed, by whom and with what justification, the exception log that most policy frameworks lack exists as a by-product of normal processing. That turns the annual policy review into an evidence-based exercise, since a rule overridden constantly is either wrong or unenforceable and a rule never triggered may be set at the wrong threshold. With approval workflow automation, vendor onboarding controls and invoice processing on one platform, the written policy and the operating reality stay aligned. To see policy rules enforced against your own invoice flow, request a demo.

Our Verdict: Document Decisions, Not Processes

After analysing why AP manuals succeed or fail, here is our recommendation.

Rewrite your AP policy if

• The current document has not been reviewed since your last system change
• Team members routinely ask questions the policy theoretically answers
• Thresholds were inherited and nobody can explain their basis
• No named owner exists for individual rules
• You are about to automate, since automation will freeze whatever ambiguity exists today

A light-touch policy is sufficient if

• The team is small enough that decisions are genuinely consistent
• Invoice volume and vendor count are low and stable
• No statutory or audit requirement demands formal documentation

Warning signs that the policy has become fiction

• Procedures reference screens or systems that no longer exist
• Exceptions are frequent but unrecorded
• The same rule is applied differently across entities
• Nobody can produce the document without searching for it

Our Recommendation: Do not start from a template. Start from the two-week log of questions your AP team asks other people, because that list is empirical evidence of which decisions are genuinely unsettled in your organisation. Write those up first, assign each an owner, encode whatever can be encoded, and stop there. A six-page policy that resolves the twelve decisions people actually face outperforms a forty-page manual describing a process in general terms.

Conclusion

An accounts payable policy is not a description of how invoices are processed. Anyone can observe that. It is a record of decisions that have been settled, so they do not have to be re-argued by whoever happens to be in the room.

That framing changes what belongs in the document and what does not. Process narrative can be dropped, because it is either obvious or better expressed as a procedure. Thresholds, authority, incompatible duties, exception routes and ownership belong, because each one resolves something that would otherwise be inconsistent.

It also explains why policy work has become more valuable rather than less as AP has automated. Every rule encoded into a system is a decision that will now execute identically thousands of times without review. Whether that is a control or a liability depends entirely on whether someone wrote down what the rule is, why it was set that way, and who is accountable for revisiting it.

Start with the question log. It takes two weeks of noticing and tells you more about what your policy needs to say than any template will.

Frequently Asked Questions

What are accounts payable policies and procedures?

Accounts payable policies and procedures are the documented rules governing how supplier invoices are received, validated, approved, coded, paid and recorded. The policy states the rule and who owns it, while the procedure states the steps required to carry it out in your specific systems.

What should an accounts payable policy include?

At minimum it should cover invoice receipt channels, vendor onboarding and bank detail verification, purchase order requirements, matching tolerances, approval authority thresholds, GL coding responsibility, duplicate prevention, payment timing and methods, segregation of duties, exception handling, record retention and the review cycle for the policy itself.

What is the difference between an AP policy and an AP procedure?

A policy is the rule and the reason for it, such as requiring two approvers above a set value. A procedure is the operational instruction for executing that rule in your systems. Policies are relatively stable, while procedures change whenever systems or screens change, which is why they should be maintained as separate documents.

How do you set approval thresholds in an AP policy?

Set them against the actual distribution of your invoice values rather than copying figures from another organisation. Pull twelve months of invoice data, look at the value distribution, and choose bands so that senior approvers see a genuinely small number of genuinely significant items. Thresholds that route too much destroy attention, and thresholds that route too little destroy the control.

Why do AP policy documents get ignored?

Usually because they describe an ideal process rather than the real one, because they mix stable policy with system steps that go out of date quickly, because no owner is named for individual rules, or because following the policy is slower than working around it. A rule that is harder to follow than to bypass will be bypassed.

How often should AP policies be reviewed?

Review annually as a baseline, and additionally whenever a trigger event occurs: an ERP or AP system change, a new entity or acquisition, a significant change in invoice volume, a fraud incident or an audit finding. System changes are the most common cause of policy drift because procedures silently stop matching reality.

Who should own the accounts payable policy?

The financial controller typically owns the policy overall, with individual rules assigned to named roles such as the AP manager for processing rules and treasury for payment timing and methods. Ownership must sit with a role rather than a department, because unowned rules are the ones that quietly lapse.

What matching tolerances should an AP policy define?

The policy should define acceptable variance between purchase order, receipt and invoice on both price and quantity, expressed as a percentage, an absolute value or both, and state who may approve a variance beyond tolerance. Tolerances set too tight generate exception volume with no control benefit, while tolerances set too loose permit systematic overbilling.

How does an AP policy support segregation of duties?

The policy should state explicitly which combinations of activities one person may not perform, most importantly that whoever can create or amend a vendor record cannot also release payments to it. Documenting the incompatible combinations is what allows system roles to be configured correctly and audited afterwards.

Do you need an AP policy if the process is automated?

Yes, and arguably more so. Automation encodes decisions into rules that execute thousands of times without review, so the logic must be documented, owned and periodically re-examined. An automated process with no written policy is a set of embedded decisions nobody can explain to an auditor or safely change later.

What is an accounts payable SOP?

An AP standard operating procedure is the step-by-step operational instruction for a specific task, such as processing a non-PO invoice or running a payment batch. SOPs are the execution layer beneath the policy and should be written for someone performing the task for the first time, in the systems you actually use.

How do you make an AP policy enforceable?

Encode rules into system configuration wherever possible, so approval routing, tolerance limits, duplicate blocking and role restrictions apply automatically rather than depending on someone remembering. Then monitor the exceptions, because the rate at which a rule is overridden is the most reliable evidence of whether it is working or merely written down.