Free SOP Templates for Recurring Business Processes

# Customer Onboarding SOP — [Company name]

Template status: [Draft / In review / Approved] · Applies from: [date]

## Purpose

Take a newly signed customer from countersigned contract to a working, adopted
deployment, so that every commitment made during the sales process is delivered
exactly once, on a date the customer agreed to, and nothing is promised twice by
two different people.

## Scope

New customers on the [standard] and [enterprise] plans, from countersignature to
the end of the [30]-day adoption review.

Out of scope: renewals and plan upgrades for existing customers ([Renewal SOP]),
self-serve signups that never speak to a person ([Self-serve activation SOP]),
and trials that did not convert.

## Owner

Accountable: [Customer Success Manager].
Supporting: [Solutions Engineer] for technical setup, [Billing Analyst] for the
first invoice, [Sales Owner] for the commitment handover.

## Trigger

Opportunity moves to **Closed Won** in [CRM] with a countersigned order form
attached to the record.

Secondary trigger: [Sales Owner] files a handover note without a countersigned
document — handled as exception E1, not as a normal start.

## Inputs

| Input | System of record | Required |
| --- | --- | --- |
| Countersigned order form | [Contract store] | Yes |
| Handover note listing every non-standard commitment | [CRM opportunity] | Yes |
| Billing contact, PO number, tax ID | [Billing system] | Yes |
| Named customer admin and their access needs | [CRM contact record] | Yes |
| Data to migrate, with source format and row count | Customer-supplied | If D3 = yes |
| Security review outcome | [Vendor risk register] | If D2 = yes |

## Prerequisites

- A handover note exists and names every non-standard commitment: custom SLA,
  bespoke report, agreed integration date, agreed discount mechanics. No
  handover note, no onboarding start.
- The [Customer Success Manager] has provisioning rights in [workspace tool].
- An onboarding plan template exists for the track chosen in D1.
- The customer has named a sponsor with authority to approve go-live.

## Steps

1. **Read the contract before the kickoff call, not after.** Extract term,
   seat count, agreed start date, notice period and any bespoke clause into the
   onboarding record. Anything in the handover note that is not in the contract
   is not a commitment — raise it with [Sales Owner] the same day.
2. **Choose the onboarding track.** → Decision **D1**.
3. **Check whether a security or procurement review is still open.** →
   Decision **D2**. If open, the technical setup in step 6 may start but no
   production data may be loaded until it closes.
4. **Create the customer record set.** Account in [CRM], billing account in
   [Billing system], onboarding plan from the D1 template, shared channel in
   [comms tool]. Every downstream step writes to these, not to a personal doc.
5. **Send the kickoff invitation within [2] business days of countersignature.**
   Include the plan, the named owners on both sides, and the dates you intend to
   hit. Ask the customer to confirm the sponsor named in the prerequisites.
6. **Provision the workspace and the named admin account.** Apply the seat count
   from the contract, not the seat count discussed on the call.
7. **Decide whether historical data has to move.** → Decision **D3**. If yes,
   run the migration checklist: sample file, field mapping signed off by the
   customer admin, dry run, row-count reconciliation, then the full load.
8. **Run the configuration session.** Work through the customer's actual first
   use case rather than a demo dataset. Record every configuration choice in the
   onboarding record so it can be explained six months later.
9. **Confirm go-live.** → Approval **A1**. Only the customer sponsor can confirm
   the deployment is live; the [Customer Success Manager] records the
   confirmation and the date.
10. **Hand the first invoice to [Billing Analyst]** with the contract start date
    and PO number. Billing never derives the start date from the go-live date
    unless the contract says so.
11. **Hold the [30]-day adoption review.** Compare actual usage against the
    success criteria agreed at kickoff, log open risks, and close the onboarding
    record or escalate to [Head of Customer Success].

## Decisions

| ID | Decision | Criteria | Default |
| --- | --- | --- | --- |
| D1 | Onboarding track | Contract value ≥ [amount] **or** seat count ≥ [n] **or** any bespoke clause → guided track. Otherwise → standard track. | Standard |
| D2 | Security review required | Customer requested a questionnaire, is in [regulated sector list], or will load [special category] data | No |
| D3 | Data migration required | Customer holds ≥ [n] historical records they expect to see on day one | No |
| D4 | Go-live may proceed with an open item | Open item is cosmetic and has an owner and a date. Any open item touching access, billing or data blocks go-live. | Block |

## Exceptions

- **E1 — Handover note without a countersigned contract.** Do not provision.
  Return to [Sales Owner] and record the date. Provisioning ahead of signature
  is the single most common cause of unbilled usage.
- **E2 — The named customer admin leaves mid-onboarding.** Freeze steps 6–8,
  ask the sponsor to name a replacement in writing, and re-run the access grant.
  Do not transfer credentials between people.
- **E3 — Migration file fails reconciliation.** Row counts or checksums differ
  from the customer's stated figures. Stop the load, return the discrepancy
  report to the customer admin, and restart from the sample file.
- **E4 — Agreed go-live date is going to be missed.** Notify the sponsor before
  the date passes, not after, with a new date and the reason. Log the slip
  against the onboarding record for the quarterly review.
- **E5 — A commitment surfaces that is not in the contract.** Route to
  [Sales Owner] and [Head of Customer Success]. Nobody in delivery may accept a
  new commercial commitment.

## Approvals

| ID | What is approved | Who approves | Why it stays with a person |
| --- | --- | --- | --- |
| A1 | Go-live confirmation | Customer sponsor | It is the customer's statement that the deployment is fit for their use |
| A2 | Any commitment not in the signed contract | [Sales Owner] | Commercial liability |
| A3 | Waiving a step in the plan | [Head of Customer Success] | Keeps the exception visible rather than silent |

## Output

- A configured, accessible deployment matching the contracted seat count.
- A completed onboarding record: plan, configuration decisions, dates hit and
  missed, open risks.
- A first invoice raised against the correct start date and PO.
- A [30]-day adoption review with a documented outcome.

## SLA / KPI

- Kickoff invitation sent within [2] business days of countersignature.
- Go-live within [21] calendar days for the standard track, [45] for guided.
- Percentage of onboardings with zero commitments discovered after kickoff:
  target [95%].
- Percentage reaching the [30]-day review with the agreed success criteria met.

## Audit record

For each onboarding, retain for [contract term + 2 years]: countersigned order
form, handover note, kickoff plan, configuration decisions with dates and
authors, the go-live confirmation and who gave it, all A2 and A3 approvals, and
the adoption review outcome.

> Simulated example data
>
> Account [Northwind Freight] · order form countersigned [2026-03-02] · track
> [guided] (contract value above threshold) · D2 = yes, questionnaire closed
> [2026-03-09] · D3 = yes, [4,120] rows migrated, reconciliation matched on the
> second attempt after exception E3 · go-live approved by sponsor
> [Head of Operations] on [2026-03-24].

## Revision log

| Version | Date | Author | Change |
| --- | --- | --- | --- |
| v1.0 | 2026-07-24 | [Your name] | initial draft |

# Support Ticket Triage SOP — [Company name]

Template status: [Draft / In review / Approved] · Applies from: [date]

## Purpose

Get every inbound support contact to the right person at the right urgency on
the first pass, so that severity is assigned by a rule rather than by whoever
happens to read the ticket, and so that the small number of contacts that are
not support requests at all leave the support queue immediately.

## Scope

All inbound contacts arriving in [help desk] from email, in-product widget and
the community forum, from creation to first assignment and first response.

Out of scope: the work of resolving the ticket ([per-product resolution
playbooks]), incident command once an incident is declared ([Incident SOP]), and
sales enquiries.

## Owner

Accountable: [Support Lead].
Supporting: [Duty Engineer] for the escalation path, [Security Contact] for E2,
[Incident Commander] when an incident is declared.

## Trigger

A ticket is created in [help desk] with status `new`. Triage runs on every new
ticket, including ones re-opened by a customer reply after [14] days closed.

