SOP Template: A Standard Operating Procedure Template You Can Copy

A standard operating procedure (SOP) is a written, step-by-step description of how one repeated task is done in your business, so anyone trained to do it gets the same result. A good SOP template gives every procedure the same sections: purpose, scope, roles, systems used, the steps (with who does each one and where it is recorded), checks and approvals, exceptions, related documents, and an owner with a review date. The full template is below. Copy it into Word, Google Docs, SharePoint or your wiki, and fill in one copy per task.

The SOP template (copy and paste)

Copy everything from "SOP title" to "Change history" into a new document. The text in brackets tells you what to write in each section. Delete the brackets as you go.

SOP title: [Verb + task, e.g. "Entering a supplier invoice"]

• SOP number: [e.g. FIN-004]
• Version: [e.g. 1.0]
• Owner: [The role responsible for keeping this SOP current, not a person's name]
• Approved by: [Manager who signed it off]
• Last reviewed: [Date]
• Next review due: [Date, usually within 12 months]

1. Purpose

[One or two sentences: what this task achieves and why it matters to the business.]

2. Scope

• Covers: [What this SOP includes, e.g. all supplier invoices for stock and freight]
• Does not cover: [What is handled elsewhere, e.g. staff expense claims, see FIN-007]
• Starts when: [The trigger, e.g. an invoice arrives in the accounts inbox]
• Ends when: [The finish point, e.g. the bill is approved and waiting for payment]

3. Roles

• [Role]: [What they do in this procedure]
• [Role]: [What they do]
• [Role]: [Who they go to when something is wrong]

4. Systems and information used

• [System, e.g. Xero, your stock system, shared inbox, spreadsheet name and location]
• [Access or permissions needed]
• [Documents or information needed before starting]

5. Procedure

For each step, write who does it, what they do, and where it is recorded.

1. [Role] [does what, starting with a verb]. Recorded in: [system or file]
2. [Role] [does what]. Recorded in: [system or file]
3. [Role] [does what]. Recorded in: [system or file]
4. [Add steps. One action per step.]

6. Checks and approvals

• [What gets checked, by whom, and how they know it is right]
• [Who approves, and the limit that needs a higher approval]
• [What the finished result looks like]

7. Exceptions

• If [something is missing or wrong], then [what to do and who to tell].
• If [the usual person is away], then [who does it instead].
• If [the system is down], then [the fallback].

8. Related documents

• [Policy this SOP follows]
• [Other SOPs that come before or after this one]
• [Forms, checklists or process maps]

9. Change history

• [Date] - [Version] - [What changed] - [Who changed it]

What each section is for

Most of the template is plain, but a few sections do more work than they appear to.

• Owner and review date. The single biggest reason SOPs go stale is that nobody owns them. Put a role in the owner field, so the SOP survives staff changes, and a real date in the review field.
• Scope. The start and end points stop SOPs from overlapping or leaving gaps. If two SOPs both claim the same step, or neither does, you'll find out here.
• Systems used. Listing every system, spreadsheet and inbox the task touches is useful on its own. It often shows how many places one piece of information passes through.
• Recorded in. Writing where each step is recorded makes the SOP a record of your controls, not just instructions. When someone asks "how do we know this was done?", the answer is in the SOP.
• Exceptions. Real work is mostly exceptions. An SOP that only covers the happy path gets ignored the first time something unusual turns up.

Example: entering a supplier invoice (wholesaler using Xero)

This is a made-up example to show the template filled in. It describes a hypothetical wholesaler that raises purchase orders in its stock system and keeps its accounts in Xero. Your steps will be different.

SOP title: Entering a supplier invoice

SOP number: FIN-004. Owner: Accounts Payable Officer. Approved by: Finance Manager.

1. Purpose

Get every supplier invoice into Xero once, matched to what was ordered and received, so we pay the right amount on time.

2. Scope

• Covers: invoices for stock and inbound freight.
• Does not cover: staff expenses or utilities (see FIN-007).
• Starts when: an invoice arrives in the accounts inbox.
• Ends when: the bill is approved in Xero and waiting for the payment run.

3. Roles

• Accounts Payable Officer: enters and matches invoices.
• Warehouse Supervisor: confirms what was received.
• Finance Manager: approves bills over the approval limit and anything that doesn't match.

4. Systems and information used

• Accounts inbox, stock system (purchase orders and goods received), Xero (bills).
• Edit access to bills in Xero; read access to purchase orders in the stock system.

5. Procedure

1. Accounts Payable Officer opens each new invoice in the accounts inbox and checks it is addressed to us and has an ABN. Recorded in: accounts inbox (moved to "In progress").
2. Accounts Payable Officer finds the purchase order number on the invoice and opens that order in the stock system. Recorded in: stock system.
3. Accounts Payable Officer checks the goods received against the order. If nothing has been received yet, the invoice waits in "Awaiting receipt". Recorded in: stock system.
4. Accounts Payable Officer compares invoice quantities and prices with the order and the goods received. Recorded in: note on the purchase order.
5. If they match, Accounts Payable Officer enters the bill in Xero with the supplier, invoice number, due date, account codes and the PDF attached. Recorded in: Xero (bill in draft).
6. Accounts Payable Officer submits the bill for approval. Recorded in: Xero (awaiting approval).

6. Checks and approvals

• Finance Manager approves bills over the approval limit, and every bill that doesn't match the order.
• Finished result: the bill is approved in Xero, the PDF is attached, and the order is marked as billed in the stock system.

7. Exceptions

• If the price or quantity doesn't match, email the buyer who raised the order and park the invoice in "Query". Don't enter it until the difference is agreed.
• If there is no purchase order number, ask the supplier for it before going any further.
• If the Accounts Payable Officer is away, the Finance Manager's assistant follows this SOP.

8. Related documents

• Purchasing policy (approval limits), SOP FIN-005 Supplier payment run, SOP WH-002 Receiving goods.

Notice steps 2 to 5. The same order details are read in one system and typed into another. That's worth knowing, and it comes up again below.

Tips for writing SOPs people actually use

• Write from watching, not memory. Sit with the person who does the task best and write down what they really do, workarounds included. For a fuller walkthrough, see how to write a standard operating procedure.
• One task per SOP. If an SOP needs sub-headings inside the procedure, it's probably two or three SOPs.
• Start each step with a verb. "Open", "Check", "Enter", "Send". It keeps steps short and clear.
• Use the names your team uses. If everyone calls it "the stock sheet", say "the stock sheet" and where it lives.
• Test it on someone new. Have someone who doesn't normally do the task follow it. Every place they stop to ask a question is a gap to fix.
• Put it where the work starts. Link the SOP from the inbox, checklist or system screen where the task begins. A folder of SOPs nobody browses doesn't help anyone.
• Keep the same template for every SOP. People learn where to look, and gaps stand out.

Where SOPs fall short

An SOP writes down how work is done today. That is useful, but it can lock in problems as well as good habits.

When the process itself is broken. If writing the SOP turns into an argument about how the task should be done, or the steps loop back on themselves, or approvals sit in someone's inbox for days, the problem is the process, not the paperwork. Map it first and fix it, then write the SOP for the fixed version. Our business process mapping guide shows how, and we offer business process mapping when the process crosses several teams or systems.

When the steps are retyping between systems. In the example above, someone reads order details in one system and types them into Xero. An SOP makes that retyping consistent, but it's still retyping, and it still goes wrong on a busy day. When an SOP is mostly "copy this from here to there", the better fix is to connect the systems so the information moves by itself, and then write a much shorter SOP for the checks a person still needs to make.

When it depends on one person. If only one person can follow the SOP because only they understand the spreadsheet behind it, the SOP hasn't removed the risk. See when only one person knows how it works.

If you want an outside view across several processes at once, our $5,000 Process & Systems Audit maps your key processes and systems and gives you a written, prioritised plan, including which tasks to document and which to fix first.

Frequently asked questions

What should be included in an SOP template?

A title, purpose, scope (with start and end points), roles, the systems and information used, the numbered steps with who does each one and where it is recorded, checks and approvals, exceptions, related documents, and an owner with a review date and change history.

What is the difference between an SOP and a process map?

A process map shows how a whole piece of work flows between people and systems, such as quote to cash. An SOP gives the detailed steps for one task within that flow, such as entering a supplier invoice. Most businesses need the map first and SOPs for the tasks that need detail.

Is there a standard SOP format in Australia?

There's no single required format for business SOPs. Regulated industries and some quality systems have their own requirements, so check those if they apply to you. For everyday business tasks, use one consistent template across the business.

Should SOPs be in Word or in a system?

Word or Google Docs is fine to start. What matters more is that the current version is easy to find from where the work happens, and that old versions don't keep circulating. A shared wiki or intranet page with a clear owner usually works better than files emailed around.

How often should an SOP be reviewed?

At least once a year, and whenever the system, supplier, rule or team behind the task changes. Put the next review date on the SOP so it's visible.

More examples: see our SOP examples from five industries, and our work instruction template for the detailed steps one person follows inside an SOP.

If writing your SOPs keeps turning up the same problems, like work waiting on one person or details typed into two systems, book a free initial chat. We'll talk through which processes to document as they are and which are worth fixing first.