# Process: [Process name]

> Business process document that describes one end-to-end process: its
> purpose, scope, owner, SIPOC, process map with lanes per role, step
> table, controls, KPIs, exceptions and related processes. Based on common
> business process management (BPM) practice. Replace every `[bracketed]`
> value and every row marked *Example*.

<!--
Guidance: How to use this template
- Document the process as it actually runs today ("as-is") unless the
  document is explicitly a future design ("to-be"). Mark which one it is.
- Fill the SIPOC (section 3) before drawing the map; it fixes the start,
  end, inputs and outputs so the map does not sprawl.
- Keep the map and the step table in sync. The table is the authoritative
  detail; the map is the overview.
- Name a single process owner. A process owned by a committee is owned by
  nobody.
-->

| Field | Value |
|---|---|
| Process ID | [PR-NNN] |
| Process name | [Process name] |
| Version | [1.0] |
| State documented | [As-is / To-be] |
| Process owner | [Role, @name] |
| Author | [@name] |
| Status | [Draft / Approved / Under review] |
| Last reviewed | YYYY-MM-DD |
| Next review | YYYY-MM-DD |

## 1. Purpose

<!-- Guidance: Why the process exists and what value it delivers to its customer. One short paragraph. -->

This process [does what] so that [customer] receives [output] that
meets [quality, time or cost expectation].

*Example:* "The purchase-to-pay process turns an approved purchase need
into a paid, correctly recorded supplier invoice, so that suppliers are
paid on time and spending stays within approved budgets."

## 2. Scope and ownership

<!-- Guidance: Name the trigger that starts the process and the event that ends it. List what is excluded so readers know where adjacent processes take over. -->

- **Trigger (start)**: [event, for example "an employee raises a purchase request"]
- **End**: [event, for example "payment is posted and the invoice is closed"]
- **In scope**: [business units, locations, systems, transaction types]
- **Out of scope**: [for example, capital expenditure over 50,000, covered by PR-014]
- **Process owner**: [@name], accountable for performance, changes and this document
- **Frequency and volume**: [for example, about 1,800 purchase orders per month]

## 3. SIPOC

<!-- Guidance: Suppliers, Inputs, Process (5 to 7 high-level steps), Outputs, Customers. Keep it to one table; it is a summary, not the detail. -->

| Suppliers | Inputs | Process (high level) | Outputs | Customers |
|---|---|---|---|---|
| *Example:* Requesting employee | Purchase request | 1. Request | Approved purchase order | Requesting department |
| *Example:* Budget holder | Budget and approval | 2. Approve | Goods receipt record | Supplier |
| *Example:* Supplier | Quote, goods, invoice | 3. Order | Paid invoice | Finance (ledger) |
| *Example:* Procurement | Supplier master data | 4. Receive | Spend report | Management |
| [Supplier] | [Input] | 5. Match and pay | [Output] | [Customer] |

## 4. Process map

<!-- Guidance: Use one lane (subgraph) per role or system. Show decisions as diamonds and keep the happy path left to right or top to bottom. -->

The map below shows the main flow across the four roles involved.

```mermaid
flowchart LR
  subgraph REQ["Requester"]
    A["Raise purchase request"]
    F["Confirm goods received"]
  end
  subgraph BH["Budget holder"]
    B{"Approve?"}
  end
  subgraph PROC["Procurement"]
    C["Create purchase order"]
    D["Send PO to supplier"]
  end
  subgraph FIN["Accounts payable"]
    G{"3-way match OK?"}
    H["Schedule payment"]
    I["Resolve discrepancy"]
  end
  A --> B
  B -- No --> A
  B -- Yes --> C --> D --> F --> G
  G -- Yes --> H
  G -- No --> I --> G
```

## 5. Process steps

<!-- Guidance: One row per step. Every step needs a role, an input, an output and the system used. Add a time target where a service level applies. -->