## Inputs

| Input | System of record | Required |
| --- | --- | --- |
| Ticket body, subject and attachments | [Help desk] | Yes |
| Requester email and verified account link | [Help desk] / [CRM] | Yes |
| Plan and contracted response time | [Billing system] | Yes |
| Open tickets from the same account in last [7] days | [Help desk] | Yes |
| Current service status | [Status page] / [monitoring] | Yes |

## Prerequisites

- A published severity matrix (the D2 table below) that support and engineering
  have both signed off.
- Contracted response times loaded into [help desk] per plan.
- A named [Duty Engineer] on rota for every hour the queue is covered.
- A documented security-report address that bypasses normal triage.

## Steps

1. **Check for a duplicate before anything else.** Same requester, same subject
   or same error signature within [24] hours → merge into the older ticket and
   stop. Merging late is the main cause of two agents replying differently.
2. **Confirm the requester is entitled to support.** → Decision **D1**. An
   unverified address on a paid account is not a licence to discuss account
   data; ask the verified admin to confirm.
3. **Read for the four disqualifiers** before classifying: a suspected security
   vulnerability (→ E2), a legal or data-subject request (→ E3), abusive
   content (→ E4), or a report that matches a live incident (→ E5). These leave
   triage immediately and do not get a severity.
4. **Classify the ticket type**: how-to question, suspected defect, data
   request, billing, feature request, or account change. Type drives the queue;
   severity drives the clock. They are separate fields and must not be merged.
5. **Assign severity from the matrix.** → Decision **D2**. Severity describes
   the customer's loss of function, never their tone and never their plan.
6. **Apply the response clock.** → Decision **D3**. The clock is the tighter of
   the internal target for that severity and the contracted response time.
7. **Route.** Product area from the type, then the queue rota. If more than one
   product area applies, route to the area named in the first reproduction step,
   not the first one mentioned in the subject.
8. **Send the first response.** It must state what you understood, what you are
   doing next, and when the customer will next hear from you. An acknowledgement
   with no next contact time does not count as a first response.
9. **Escalate the top severity immediately.** For S1, page the [Duty Engineer]
   and open the escalation channel before finishing the ticket notes. Do not
   wait for the response clock to run down.
10. **Record triage outcome** on the ticket: type, severity, the rule that set
    it, the queue, and any exception invoked.

## Decisions

| ID | Decision | Criteria | Default |
| --- | --- | --- | --- |
| D1 | Entitlement | Requester address verified **and** account has an active plan **or** is within [30]-day trial | Ask the verified admin to confirm |
| D2 | Severity | S1: production unusable for all users of the account, no workaround. S2: major function unusable or unusable for [n]+ users, workaround painful. S3: single function degraded, workaround exists. S4: question, cosmetic, feature request. | S3 |
| D3 | Response clock | Tighter of internal target and contracted time. S1 [30] min, S2 [4] h, S3 [1] business day, S4 [3] business days | Internal target |
| D4 | Goodwill credit | Up to [amount] at agent discretion. Above that, or any credit on a disputed invoice → approval A1 | No credit |
| D5 | Convert to incident | [2]+ unrelated accounts report the same symptom within [30] min | Keep as ticket, flag to [Duty Engineer] |

## Exceptions

- **E1 — No account can be identified.** Reply asking for the account
  identifier; do not guess from the email domain. Close after [2] unanswered
  attempts over [7] days.
- **E2 — Suspected security vulnerability.** Do not reply with details, do not
  discuss in the shared queue. Move the ticket to the restricted queue, notify
  [Security Contact] within [1] hour, and follow [Vulnerability disclosure SOP].
- **E3 — Legal notice or data-subject request.** Route to [Legal / Privacy
  Contact] the same day. Support does not answer erasure, access or subpoena
  requests from the queue.
- **E4 — Abusive or threatening content.** Stop the conversation, notify
  [Support Lead], and follow [Acceptable use policy]. Severity is not assigned.
- **E5 — Matches a live incident.** Link the ticket to the incident, send the
  incident holding reply, and do not triage independently. Reopen triage only if
  the symptom turns out to be unrelated.
- **E6 — Customer disputes the severity.** The severity stays as the matrix
  sets it. Record the disagreement and escalate to [Support Lead], who is the
  only person who may override D2.

## Approvals

| ID | What is approved | Who approves | Why it stays with a person |
| --- | --- | --- | --- |
| A1 | Goodwill credit above [amount] or on a disputed invoice | [Support Lead] with [Finance] | Money leaving the business |
| A2 | Severity override against the matrix | [Support Lead] | Keeps the matrix honest and the override visible |
| A3 | Any public statement, including a status page post | [Incident Commander] | A public statement cannot be retracted |
| A4 | Account-level configuration change requested in a ticket | Verified account admin | Change of access must come from the account, not from support |

## Output

- Every new ticket carrying type, severity, the rule that set it, queue and
  owner.
- A first response containing an understanding, a next step and a next contact
  time.
- Escalations opened for every S1 within the paging target.
- A triage log usable for weekly review of misroutes and severity overrides.

## SLA / KPI

- First response within the D3 clock: target [95%] by severity band.
- Reassignment rate after triage (misroute proxy): target under [10%].
- Duplicate merge rate: tracked, not targeted — a rising number usually means a
  broken notification, not a lazy agent.
- Severity overrides per [100] tickets: target under [3].

## Audit record

Retain for [24] months: full ticket thread, triage fields with timestamps and
the acting agent, every severity override with its A2 approval, every credit
with its A1 approval, and the routing of every E2 and E3 exception including the
handover time.

