> ## Documentation Index
> Fetch the complete documentation index at: https://docs.seloria.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Approvals

> Amount-based approval gates for awards, purchase orders, budgets, and unbudgeted spend — and who can approve them

Seloria enforces approval controls at the points where money is committed: when an award is decided, when a purchase order is sent, when a budget is activated, and when spend has no budget behind it. Each control is driven by a threshold your organization sets — first in the **onboarding wizard**, and at any time afterwards in **Settings** (thresholds are editable by **PM** and **Admin**).

## Who can approve

Approval authority follows your team mode:

* **Procurement Managers (PM)** are always approvers.
* **Admins** are approvers only when **SMB mode** is enabled (see below). In a hierarchical organization, the Admin manages the account but is not a procurement authority.
* **Buyers** and **Requestors** can never approve. They only see the approval requests they themselves opened, so they can track status without seeing the org-wide queue.

When rejecting, a **comment or reason is required**; when approving, it is optional. Every decision is recorded in the entity's audit history and the requester is notified in-app and by email.

## PO approval threshold

Set the **Purchase order approval threshold** in the wizard or in **Settings**. The rule:

* If the threshold is **greater than 0** and a PO's total exceeds it, the PO **cannot be sent** to the supplier until a PM approves it. The approval request is opened automatically the first time someone tries to send, and all PMs (and Admins) are notified.
* A threshold of **0 means no PO approval is required** — every PO can be sent directly.

Once approved, the buyer can send the PO normally. If rejected, sending stays blocked and the rejection (with the approver's comment) is shown on the PO.

This gate is independent from the award approval: re-awards can produce several POs that each sit under the award threshold, so the spend is checked again at the moment of issue.

A buyer can also voluntarily click **Request approval** on any draft PO that has no approval yet — useful when policy or judgment calls for a second pair of eyes even under the threshold.

## Award approval

Set the **Award approval threshold** the same way. When a buyer awards an RFQ (or RFP) and the total awarded amount exceeds the threshold:

* The RFQ stays in its current status and shows an **award pending approval** banner.
* **Generating POs is blocked** until a PM decides.
* On **approve**, the RFQ advances to **Awarded** and the buyer is notified that POs can be generated.
* On **reject** (reason required), the award is undone entirely: supplier quotes return to submitted, any budget reservation is released, and the buyer can fix and re-award.

A threshold of **0 means awards never require approval** and are confirmed immediately.

## Unbudgeted spend threshold

The **Unbudgeted spend threshold** is a separate control for awards that have **no linked budget**:

* Left **empty**, the control is off.
* Set to **0**, **any** unbudgeted award requires approval.
* Set to an amount, unbudgeted awards **above** that amount require approval.

This catches spend that would otherwise bypass budget tracking, regardless of the award threshold.

## Budget approvals

Budgets follow their own activation flow:

* Budgets are always created as **drafts** and must be **submitted** for activation.
* The **Auto-activation threshold** decides what happens on submit: budgets **at or below** the threshold activate automatically; budgets above it go to **pending approval**. Left empty (or 0), **every** budget requires approval.
* **Approving, rejecting, or closing** a budget is reserved for PMs (and Admins in SMB mode). Buyers can create and submit drafts but never activate them.

## SMB mode

**SMB mode** simplifies governance for small teams where one person wears every hat:

* It is chosen during onboarding (**Small team (SMB)** vs **Hierarchical team**) and can be changed later in **Settings**.
* Only the **Admin** can toggle it, because it governs the Admin's own authority.
* When **on**, the Admin can act as a PM for procurement decisions: approving awards, POs, and budgets.
* When **off**, only PMs hold approval authority — the recommended setup when buyers and approvers are different people.

## Approval chain by amount (bands)

A single threshold answers "does this need approval?" but not "how many people, and in what order?". For that, **Settings → Approvals** lets you define **bands by amount**, which build a sequential chain.

Bands are **cumulative**: every band whose floor the amount crosses adds one approver, and they are asked **in order**. With bands at 15k, 100k and 500k, an award of 600,000 needs three approvals, one after another — not just the top one. The next approver is only notified once the previous step is approved.

Each band's approver is either:

* **A role** — anyone holding that role (PM or Admin) can resolve the step, or
* **A named person** — only that person, which is how you put a GM or MD on the highest band.

Three templates give you a starting point, and you can edit the bands afterwards:

| Template    | Chain it creates                                                                                                                      |
| ----------- | ------------------------------------------------------------------------------------------------------------------------------------- |
| **Simple**  | No chain. Awards approve themselves, recorded as a deliberate self-approval in the audit trail. For a one-person operation.           |
| **Medium**  | Two levels: PM from 50,000 to 250,000, Admin above 250,000.                                                                           |
| **Complex** | Three levels: PM from 15,000 to 100,000, Admin from 100,000 to 500,000, Admin above 500,000 — replace the top ones with named people. |

Bands and the **dimension rules** (by project or department) work **together**, not instead of each other: an award can require the PM because of its amount *and* a specific approver because of the project it belongs to. Both steps must clear.

Bands apply to **awards** in this version. If no bands are defined, awards fall back to the classic **Award approval threshold** described above.

## Delegating approval authority

When an approver goes on leave, approvals should not stall behind them. **Settings → Approvals → Delegation** hands your authority to someone else for a defined window.

How it behaves:

* **Who can delegate** — PMs and Admins. By default you delegate *your own* authority; an Admin can also create a delegation on behalf of someone else who forgot to set one up.
* **A window, not a switch** — you pick an end date, and the delegation only applies between its start and end. Outside that window it has no effect, so authority returns on its own when you are back.
* **An optional cap** — set a maximum amount and the delegate can only resolve steps at or below it. Anything larger waits for you. Leave it empty for no limit.
* **It applies to named approvers** — a step assigned to a *specific person* is the case that needs delegation. A step defined by *role* can already be resolved by anyone holding that role, so it never blocks.
* **The record keeps both names** — the audit trail stores who approved **on behalf of** whom. The delegate's decision is never anonymous, and the original approver stays accountable.
* **You cannot delegate to yourself**, and the delegate must be an active user.
* **Revoking** takes effect immediately; existing approvals already decided are untouched.

Delegation does not bypass the segregation-of-duties rule: a delegate still cannot approve something they themselves created.

## Where approvers act

* **The Approvals page** (sidebar: **Requisitions → Approvals**) is the PM workspace. It shows counters and tabs for intakes to assign, **RFQs to approve**, and **POs to approve**, each with one-click **Approve** / **Reject** actions and a comment dialog.
* **Entity detail pages** — award approvals are decided directly from the award banner on the RFQ detail page, PO approvals from the banner on the PO detail page, and budget approvals from the budget detail page.
* **The dashboard** shows PMs and Admins a banner with the number of pending approvals and a shortcut to the queue.
* **Notifications and email** — approvers are notified in-app and by email when something needs their decision, with a link straight to the item; requesters are notified of the outcome the same way.