| Step | Activity | Role | Input | Output | System | Time target |
|---|---|---|---|---|---|---|
| 1 | *Example:* Raise purchase request with supplier, amount and cost centre | Requester | Business need, quote | Purchase request | ERP | Same day |
| 2 | *Example:* Approve or reject request against budget and delegation limits | Budget holder | Purchase request | Approved request | ERP workflow | 2 working days |
| 3 | *Example:* Create purchase order using approved supplier | Procurement | Approved request | Purchase order | ERP | 1 working day |
| 4 | *Example:* Send PO and confirm delivery date | Procurement | Purchase order | Order confirmation | Email / portal | 1 working day |
| 5 | *Example:* Record goods or service receipt | Requester | Delivery | Goods receipt | ERP | On delivery |
| 6 | *Example:* Match invoice to PO and receipt | Accounts payable | Invoice, PO, receipt | Matched invoice | ERP | 3 working days |
| 7 | *Example:* Schedule payment in the next payment run | Accounts payable | Matched invoice | Payment | Banking | Per supplier terms |

## 6. Controls

<!-- Guidance: List the checks that prevent or detect errors and fraud. Each control needs a type, an owner and evidence that it ran. -->

| ID | Control | Type | Step | Owner | Evidence |
|---|---|---|---|---|---|
| CT-01 | *Example:* Approval limits enforced by workflow | Preventive, automated | 2 | Finance systems | Workflow configuration report |
| CT-02 | *Example:* Three-way match (PO, receipt, invoice) within 2% tolerance | Preventive, automated | 6 | Accounts payable | Match exception log |
| CT-03 | *Example:* Supplier bank detail changes verified by call-back | Preventive, manual | Master data | Procurement | Call-back log |
| CT-04 | *Example:* Monthly review of invoices paid without PO | Detective, manual | 7 | Finance controller | Signed review |

## 7. Key performance indicators

<!-- Guidance: Measure outcome, speed, quality and cost. Define each KPI precisely enough that two people calculate the same number. -->

| KPI | Definition | Target | Current | Frequency |
|---|---|---|---|---|
| *Example:* Cycle time | Working days from request to PO sent | 4 days or fewer | 6.2 days | Monthly |
| *Example:* First-time match rate | Invoices matched without manual intervention divided by all invoices | 85% or more | 71% | Monthly |
| *Example:* On-time payment | Invoices paid by due date divided by invoices due | 95% or more | 89% | Monthly |
| *Example:* PO compliance | Spend with a PO divided by total third-party spend | 90% or more | 82% | Quarterly |

## 8. Exceptions and escalation

<!-- Guidance: Describe the known non-standard paths and who decides. Unhandled exceptions become workarounds that never get documented. -->

| Exception | Handling | Decision owner |
|---|---|---|
| *Example:* Urgent purchase without PO | Retrospective PO within 2 days; logged for monthly review | Finance controller |
| *Example:* Invoice above PO by more than 2% | Hold invoice; requester and procurement confirm or reject the difference | Procurement lead |
| *Example:* New supplier needed | Run supplier onboarding (PR-011) before step 3 | Procurement |
| [Exception] | [Handling] | [Owner] |

## 9. Roles and responsibilities

<!-- Guidance: Summarise what each role does across the process. Match the lanes in the map. -->

| Role | Responsibilities |
|---|---|
| Requester | Raises accurate requests, confirms receipt promptly |
| Budget holder | Approves within delegation limits and budget |
| Procurement | Selects suppliers, issues POs, maintains supplier data |
| Accounts payable | Matches invoices, resolves discrepancies, schedules payment |
| Process owner | Monitors KPIs, approves changes, reviews this document |

## 10. Related processes and documents

<!-- Guidance: Link upstream and downstream processes, policies and work instructions. -->

| ID | Name | Relationship |
|---|---|---|
| PR-011 | Supplier onboarding | Upstream: provides approved suppliers |
| PR-014 | Capital expenditure approval | Alternative path above threshold |
| POL-[NNN] | Delegation of authority policy | Sets approval limits for step 2 |
| [ID] | [Name] | [Relationship] |

## 11. Change history

<!-- Guidance: Record each approved change to the process or this document. -->

| Version | Date | Author | Change |
|---|---|---|---|
| 1.0 | YYYY-MM-DD | [@name] | First documented version |
| [N.N] | YYYY-MM-DD | [@name] | [Change and reason] |

## Standard and licence note

Based on common business process management practice, including SIPOC
and swimlane process mapping. This template is original text written for
this collection. Template licence: MIT.