> Simulated example data
>
> Ticket [#44120] · requester verified on account [Meridian Labs] · type
> [suspected defect] · D2 → **S2** (export unusable for [12] users, manual
> workaround exists) · D3 clock [4] h, contracted time [2] h, so [2] h applied ·
> routed to [Reporting] queue · first response sent at [00:37] with next contact
> committed for [09:00].

## Revision log

| Version | Date | Author | Change |
| --- | --- | --- | --- |
| v1.0 | 2026-07-24 | [Your name] | initial draft |

# Recurring Client Reporting SOP — [Company name]

Template status: [Draft / In review / Approved] · Applies from: [date]

## Purpose

Produce the recurring client report on the same day, from the same data window,
with the same metric definitions every period, so that a number the client saw
last month still means the same thing this month and any change in it is a real
change in performance rather than a change in how it was calculated.

## Scope

The [monthly] performance report for clients on [retainer / managed service],
from data cut-off to delivery and archive.

Out of scope: ad-hoc analysis requests, quarterly business reviews
([QBR SOP]), and invoicing, which reads from the same data but has its own
sign-off.

## Owner

Accountable: [Account Manager].
Supporting: [Analyst] for the data pull, [Delivery Lead] for the internal
review, [Account Director] for external sign-off.

## Trigger

Scheduled: [working day 2] of each month at [09:00] for the previous calendar
month.

Out-of-cycle trigger: a client contract that specifies a different window runs
on its own schedule and is listed in [reporting calendar], never handled by
memory.

## Inputs

| Input | System of record | Required |
| --- | --- | --- |
| Metric definitions and formulas, versioned | [Metric dictionary] | Yes |
| Period data from each source platform | [Named platforms] | Yes |
| Prior period report as published | [Report archive] | Yes |
| Spend and budget for the period | [Finance system] | Yes |
| Commentary notes logged during the period | [Account notes] | Yes |
| Client-specific reporting requirements | [Client file] | Yes |

## Prerequisites

- The metric dictionary is current and every metric in the report template maps
  to a definition in it. A metric with no definition does not go in the report.
- All source platforms have finished their own attribution or restatement window
  for the period. Pulling before a platform settles is the most common cause of
  a number changing after delivery.
- Last period's report is archived exactly as sent, including the commentary.
- The recipient list on the client file was confirmed within the last [90] days.

## Steps

1. **Freeze the data window** and record it explicitly: start timestamp, end
   timestamp, timezone. Every figure in the report comes from this window and
   nothing else.
2. **Confirm each source has settled.** → Decision **D1**. If a platform is
   still restating, either wait within the SLA or publish with a stated
   provisional marker; do not publish a settled-looking number from unsettled
   data.
3. **Pull the raw data per source** into the working file without editing.
   Record row counts and the pull timestamp per source.
4. **Apply the metric definitions** from the dictionary version in force for
   this period, and stamp that version onto the report. This is what lets you
   answer "why is this different from last month" a year later.
5. **Reconcile against the prior period.** Compare every headline metric to the
   published prior figure. → Decision **D2** for anything that has moved beyond
   the variance threshold.
6. **Check for data gaps and outliers** before writing anything: zero-value days
   in a normally active series, a single day carrying an implausible share of
   the period, a metric that is exactly flat. Each of these is a data question
   before it is a performance story.
7. **Compare against budget and target** for the period, and against the same
   period last year where [12] months of comparable data exists under the same
   definitions.
8. **Write the commentary.** Every headline variance beyond the D2 threshold
   gets a sentence naming the cause or explicitly saying the cause is not yet
   known. "Not yet known" is an acceptable answer; silence is not.
9. **Decide whether a prior period must be restated.** → Decision **D3** and
   approval **A2**. A restatement is always disclosed in the report, never
   applied quietly.
10. **Internal review.** [Delivery Lead] checks the numbers against the sources
    and the commentary against the notes. The reviewer is never the person who
    pulled the data.
11. **External sign-off and delivery.** → Approval **A1**. Send to the confirmed
    recipient list only.
12. **Archive** the delivered file, the working file, the source extracts, the
    dictionary version and the sign-off, all under the period key.

## Decisions

| ID | Decision | Criteria | Default |
| --- | --- | --- | --- |
| D1 | Source has settled | Platform's stated attribution window has closed **and** yesterday's pull matches today's for the same window | Not settled → wait or mark provisional |
| D2 | Variance needs commentary | Absolute change ≥ [x%] period-on-period **or** ≥ [amount] **or** crosses a target boundary | Comment |
| D3 | Restate a prior period | Prior figure was wrong by more than [x%] **and** the client made or could reasonably have made a decision on it | Disclose without restating |
| D4 | Hold delivery | A headline metric cannot be produced, or a restatement is unresolved, or the client contact list is unconfirmed | Deliver on time with a stated gap |
| D5 | Provisional marker | Any source not settled at cut-off | Mark the affected metrics provisional and state the settle date |

## Exceptions

- **E1 — Source platform unavailable at cut-off.** Record the outage, deliver
  with the metric marked unavailable and a stated re-issue date. Never estimate
  a platform figure and present it in the same format as measured ones.
- **E2 — Metric definition changed mid-period.** Report both the old and the new
  basis for the first period after the change, then the new basis alone. Note
  the change in the report and bump the dictionary version.
- **E3 — Client changed reporting contacts.** Do not send until the new
  recipient list is confirmed in writing by a known contact. A report is client
  data; a wrong recipient is a disclosure.
- **E4 — Numbers contradict what the client was told during the period.** Raise
  internally before delivery. The report is not the place a client first learns
  that a mid-period update was wrong.
- **E5 — Period contains a one-off event** (an outage, a campaign pause, a
  pricing change). Isolate it in the commentary and state whether the headline
  figures include it. Do not remove it silently.
- **E6 — Data window overlaps a client's own restatement.** Use the client's
  published figures for shared metrics and note the source, rather than
  publishing a competing version of their own numbers.

## Approvals

| ID | What is approved | Who approves | Why it stays with a person |
| --- | --- | --- | --- |
| A1 | Delivery to the client | [Account Director] | Once a report leaves the building it cannot be unsent |
| A2 | Restatement of a previously published figure | [Account Director] with [Delivery Lead] | It changes something the client already acted on |
| A3 | Adding or changing a metric definition | [Delivery Lead] | Definitions are the contract behind the numbers |
| A4 | Sending to a recipient not on the confirmed list | [Account Director] | Disclosure of client data |

## Output

- A delivered report stamped with the data window, the dictionary version and
  the preparer and reviewer.
- Commentary covering every variance above the D2 threshold.
- An archived bundle: delivered file, working file, source extracts, sign-off.
- A log of provisional metrics with their settle dates and re-issue status.

## SLA / KPI

- Delivered by working day [5]: target [100%].
- Reports requiring a post-delivery correction: target under [2%] per quarter.
- Metrics delivered without a dictionary version stamp: target zero.
- Median time from data cut-off to internal review: [x] hours, tracked to see
  where the cycle actually goes.

## Audit record

Retain for [36] months per period and client: the frozen window definition,
source extracts with pull timestamps and row counts, the metric dictionary
version, the working file, the delivered file exactly as sent, the recipient
list, the A1 sign-off, and any A2 restatement with its disclosure text.

> Simulated example data
>
> Client [Harbour Retail], period [2026-06-01 → 2026-06-30 Europe/Berlin], cut
> off [2026-07-02 09:00]. Source [Platform A] settled; source [Platform B]
> still in a [72]-hour attribution window → D5 provisional marker applied to
> [attributed conversions]. Headline [qualified enquiries] moved from [412] to
> [351], a [-14.8%] change, above the D2 threshold of [10%], so commentary
> names the [two-week campaign pause] logged on [2026-06-09]. Dictionary
> version [2026-Q2.1].

## Revision log

| Version | Date | Author | Change |
| --- | --- | --- | --- |
| v1.0 | 2026-07-24 | [Your name] | initial draft |

# Accounts Payable Processing SOP — [Company name]

Template status: [Draft / In review / Approved] · Applies from: [date]

## Purpose

Take a supplier invoice from arrival to a scheduled payment, so that the company
pays the right supplier, the right amount, once, for something it actually
ordered and received, and so that the person who approves an invoice is never
the person who releases the money.

## Scope

Supplier invoices and credit notes arriving in [AP inbox] or [supplier portal],
from receipt to payment posting and filing, for entity [legal entity].

Out of scope: employee expenses ([Expenses SOP]), corporate card transactions,
intercompany recharges, and customer receipts ([Invoice Reconciliation SOP]).

## Owner

Accountable: [Accounts Payable Specialist].
Reviewing: [Financial Controller]. Budget approvals sit with the named budget
holder. Payment release sits with [Treasury / Payment Approver] — deliberately
a different person.

## Trigger

Event: an invoice arrives in [AP inbox] or is posted to [supplier portal].
Scheduled: the payment run executes [weekly on Wednesday]; invoices approved
after [Tuesday 17:00] fall into the following run.

## Inputs

| Input | System of record | Required |
| --- | --- | --- |
| Invoice document (PDF or portal record) | [AP inbox] / [portal] | Yes |
| Purchase order | [Procurement system] | Yes for PO-backed spend |
| Goods or service receipt confirmation | [Procurement system] / requester | Yes for goods |
| Supplier master record with verified bank details | [Accounting system] | Yes |
| Contract or rate card | [Contract store] | For recurring services |
| Tax / VAT treatment rules for the jurisdiction | [Tax guidance] | Yes |

## Prerequisites

- Supplier exists on the approved master with bank details verified out of band
  at onboarding, and the master is only editable by someone who cannot approve
  or release payments.
- A published approval matrix by amount band and cost centre (D3).
- Purchase orders are raised **before** the spend commitment for all categories
  where PO discipline applies. An invoice for an unraised PO is exception E1.
- Segregation of duties is real, not nominal. The GAO Green Book describes
  dividing key duties — authorising, processing and recording, and reviewing —
  among different people to reduce the risk of error and fraud; see
  [Standards for Internal Control in the Federal Government](https://www.gao.gov/products/gao-25-107721).

## Steps

1. **Capture and register the invoice.** Assign a unique AP reference on
   arrival, before any judgement about validity. An invoice that is rejected
   still has a record.
2. **Extract the header fields**: supplier name, supplier tax identifier,
   invoice number, invoice date, currency, net, tax, gross, payment terms, PO
   reference, bank details as printed.
3. **Run the duplicate check** on supplier plus invoice number, then on supplier
   plus amount plus date within [30] days. → Exception **E4**. Duplicates are
   most often the same invoice sent by email and by portal.
4. **Validate the supplier against the master.** → Decision **D1**. If bank
   details on the invoice differ from the master, stop: exception **E5**. Do not
   update the master from the invoice.
5. **Match the invoice.** → Decision **D2**. Two-way against the PO for
   services, three-way against PO and receipt for goods.
6. **Apply the tolerance rule** to price and quantity variances. Within
   tolerance, proceed and record the variance. Outside tolerance, route to the
   requester with the variance stated (→ **E2**), never to the supplier first.
7. **Check the tax treatment**: correct rate, valid supplier tax identifier,
   reverse charge or withholding where it applies, and that the invoice carries
   the details your jurisdiction requires to be a valid tax document.
8. **Code to the general ledger**: account, cost centre, and period. Period is
   the period the goods or service was received, not the date you happened to
   process it.
9. **Route for approval.** → Decision **D3**. The budget holder approves the
   commitment; approval is recorded in the system, never by forwarded email.
10. **Schedule the payment.** → Decision **D4**: terms, any early-settlement
    discount, and cash-position constraints. Do not pay early by default; do not
    pay late by drift.
11. **Release the payment.** → Approval **A2**, by a person who did not enter
    the invoice, did not approve it and cannot edit the supplier master.
12. **Post and file.** Post the payment, attach the invoice, PO, receipt,
    approvals and remittance to the AP reference, and close the item.

## Decisions

| ID | Decision | Criteria | Default |
| --- | --- | --- | --- |
| D1 | Supplier is valid | On the approved master, active, bank details match the master exactly | Hold, do not process |
| D2 | Match type | Goods with a PO → three-way. Services with a PO → two-way. Contracted recurring service → match to contract rate card. No PO → E1. | Three-way |
| D3 | Approval route | ≤ [amount A]: [Accounts Payable Specialist] alone. [A]–[B]: budget holder. [B]–[C]: budget holder + [Financial Controller]. > [C]: + [CFO] | Budget holder |
| D4 | Payment timing | Pay on terms. Take early-settlement discount only if the discount rate beats [threshold] and cash allows. | Pay on terms |
| D5 | Tolerance | Price variance ≤ [%] and ≤ [amount]; quantity variance ≤ [%] | Outside tolerance → E2 |
| D6 | Hold the payment | Open dispute, unresolved variance, supplier compliance flag, or duplicate suspicion | Release if none apply |

## Exceptions

- **E1 — Invoice with no purchase order.** Route to the requester to raise a
  retrospective PO with a stated reason, and log it. A rising count of E1 is a
  procurement problem, not an AP problem, and belongs in the monthly review.
- **E2 — Price or quantity variance beyond tolerance.** Return to the requester
  with the PO, the receipt and the invoice line side by side. AP does not
  negotiate the variance; the person who ordered does.
- **E3 — Credit note.** Match to the original invoice and offset within the same
  supplier account. Never net a credit note against an unrelated invoice to make
  a payment run balance.
- **E4 — Duplicate suspected.** Hold both, confirm against the supplier
  statement, and cancel the later registration with a reason. Retain the
  cancelled record.
- **E5 — Bank details differ from the supplier master, or a change is
  requested.** Treat every change request as suspected fraud until proven
  otherwise. Verify by calling a number already held on the supplier master, not
  a number on the invoice or in the email. Change requires approval **A3** and a
  second person. This is the single most exploited step in accounts payable.
- **E6 — Supplier not on the approved master.** Do not create the supplier to
  clear the invoice. Route to [Vendor Compliance Review SOP] and hold.
- **E7 — Invoice in a foreign currency.** Post at the rate defined in
  [FX policy] with the rate source recorded, and revalue at period end.
- **E8 — Statement shows an invoice you have never received.** Request a copy
  from the supplier; do not pay from a statement line.

## Approvals

| ID | What is approved | Who approves | Why it stays with a person |
| --- | --- | --- | --- |
| A1 | The spend commitment on the invoice | Budget holder per D3 | Someone must be accountable for the cost |
| A2 | Release of the payment run | [Treasury / Payment Approver], different from the enterer and the approver | Money irreversibly leaves the business |
| A3 | Change to supplier bank details | [Financial Controller] plus a second verifier, out-of-band verified | Payment redirection fraud happens here |
| A4 | Adding a new supplier to the master | [Financial Controller] after vendor review | Prevents the invoice itself from creating its own payee |
| A5 | Paying outside terms, early or late | [Financial Controller] | Cash and relationship impact |

## Output

- Approved, coded and posted invoices with a complete document set attached to
  the AP reference.
- A payment run released by an authorised second person, with a remittance sent
  to each supplier.
- An exceptions log by type, reviewed [monthly].
- An accruals list for goods received but not invoiced at period end.

## SLA / KPI

- Touchless rate: invoices matched and approved with no manual intervention.
  Target [x%], measured monthly.
- Invoices processed within [5] business days of receipt: target [95%].
- Duplicate payments per period: target zero.
- On-time payment rate against terms: target [98%].
- E1 count (no-PO invoices) trending down quarter on quarter.

## Audit record

For every invoice retain the invoice document, PO, receipt, coding, approvals
with approver and timestamp, payment reference and remittance. Supporting
documents for business expenses should show the payee, the amount paid, proof of
payment, the date incurred and a description of the item, and the same
requirements apply to electronic records; see the IRS guidance on
[what kind of records to keep](https://www.irs.gov/businesses/small-businesses-self-employed/what-kind-of-records-should-i-keep)
and
[recordkeeping](https://www.irs.gov/taxtopics/tc305). Confirm the retention
period and the tax-document requirements that apply to your entity with your
accountant.

> Simulated example data
>
> Invoice [SUP-88431] from [Aldergate Components Ltd], gross [EUR 12,480.00],
> PO [PO-20261-0412], goods receipt [GRN-9931]. D2 → three-way match. PO line
> price [EUR 12,300.00]; variance [180.00] is [1.46%], inside the D5 tolerance
> of [2%] and [250.00], so the invoice proceeds with the variance recorded.
> D3 → amount falls in band [B]–[C], approved by budget holder [Head of
> Production] and [Financial Controller]. Payment scheduled for run
> [2026-07-29] on [30]-day terms; released under A2 by [Treasury] who did not
> enter or approve the invoice.

## Revision log

| Version | Date | Author | Change |
| --- | --- | --- | --- |
| v1.0 | 2026-07-24 | [Your name] | initial draft |

# Invoice Reconciliation SOP — [Company name]

Template status: [Draft / In review / Approved] · Applies from: [date]

## Purpose

Match incoming customer payments to open sales invoices so that the accounts
receivable ledger reflects what the bank actually received, unapplied cash is
cleared rather than parked, and the aged debt report can be trusted by whoever
chases it.

## Scope

Cash application and reconciliation for customer receipts in [bank accounts] and
[payment processor] against invoices raised in [accounting system], for the
period [monthly close / weekly cycle].

Out of scope: raising invoices ([Billing SOP]), supplier payments ([Accounts
Payable Processing SOP]), payroll, and intercompany balances.

## Owner

Accountable: [Accounts Receivable Analyst].
Reviewing: [Financial Controller]. Escalation for disputes: [Credit Control].

## Trigger

Scheduled: [daily] bank feed import at [time], plus a full reconciliation on
[working day 3] of the following month.

Event trigger: any receipt above [amount] is reconciled the same day rather than
waiting for the cycle.

## Inputs

| Input | System of record | Required |
| --- | --- | --- |
| Bank statement lines with value date and reference | [Bank feed] | Yes |
| Payment processor settlement report, gross and fee | [Payment processor] | Yes |
| Open invoice ledger with due dates | [Accounting system] | Yes |
| Remittance advices received | [AR inbox] | Where sent |
| Credit notes and agreed deductions | [Accounting system] | If any |
| Closing FX rates for the period | [Rate source, named] | If multi-currency |

## Prerequisites

- Opening balance agreed and the previous period locked. Reconciling into an
  unlocked prior period rewrites history.
- Bank feed complete to the cut-off timestamp, with no gaps in the statement
  sequence.
- Customer master data current: legal entity names, trading names and any
  factoring or payment-service intermediaries the customer pays through.
- Documented tolerance and write-off thresholds (D2, D4) approved by
  [Financial Controller].

## Steps

1. **Freeze the window.** Fix the statement cut-off date and time and record it.
   Everything that follows reconciles to that boundary; late lines belong to the
   next cycle.
2. **Import and de-duplicate statement lines.** Same amount, same value date and
   same reference imported twice is an import artefact, not a double payment.
   Confirm against the bank's own statement sequence number before deleting.
3. **Attempt exact match**: invoice number present in the payment reference and
   amount equal to the open balance. These clear without further work.
4. **Attempt structured match** for the remainder: remittance advice lines,
   then customer plus amount, then customer plus a set of invoices summing to
   the receipt. Record which rule matched — you will need it when the pattern
   changes.
5. **Apply tolerance to near matches.** → Decision **D2**. Within tolerance,
   clear the invoice and post the difference to [rounding / bank charges
   account]. Outside tolerance, the item stays open.
6. **Handle partial payments.** → Decision **D3**. Apply against the oldest
   invoice unless the remittance says otherwise; a remittance advice always
   overrides the default allocation order.
7. **Reconcile the payment processor separately.** Settlements arrive net of
   fees. Post gross to the customer account and the fee to [processor fees],
   then agree the settlement total to the bank line. Never reconcile a customer
   invoice against a net figure.
8. **Revalue foreign-currency receipts** at the recorded rate and post the
   difference to [FX gain/loss]. Record the rate source and timestamp used.
9. **Work the unapplied cash list.** Every receipt still unmatched gets an owner
   and an action: request a remittance, contact the customer, or flag as an
   overpayment (→ E3). Unapplied cash with no owner is the item that quietly
   grows for a year.
10. **Decide on write-offs.** → Decision **D4**. Anything above the analyst
    threshold goes to approval **A1**.
11. **Agree the control totals.** Opening AR + invoices raised − receipts
    applied − credit notes − write-offs = closing AR. If it does not agree, do
    not adjust to force it; find the line.
12. **Publish the aged debt report** and hand the [60]+ day items to
    [Credit Control] with the reconciliation status attached.

## Decisions

| ID | Decision | Criteria | Default |
| --- | --- | --- | --- |
| D1 | Which customer a receipt belongs to | Invoice number in reference > remittance advice > exact legal entity name > bank account previously used by that customer | Leave unapplied, never guess from a partial name match |
| D2 | Tolerance for a near match | Absolute difference ≤ [amount] **and** ≤ [%] of invoice value | Outside tolerance → stays open |
| D3 | Allocation order for partial payment | Remittance advice, else oldest invoice first, else customer's written instruction on file | Oldest first |
| D4 | Write off a residual balance | Residual ≤ [amount] **and** invoice older than [90] days **and** no active dispute | Do not write off |
| D5 | Refer to collections | Balance overdue [60]+ days with no payment plan and no open dispute | Refer |

## Exceptions

- **E1 — Receipt with no identifiable customer.** Hold in unapplied cash with a
  named owner and a [7]-day chase. Do not apply it to the customer who most
  recently paid a similar amount.
- **E2 — Duplicate payment from the customer.** Confirm both receipts cleared
  the bank, then treat as an overpayment, not as a credit. Refunds require
  approval **A2** and the bank details must be verified against the customer
  record, not against the email requesting the refund.
- **E3 — Overpayment.** Leave as a credit on account or refund per D-policy;
  either way, notify the customer in writing so it does not reappear as a
  dispute at year end.
- **E4 — Payment received by a group entity or a factoring house.** Reconcile
  against the entity that raised the invoice and record the intermediary on the
  customer master so the next receipt matches automatically.
- **E5 — Customer deducts an amount unilaterally.** Do not net it off. Raise a
  dispute record, allocate the amount received, and leave the deduction open
  until the dispute is settled or a credit note is issued.
- **E6 — Bank feed gap.** If the statement sequence is broken, stop. A
  reconciliation over an incomplete feed is worse than no reconciliation because
  it looks finished.

## Approvals

| ID | What is approved | Who approves | Why it stays with a person |
| --- | --- | --- | --- |
| A1 | Write-off above the analyst threshold | [Financial Controller] | Reduces recorded income |
| A2 | Refund of an overpayment | [Financial Controller], bank details verified by a second person | Money leaving the business to a bank account |
| A3 | Manual journal to force a control total | [Financial Controller] | A forced total hides the real error |
| A4 | Period close | [Financial Controller] | Locks the ledger against restatement |

## Output

- Cash applied to the correct customer and invoice, with the matching rule
  recorded per receipt.
- An unapplied cash list where every line has an owner, an age and an action.
- A signed control-total reconciliation for the period.
- An aged debt report handed to credit control with dispute status attached.

## SLA / KPI

- Auto-match rate at first pass: target [80%] of receipts by count.
- Unapplied cash older than [30] days: target under [amount] at each close.
- Reconciliation complete by working day [3]: target [100%].
- Number of A3 forced journals per period: target zero.

## Audit record

Retain the bank statements, remittance advices, settlement reports, the matching
rule and allocation applied to each receipt, every write-off with its A1
approval, every refund with its A2 approval and the evidence of bank-detail
verification, and the signed control-total reconciliation. Supporting documents
for business income and expenses should identify the payer, the amount, the date
and a description, and the same rules apply to electronic records; see the IRS
guidance on
[what kind of records to keep](https://www.irs.gov/businesses/small-businesses-self-employed/what-kind-of-records-should-i-keep)
and confirm the retention period that applies in your jurisdiction with your
accountant.

> Simulated example data
>
> Receipt [GBP 4,187.50] value date [2026-06-30], reference `INV-2291 2294`.
> D1 → matched to [Halcyon Print Ltd] on invoice numbers. Invoices open
> [2,100.00] + [2,090.00] = [4,190.00]. Difference [2.50] is inside the D2
> tolerance of [5.00] and [0.2%], so both invoices cleared and [2.50] posted to
> [bank charges]. Matching rule recorded as `reference-multi-invoice`.

## Revision log

| Version | Date | Author | Change |
| --- | --- | --- | --- |
| v1.0 | 2026-07-24 | [Your name] | initial draft |

# Lead Enrichment and CRM Cleanup SOP — [Company name]

Template status: [Draft / In review / Approved] · Applies from: [date]

## Purpose

Turn a raw inbound lead into a record a salesperson can act on without
re-researching it, and keep the CRM free of the duplicates, dead domains and
mis-assigned owners that make routing and reporting untrustworthy.

## Scope

New leads arriving from [web forms], [events] and [list uploads], plus the
[weekly] hygiene sweep over records touched in the last [7] days.

Out of scope: outbound prospecting list building, opportunity management after
qualification, and any bulk import over [1,000] rows, which follows
[Bulk import SOP] because of its blast radius.

## Owner

Accountable: [Revenue Operations Specialist].
Supporting: [Sales Manager] for territory rules, [Data Protection Contact] for
E5 and A3.

## Trigger

Event: a lead record is created in [CRM] by any source.
Scheduled: the hygiene sweep runs [weekly on Monday 07:00] over records created
or modified in the previous [7] days.

## Inputs

| Input | System of record | Required |
| --- | --- | --- |
| Submitted form fields, raw | [CRM] / [form tool] | Yes |
| Capture context: source, campaign, page, timestamp | [CRM] | Yes |
| Existing accounts, contacts and open opportunities | [CRM] | Yes |
| Enrichment response for the company domain | [Enrichment source, named] | Best effort |
| Suppression list: do-not-contact, unsubscribes, erasure requests | [Suppression register] | Yes |
| Territory and routing rules, current version | [Sales ops sheet] | Yes |

## Prerequisites

- A written ideal-customer-profile definition with thresholds, not adjectives.
- A field dictionary stating the canonical format of every field you normalise
  (country codes, industry values, employee bands).
- The suppression register is authoritative and reachable before any record is
  routed. If it is unavailable, routing stops.
- Merge rights restricted to [Revenue Operations Specialist]; nobody else merges
  records.

## Steps

1. **Capture the raw submission unchanged** into an immutable field before
   normalising anything. Every later dispute about "the form said X" is settled
   here.
2. **Check the suppression register first.** A match ends processing: no
   enrichment, no routing, no sequence. Suppression is checked before enrichment
   so you do not buy data about someone who asked you to stop.
3. **Normalise fields** to the field dictionary: trim whitespace, lowercase the
   email, resolve the company domain from the email where the company field is
   blank, map country to [ISO 3166-1 alpha-2], map free-text industry to the
   controlled list.
4. **Classify the email domain.** → Decision **D1**. Personal domains,
   competitor domains and known throwaway domains take different paths and must
   not be silently enriched.
5. **Search for an existing record** before creating anything: by email, then by
   company domain, then by normalised company name plus country. → Decision
   **D2**.
6. **Enrich the company, not the person, by default.** Employee band, sector,
   country, and any published funding or headcount signal you actually use in
   routing. Enriching personal attributes you do not use in a decision is data
   you have to justify holding.
7. **Reconcile enrichment against self-reported data.** → Exception **E3**.
   Self-reported wins on job title and intent; enrichment wins on domain-level
   firmographics. Never overwrite a field the prospect typed themselves.
8. **Score against the ICP definition** and record the inputs to the score, not
   only the number. A score nobody can explain gets ignored within a quarter.
9. **Route.** → Decision **D3**. Assign the owner from the territory rules,
   stamping the rule version used. If no rule matches, route to the [unassigned]
   queue with an owner and a [4]-hour clock, never to a default person.
10. **Decide on sequence enrolment.** → Decision **D4** and approval **A2** for
    contacts in jurisdictions where your legal basis for outbound contact
    requires it.
11. **Run the hygiene sweep** over the [7]-day window: unresolvable domains,
    records with no owner, contacts whose account was merged away, and
    duplicates created since the last sweep. Produce a proposed change list.
12. **Apply the change list.** Anything above the bulk threshold goes to
    approval **A1**, and the pre-change export is kept so it can be reversed.

## Decisions

| ID | Decision | Criteria | Default |
| --- | --- | --- | --- |
| D1 | Domain class | Free-mail provider list → personal. Domain on [competitor list] → competitor. Domain on [disposable list] or MX record absent → invalid. | Business |
| D2 | Merge or keep separate | Same email → merge. Same company domain and same normalised name → merge accounts, keep both contacts. Same name, different country → keep separate. | Keep separate and flag for review |
| D3 | Routing target | ICP score ≥ [n] and employee band ≥ [x] → [named sales segment]. Below → nurture. Existing open opportunity → the opportunity owner, always. | Nurture |
| D4 | Enrol in an outbound sequence | Not suppressed, business domain, legal basis recorded for the contact's jurisdiction | Do not enrol |
| D5 | Discard as non-ICP | Domain class invalid, or explicitly out-of-scope sector, or student/personal-research intent stated | Keep in nurture |

## Exceptions

- **E1 — Personal email domain on an otherwise good lead.** Do not discard and
  do not guess a company. Route to nurture with a task to ask for a work address
  on first contact.
- **E2 — Competitor domain.** Flag, do not enrol, and notify [Sales Manager].
  Do not add commentary to the record that you would not want read aloud.
- **E3 — Enrichment contradicts self-reported data.** Keep both: the submitted
  value in the immutable capture, the enriched value in a clearly named
  `enriched_*` field. Never merge them into one field.
- **E4 — Duplicate detected after an opportunity exists on one record.** Do not
  merge automatically. The opportunity's history is the record of truth; merge
  into it manually and re-point activities.
- **E5 — Erasure or objection request.** Route to [Data Protection Contact] the
  same day, add to the suppression register immediately, and stop all processing
  of that record including enrichment. This exception overrides every other rule
  in this document.
- **E6 — Enrichment source unavailable.** Route on self-reported data alone and
  queue for re-enrichment. Never hold a lead in a queue waiting for enrichment.

## Approvals

| ID | What is approved | Who approves | Why it stays with a person |
| --- | --- | --- | --- |
| A1 | Bulk merge or delete affecting more than [50] records | [Revenue Operations Specialist] with [Sales Manager] | Irreversible at scale; the pre-change export is checked as part of the approval |
| A2 | Outbound enrolment where legal basis depends on jurisdiction | [Data Protection Contact] | Contact rules differ by jurisdiction and the risk is not the salesperson's to carry |
| A3 | Adding a new enrichment source or new enriched field | [Data Protection Contact] | New data collection needs a stated purpose |
| A4 | Change to territory or routing rules | [Sales Manager] | Routing determines compensation |

## Output

- Lead records with normalised fields, a preserved raw capture, an explainable
  score, an owner and a stamped routing-rule version.
- A suppression check recorded on every processed record.
- A weekly hygiene change list with before/after counts and a reversible export.
- A queue of records that could not be routed, each with an owner and a clock.

## SLA / KPI

- Enrichment and routing complete within [60] minutes of creation for business
  domains: target [95%].
- Duplicate rate among records created in the period: target under [2%].
- Records with no owner after the sweep: target zero.
- Percentage of routed leads where the routing rule version is recorded: [100%].

## Audit record

Retain for [24] months: the raw capture, the suppression check result and
timestamp, every enriched field with its source and retrieval date, the score
inputs, the routing rule version, and every bulk change with its A1 approval and
the pre-change export. Erasure requests and their completion dates are retained
separately per [Data retention policy].

> Simulated example data
>
> Form submission [2026-05-11 09:14], email `ops@[northwind-freight].example`,
> company field blank. D1 → business domain, resolved from email. D2 → existing
> account matched on domain, contact created against it. Enrichment returned
> employee band [201–500]; self-reported title [Head of Operations] kept
> unchanged. ICP score [72] (band [+30], sector [+25], region [+17]). D3 →
> routed to [Mid-market EMEA], rule version [2026-04].

## Revision log

| Version | Date | Author | Change |
| --- | --- | --- | --- |
| v1.0 | 2026-07-24 | [Your name] | initial draft |

# Vendor Compliance Review SOP — [Company name]

Template status: [Draft / In review / Approved] · Applies from: [date]

## Purpose

Decide, on evidence rather than familiarity, whether a supplier may be engaged
and what conditions attach, and make sure the same decision is revisited on a
schedule instead of being made once at purchase and never looked at again.

## Scope

New vendor requests and scheduled re-reviews for suppliers that process company
or customer data, hold system access, or are relied on for a service the
business cannot immediately replace.

Out of scope: one-off purchases below [amount] with no data access and no system
access, and the commercial negotiation itself ([Procurement SOP]).

## Owner

Accountable: [Vendor Risk Lead].
Supporting: [Requesting Manager] for business need, [Security Contact] for
technical review, [Legal Contact] for contract terms, [Finance] for onboarding
to the payment system.

## Trigger

Event: a vendor request is submitted by a [Requesting Manager], or an existing
vendor's scope changes to include data or system access.

Scheduled: the re-review date set at the last decision (see D4), plus an
immediate review on receipt of a breach notification from the vendor (→ E5).

## Inputs

| Input | System of record | Required |
| --- | --- | --- |
| Business case: what the vendor does and what breaks without them | [Request form] | Yes |
| Data the vendor will process, by category and volume | [Request form] | Yes |
| System access requested, by scope | [Request form] | Yes |
| Completed security questionnaire | [Vendor risk register] | Tier-dependent |
| Certifications and audit reports with expiry dates | Vendor-supplied | Tier-dependent |
| Insurance certificate | Vendor-supplied | If contract value ≥ [amount] |
| Subprocessor list and hosting locations | Vendor-supplied | If data is processed |
| Sanctions and denied-party screening result | [Screening source] | Yes |

## Prerequisites

- A written data classification scheme, so "what data will they touch" has a
  defined answer rather than a judgement call per request.
- A current register with every existing vendor, their tier and their next
  review date. A review process with no register only ever reviews new vendors.
- Named [Security Contact] and [Legal Contact] with capacity inside the SLA.
- The standard data processing agreement and the list of terms that may not be
  varied without [Legal Contact].

## Steps

1. **Check the register first.** The vendor may already be engaged by another
   team under different terms. Duplicate engagements are the most common finding
   in a first pass over a register.
2. **Validate the business case.** What is the vendor doing, who owns the
   relationship, and what happens to the business if they stop tomorrow. An
   answer of "we would be fine" changes the tier; an answer of "we would stop
   trading" changes the exit plan.
3. **Classify the data and access.** → Decision **D1**. This is the single input
   that drives the depth of everything after it.
4. **Assign the risk tier.** → Decision **D2**. Record the reason, because the
   tier is what a future auditor will question.
5. **Run sanctions and denied-party screening** on the legal entity and its
   stated ultimate parent. A positive hit stops the process (→ E4); it is not a
   condition to be negotiated.
6. **Collect the evidence for that tier.** Certifications with expiry dates,
   most recent audit report, penetration-test summary, insurance certificate,
   subprocessor list, hosting regions, incident-notification commitment.
7. **Check every certificate's validity date, not its existence.** An expired
   certificate is an exception (→ E1), not a tick.
8. **Review the subprocessor list against the data classification.** A
   subprocessor in a location or category the classification does not permit is
   a condition of engagement or a rejection, never a footnote.
9. **Review contract terms** against the standard set: notification window for
   incidents, audit rights, deletion on termination, liability cap, exit
   assistance. → Approval **A2** for any variation.
10. **Reach a decision.** → Decision **D3**: accept, accept with named
    conditions and owners, or reject. Conditions without an owner and a date are
    not conditions.
11. **Record the decision and set the next review date.** → Decision **D4**.
12. **Only then onboard to payment.** Bank details are verified by [Finance]
    against a source that is not the email containing them, and by a person who
    did not request the vendor.

## Decisions

| ID | Decision | Criteria | Default |
| --- | --- | --- | --- |
| D1 | Data class | None / internal-only / customer personal data / special category or regulated data | Assume customer personal data until evidenced otherwise |
| D2 | Risk tier | Tier 1: special category data, or production system access, or no viable replacement. Tier 2: customer personal data or limited system access. Tier 3: no data, no access, replaceable. | Tier 2 |
| D3 | Engagement decision | Evidence complete for tier, no unresolved high finding, terms acceptable | Accept with conditions |
| D4 | Re-review interval | Tier 1: [12] months. Tier 2: [24] months. Tier 3: on renewal. Any tier: immediately on breach notification or scope change. | Tier interval |
| D5 | Conditions may be waived | Never for Tier 1 findings; Tier 2 and 3 only with approval **A3** and a stated end date | No waiver |

## Exceptions

- **E1 — Certificate expired or expiring within [60] days.** Accept only with a
  condition naming the renewal date and an owner who will check it. Record the
  gap; do not treat the previous year's certificate as current evidence.
- **E2 — Vendor declines to complete the questionnaire.** Escalate to
  [Requesting Manager] and [Vendor Risk Lead]. For Tier 1 and 2 this is a
  rejection unless an equivalent audit report covers the same ground.
- **E3 — Sole-source vendor with material findings.** Do not silently accept.
  Document the dependency, agree compensating controls with [Security Contact],
  set a shorter re-review, and obtain approval **A4** at executive level.
- **E4 — Sanctions or denied-party hit.** Stop. Escalate to [Legal Contact]
  immediately. No engagement, no payment, and no further correspondence without
  legal direction.
- **E5 — Breach notification received from an engaged vendor.** Trigger an
  immediate re-review, notify [Security Contact] and [Legal Contact] within [24]
  hours, and assess whether your own notification obligations are engaged.
- **E6 — Vendor changes its subprocessors or hosting region after engagement.**
  Treat as a scope change: re-run steps 8 to 11, do not wait for the scheduled
  review.
- **E7 — Bank detail change request mid-engagement.** Never actioned from an
  email or a portal message alone. Verify out of band with a known contact using
  details already on file.

## Approvals

| ID | What is approved | Who approves | Why it stays with a person |
| --- | --- | --- | --- |
| A1 | Engagement of a Tier 1 vendor | [Vendor Risk Lead] with [Security Contact] | Highest exposure to data and continuity risk |
| A2 | Variation to standard contract terms | [Legal Contact] | Contractual liability |
| A3 | Waiver of a condition | [Vendor Risk Lead] with a stated end date | A waiver with no end date becomes a permanent gap |
| A4 | Accepting a sole-source vendor with material findings | [Executive sponsor] | Accepting residual risk on behalf of the business |
| A5 | Adding vendor bank details to the payment system | [Finance] second person, out-of-band verified | Payment fraud is committed at exactly this step |

## Output

- A register entry per vendor: tier, decision, evidence with expiry dates,
  conditions with owners and dates, and the next review date.
- A decision record naming who approved what and on what evidence.
- A conditions worklist that is reviewed [monthly], not at renewal.
- Payment-system onboarding only after A5.

## SLA / KPI

- Decision within [10] business days of a complete submission: target [90%].
- Vendors past their re-review date: target zero.
- Open conditions past their due date: target zero, reported [monthly].
- Percentage of Tier 1 vendors with in-date evidence on file: [100%].

## Audit record

Retain for the engagement term plus [6] years: the request, the classification
and tier with reasons, all evidence documents with their validity dates, the
screening result, the decision record and its approvals, every condition with
its owner, due date and closure evidence, and every scope change or breach
notification with the resulting re-review.

> Simulated example data
>
> Vendor [Kestrel Analytics BV] · requested by [Marketing] · D1 → customer
> personal data, no special category · system access: [read-only API], so
> D2 → **Tier 2** · questionnaire complete, [ISO 27001] certificate valid to
> [2027-01-31], subprocessor list shows one processor in a region not covered by
> the current transfer mechanism → D3 = accept with conditions: transfer
> mechanism confirmed by [Legal Contact], owner [Vendor Risk Lead], due
> [2026-08-15]. Next review [2028-07]. A5 bank verification completed by
> [Finance] by phone to a number already on file.

## Revision log

| Version | Date | Author | Change |
| --- | --- | --- | --- |
| v1.0 | 2026-07-24 | [Your name] | initial draft |

# Employee Onboarding SOP — [Company name]

Template status: [Draft / In review / Approved] · Applies from: [date]

## Purpose

Get a new joiner legally employed, paid correctly, equipped and productively
working from day one, with access granted by role rather than by copying the
permissions of whoever sat in the seat before them.

## Scope

Permanent and fixed-term employees, from signed offer to the end of the [90]-day
review, in [jurisdictions covered].

Out of scope: contractors and agency workers ([Contingent worker SOP]), internal
transfers ([Internal move SOP]), and recruitment up to offer acceptance
([Hiring SOP]).

This template is generic. Employment, right-to-work, background-screening and
record-retention rules differ by jurisdiction and by role, so have your version
reviewed by someone qualified in the jurisdictions you hire in before you use
it. Onboarding also collects some of the most sensitive data an employer holds:
every step below states what is collected and why, and a field with no stated
purpose does not get collected.

## Owner

Accountable: [People Operations Partner].
Supporting: [Hiring Manager] for role and access, [IT] for equipment and
accounts, [Payroll] for pay and benefits, [Legal / HR Advisor] for E2 and A4.

## Trigger

Event: candidate accepts and returns the signed offer.
Schedule: the task sequence is anchored to the start date — T-10, T-5, T-1, day
one, day 30, day 90 — not to the acceptance date.

## Inputs

| Input | System of record | Required |
| --- | --- | --- |
| Signed offer and contract | [HR system] | Yes |
| Role definition and reporting line | [HR system] | Yes |
| Right-to-work / employment eligibility documents | [HR system, restricted] | Yes, per jurisdiction |
| Payroll data: bank details, tax identifiers, start date | [Payroll system, restricted] | Yes |
| Access bundle for the role | [Access catalogue] | Yes |
| Equipment specification and delivery address | [IT asset system] | Yes |
| Background screening outcome, where lawful and role-relevant | [Screening provider] | If D3 = yes |

## Prerequisites

- A role-based access catalogue exists. Without it, step 6 becomes "copy
  someone's access", which is how permission creep starts.
- Payroll cut-off dates for the start month are known and the start date is
  checked against them before any promise about the first payslip.
- Right-to-work checking method for the jurisdiction is documented and the
  checker is trained.
- Manager has confirmed the first-week schedule before T-5.

## Steps

1. **Create the employee record** from the signed contract, not from the offer
   conversation. Job title, start date, salary, working pattern, probation
   length and notice period all come from the executed document.
2. **Confirm the start date against payroll cut-off.** If the start date falls
   after cut-off, tell the joiner before they start what their first payslip
   will contain. → Exception **E5** if it moves later.
3. **Collect right-to-work / employment eligibility evidence** by the method
   required in the jurisdiction, on or before the first day as the law requires.
   Store in the restricted area, retain per the retention rule, and record only
   the fact and date of the check where others can see it.
4. **Decide whether background screening applies.** → Decision **D3**. Screening
   runs only where it is lawful, role-relevant and consistently applied.
   Individualised assessment applies before any adverse decision; see the EEOC
   guidance on
   [background checks](https://www.eeoc.gov/laws/guidance/background-checks-what-employers-need-know)
   and take local advice.
5. **Order equipment against the role specification.** → Decision **D2** for
   remote versus onsite. Anything above [amount] needs approval **A2**.
6. **Assemble the access bundle from the catalogue.** → Decision **D1**. The
   [Hiring Manager] approves the bundle (**A1**); nobody grants access by
   copying an existing account.
7. **Enrol in payroll and benefits.** Collect only what payroll and the benefits
   provider require. Confirm tax status, pension or retirement enrolment and any
   statutory deductions for the jurisdiction.
8. **Prepare the first week.** Day-one schedule, buddy assigned, manager
   one-to-one booked, mandatory training assigned with due dates, and the
   security and acceptable-use briefing scheduled inside week one.
9. **Day one: verify, do not assume.** Confirm the joiner can log in, has the
   equipment, and that every account in the approved bundle exists and nothing
   outside it does. Log any gap the same day.
10. **Day 30 check-in.** Manager and [People Operations Partner] review against
    the role expectations set at offer. Record the outcome.
11. **Day 90 / probation review.** → Approval **A4** for any outcome other than
    confirmation. Record the evidence used, not only the conclusion.
12. **Close the onboarding record**: access reconciled to the approved bundle,
    all documents filed in the restricted store, training completions logged.

## Decisions

| ID | Decision | Criteria | Default |
| --- | --- | --- | --- |
| D1 | Access bundle | Role in the access catalogue → its named bundle. New role with no bundle → [Hiring Manager] and [IT] define one before day one. | Least-privilege base bundle only |
| D2 | Equipment set | Remote worker → remote set including [peripherals, connectivity allowance]. Onsite → standard set. Role-specific hardware needs A2. | Standard onsite set |
| D3 | Background screening | Lawful in the jurisdiction **and** role has [financial authority / regulated duties / access to special-category data] **and** applied consistently to everyone in that role | No screening |
| D4 | Start date may proceed | Right-to-work evidence obtained per jurisdictional timing, contract signed, access bundle approved | Do not start |
| D5 | Probation outcome | Confirm, extend by [period], or not confirm | Confirm only on recorded evidence |

## Exceptions

- **E1 — Right-to-work evidence missing or unclear.** Do not improvise. Escalate
  to [Legal / HR Advisor] before the start date. Starting someone without a
  compliant check is a legal exposure, not an administrative slip.
- **E2 — Adverse screening result.** Never an automatic withdrawal. Follow the
  individualised-assessment process, give the person an opportunity to respond,
  and route the decision to [Legal / HR Advisor] with approval **A4**.
- **E3 — Equipment will not arrive for day one.** Arrange a loan device and tell
  the joiner before they start. Do not let a new colleague discover it on the
  morning.
- **E4 — Access requested outside the approved bundle.** Treated as a new access
  request with its own approval, and added to the catalogue if it turns out to
  be part of the role.
- **E5 — Start date moves.** Re-anchor every T-minus task, re-check payroll
  cut-off, and re-confirm right-to-work timing. Do not simply shift the calendar
  entries.
- **E6 — Candidate withdraws after acceptance.** Cancel provisioning within [24]
  hours, return equipment to stock, and delete collected personal data that no
  longer has a purpose, retaining only what the retention rule requires.
- **E7 — Joiner is a rehire.** Do not reactivate the old accounts. Create fresh
  accounts against the current bundle and archive the historical record.

## Approvals

| ID | What is approved | Who approves | Why it stays with a person |
| --- | --- | --- | --- |
| A1 | Access bundle for the role | [Hiring Manager] | Access is authority; someone must own the grant |
| A2 | Equipment above [amount] or non-standard hardware | [Finance] | Spend control |
| A3 | Salary or contract variation before start | [Hiring Manager] with [People Operations Partner] | Changes the executed contract |
| A4 | Any adverse decision: withdrawal, non-confirmation, extension | [Legal / HR Advisor] | Employment decisions about an individual must have a named accountable human |

## Output

- A compliant employee record with contract, eligibility check and payroll
  enrolment complete.
- Access granted exactly to the approved bundle, verified on day one.
- Equipment issued and recorded against the asset register.
- Completed day-30 and day-90 reviews with recorded outcomes.

## SLA / KPI

- Accounts and equipment ready before [09:00] on day one: target [100%].
- Right-to-work check completed within the jurisdictional deadline: [100%].
- First payslip correct: target [100%]; every miss is reviewed, not averaged.
- Day-90 review completed within [7] days of the date: target [95%].

## Audit record

Retain per the rules for your jurisdiction and role. In the United States, the
EEOC requires personnel and employment records — including application forms,
whether or not the applicant was hired — to be kept for at least one year, with
longer retention once a charge is filed and separate rules for payroll records;
see the
[EEOC recordkeeping requirements](https://www.eeoc.gov/employers/recordkeeping-requirements).
Keep eligibility documents, screening consents and results, and pay data in the
restricted store, separated from the general HR record, with access logged.

> Simulated example data
>
> Joiner [A. Okonjo] · role [Operations Analyst] · start [2026-09-01] ·
> right-to-work check completed [2026-08-28] by [People Operations Partner] ·
> D3 → no screening (role has no financial authority and no special-category
> data access) · D1 → bundle [ops-analyst-base] approved by [Hiring Manager] on
> [2026-08-24]; one out-of-bundle request for [reporting-admin] raised as E4 and
> declined · payroll cut-off [2026-08-20] passed, so joiner informed on
> [2026-08-25] that the first payslip covers one month in arrears.

## Revision log

| Version | Date | Author | Change |
| --- | --- | --- | --- |
| v1.0 | 2026-07-24 | [Your name] | initial draft |