# Why procurement governance matters

An Atlas Corporate APAC buyer assembles a 180-line requisition worth AUD 92,000 and is ready to submit. In a consumer purchase, that is the end of the story: the shopper decides, the shopper pays. In B2B, it is the start of a second story. Who is allowed to commit that spend? Does it need a manager's sign-off, a second approver above a threshold, or a compliance check first? Procurement governance answers those questions, and you can configure it directly on the platform rather than bolting on an external workflow engine.

## The business problem: controlling who can commit spend

B2B organizations delegate purchasing to many people but rarely delegate unlimited authority. Three needs recur across almost every buyer:

- **Spending thresholds.** A buyer can self-serve up to a limit; above it, someone with more authority must approve.
- **Separation of duties.** The person who raises a purchase should not be the only person who approves it. You designed Associate Roles with this split in [Configure associate access](/learning-model-b2b-commerce/configure-associate-access/associate-roles-and-permissions.md); approval workflows are where that split is enforced.
- **Departmental controls.** Different divisions, cost centers, or product categories carry different sign-off requirements.

[Approval Rules](/api/projects/approval-rules.md) and [Approval Flows](/api/projects/approval-flows.md) model all three, scoped to the Business Unit hierarchy you already designed.

## The three resources at a glance

Approval governance is built from two configuration resources and one runtime resource.

- **Approval Rule**: the policy. It states which Orders need approval (a `predicate`), which roles' Orders it applies to (`requesters`), and who must approve and in what order (`approvers`). A rule belongs to one Business Unit.
- **Approval Flow**: the runtime instance. When an Order matches an active Approval Rule, the platform creates an Approval Flow automatically to track that Order's approvals, rejections, and the parties involved.
- **Associate Role**: the currency of authority. Both the requesters and the approvers in a rule are expressed as Associate Roles, not individual people, so governance stays stable as staff change.

Approval governance evaluates **Orders**, not Carts. A rule's `predicate` is an [Order Predicate](/api/projects/predicates.md#order-predicates), and an Approval Flow references the Order it governs. The buying-committee Cart freeze you met in the previous module protects a price before checkout; an Approval Flow governs whether the resulting Order may proceed.

## Where approval sits in the purchasing flow

Approval Rules are designed once, ahead of time. The Approval Flow is created at the moment an Order is placed and matches a rule. From there, the flow moves through the rule's approver tiers until it is fully approved or a single rejection stops it.

```mermaid
flowchart TD
	A["Design time: Approval Rule<br/>predicate + requesters + approver hierarchy"] -.belongs to.-> BU[Business Unit]
	B[Buyer places Order] --> C{"Order matches an<br/>active Approval Rule?"}
	C -->|No| D[Order proceeds]
	C -->|Yes| E[Platform creates Approval Flow]
	E --> F[Approvers act tier by tier]
	F -->|All tiers approve| G[Order approved]
	F -->|Any rejection| H[Order rejected]
```

The next pages build each piece in turn: the rule's predicate and requesters, the approver hierarchy, the flow at runtime, and how rules inherit across a Business Unit hierarchy.

## Key takeaways

- B2B purchasing needs governance for spending thresholds, separation of duties, and departmental controls; you configure it natively.
- An **Approval Rule** is the policy (predicate, requesters, approver hierarchy); an **Approval Flow** is the runtime instance the platform creates when an Order matches a rule.
- Both requesters and approvers are expressed as **Associate Roles**, so governance is role-based and survives staff changes.
- Approval governance acts on **Orders**: rules use Order Predicates, and a flow references the Order it governs.

## Related pages

- [Area overview page with navigation](/learning-model-b2b-commerce.md)
- [Previous page: Overview](/learning-model-b2b-commerce/configure-approval-workflows/overview.md)
- [Next page: Approval Rules: predicates and requesters](/learning-model-b2b-commerce/configure-approval-workflows/approval-rules-predicates-and-requesters.md)