Skip to main content
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: 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.