Company procedures are the instructions your staff follow when a familiar job comes round again. They might say how an invoice is approved, when to escalate a complaint or who checks a new supplier. You don’t need a thick procedure manual to have them, but you do need to know which instructions are current.
Some teams call their detailed instructions standard operating procedures, or SOPs. The written steps describe intended work; dated forms, system events and decisions can show what actually happened. That difference matters when you’re interpreting operational evidence. ADP (Accord Data Partners) is independent of buyers and never receives company datasets, so this guide focuses on records you keep yourself.
What is a company procedure?
A procedure explains how to carry out a repeatable piece of work. It identifies what starts the task, who takes each action and how the task ends. Company procedures might be a page of instructions, a form with prompts or steps built into a system. The useful test is whether another trained person could follow them.
A business process is the wider route from an initial need to an outcome. Paying a supplier, for example, may involve ordering, receiving goods, checking an invoice and making payment. A procedure can cover one part of that route, such as checking the invoice. Keeping the two levels separate makes gaps and handovers easier to spot.
Not every action needs a separate document. A short routine with no judgement calls may only need a checklist, while a task involving money or customer decisions needs clearer boundaries. Ask where staff have to choose, wait for someone else or record an outcome. Those points tell you how much detail the instructions need.
How is a procedure different from a policy?
A company policy sets a rule or commitment, such as requiring someone else to approve a purchase before it’s placed. Company procedures turn that rule into actions: where to send the request, what the reviewer checks and how a refusal is recorded. When the rule changes, the instructions need checking too, or staff may follow conflicting documents.
The policy answers what the business expects; the procedure answers what a person does next. Take refunds. A policy might set the circumstances in which a refund can be considered. The accompanying instructions should tell staff where to find the order, who can decide and what to tell the customer if more information is needed.
Neither document, on its own, shows that staff followed it. An instruction saying ‘manager signs off’ tells you what should happen, not whether a particular request received sign-off. To answer that question, look for a linked request and decision. This distinction helps when you’re reviewing operations, training someone new or explaining past work.
What should a useful procedure contain?
Start with the trigger, the intended outcome and the role responsible for each action. Name a process owner who can answer questions and keep the instructions accurate, rather than leaving edits to whoever notices a problem. Say where staff find the necessary information and where they record the result. Otherwise, even sensible steps can be difficult to use.
Write at the level a capable new colleague needs. If the task involves entering fields in a particular system, a short work instruction can explain those clicks without making the main procedure unreadable. Link the detailed steps to the wider task, so a system change can be updated without rewriting every explanation of why the work happens.
Make each decision point visible. ‘Check the request’ is vague; ‘confirm that the quoted amount matches the request, then send any mismatch back to the requester’ gives staff an action. Company procedures should also say what counts as finished and what to do if the usual route cannot be followed. That prevents a checklist from hiding unresolved work.
What does an approval example look like?
An approval step needs a clear trigger and a named decision maker. For a purchase, explain what the requester submits, what information the reviewer needs and whether approval must come before an order is placed. ‘Get sign-off’ leaves too much open: staff may not know whose decision counts or where to find it later.
In company procedures, keep requesting, authorising and carrying out the work distinct where those roles matter. State what happens when the usual approver is away and how a rejected request returns for correction. A record that says only ‘approved’ may be hard to interpret unless it also identifies the request, the reviewer and the decision date.
Hypothetical worked example: A facilities team requests a replacement printer under an internal rule requiring a manager’s approval before ordering. The requester attaches a quote, the manager checks it against the available budget and records a decision, then a purchasing colleague places the order. The approval record should remain distinct from the later record confirming delivery.
How do staff handle exceptions?
An exception is a case the normal steps don’t settle, not permission to skip them quietly. Tell staff when to pause, who can decide an alternative and what information that person needs. An exception log can capture the reason, the authorised decision and the follow-up without turning a one-off problem into an unwritten new rule.
Some exceptions are urgent, while others can wait for clarification. Company procedures can distinguish the two by setting a safe stopping point: for instance, hold an incomplete supplier payment rather than guessing the missing bank detail. If work must continue, name who may authorise that route and what must be checked afterwards.
A customer complaint shows why the distinction matters. Staff might follow the usual acknowledgement steps, then find that the issue falls outside the standard remedy. The instructions should say who reviews it and how the customer receives an update. Recording the reason for the different handling helps the team decide whether the usual steps need changing.
How do procedures change over time?
Company procedures change when a system, role or rule changes, and sometimes because staff find a step that doesn’t work. Use version control so people can identify the current instructions and see what changed. Retain older versions when you need to understand historical work; replacing a file without a trace can make an earlier decision look inconsistent.
An effective date tells staff when to start using a revision. It matters if the document was approved on Monday but a new system went live on Thursday. Keep the approval date and start date distinct, and make the change easy to find where staff work. Otherwise, two teams may use different instructions without realising it.
A review cycle gives someone a prompt to check that the instructions still match the job, but a scheduled review shouldn’t delay an obvious correction. Assign responsibility for gathering staff feedback, checking related forms and communicating the revised steps. A small change to an approval route may also require changes to templates or training materials.
What records show that work happened?
A procedure describes the intended route; a completed task leaves evidence of the route taken. Company procedures for invoice checking, for example, might be accompanied by an invoice, a receipt confirmation and a recorded payment decision. Compare the records with the steps, but don’t assume a filled-in field proves every check was done well.
An audit trail can connect a request to a reviewer, time and result, but a timestamp alone won’t tell you whether the decision was sound. The Government Data Quality Framework describes data quality in terms of fitness for its intended purpose. For your own records, check what’s missing and be clear about what the available entries cannot establish.
A training record may show that someone received the instructions in force at a particular time. It doesn’t prove they followed every step on a later job. To interpret company procedures alongside work records, match the relevant document version to the date of the task, then look at the actual decisions and outputs.
When do procedures become part of a data collection?
A data collection needs a defined scope, such as instructions and associated approval records for one workflow and period. If you’re considering whether to sell your company data, establish that scope first. ADP provides a paid introduction course and a portal, not a place to hand over datasets. It cannot approve eligibility or promise earnings.
An onboarding checklist alongside completed onboarding records may explain why certain information was collected, but the collection could also contain personal details or somebody else’s writing. GOV.UK’s copyright guidance explains that using protected work requires the relevant permission or an applicable exception. Check copyright, confidentiality and contract authority separately before discussing a licence.
Keep business consent to an introduction separate from a lawful basis for processing personal data. Pseudonymised records can still be personal data, and a licence doesn’t settle privacy obligations. The business and buyer agree any licence themselves. To consider whether your company procedures are relevant material, start with ADP’s information for businesses, without sending it your records.
Frequently asked questions
Is a procedure the same as an SOP?
An SOP is usually a detailed procedure for a repeatable task. Teams use the labels differently, so check what the document actually tells staff to do rather than relying on its name.
Does a completed checklist prove staff followed a procedure?
It can show that steps were recorded, but it may not show how carefully they were done. Read it alongside dates, decisions and other records from the same task.
Can a written procedure alone show how a business operated?
No. It shows the intended approach. Dated work records and the version in force at the time help you assess what happened in practice.
