Nobody reads an invoice procedure to find out how to process a normal invoice. They read it when something unusual has happened and the person who normally deals with it is not there. That single fact should shape the document: a paragraph on the clean path, and real detail on each exception, which is the inverse of how most of them are written.
The clean path in a paragraph
Receive, validate, match within tolerance, route by cost centre and value, approve, code, schedule, pay, remit. State the tolerance and the routing rule and stop. Anybody doing the job daily knows this, and detail here adds length without adding usefulness, while length is what stops the document being maintained.
Each exception in detail
No purchase order, price variance, quantity variance, missing receipt, unrecognised supplier, suspected duplicate, dispute, credit note. For each: how to recognise it, who owns it, what to record, and how long it should take. This is what somebody covering during absence needs, and it is what a new joiner learns from.
The controls, written plainly
Who may create or amend a supplier record, how bank detail changes are verified and by whom, who may release a payment run, and what may be overridden and by whom. Writing these down is also how organisations discover that one or two of them have never actually been decided by anybody.
Questions people ask about invoice procedures
How long should it be?
Two or three pages. Longer documents are not maintained, and an out-of-date procedure discredits the parts that are still right.
Should screenshots be included?
Reference the system rather than reproducing screens, which date the moment anything changes.
Who reviews it?
Whoever owns the control, with the people doing the work, at least annually and whenever something changes.