Purchase orders and approvals

The purchase order is the workspace's binding authorization to a supplier + the anchor for everything that follows: the receipt that creates inventory or expense, the invoice that creates the payable, the payment that settles the obligation. The full arc is requisition → approval → PO → receipt → invoice → payment, each step gated by controls. This page walks the arc — including the approval ladder, the 3-way match, and the common exceptions.

TL;DR — Requesters open Procurement → Request a purchase. Approvers see items in their Approvals inbox. Once approved, the PO transmits to the supplier; receipts come in via Inventory → Receipts; the supplier invoices via the Supplier portal or directly to AP; matched invoices route to Payment release.

Before you start

• Requesters need an active employee record with a default cost center. Procurement defaults can be customized per workspace.
• The supplier must be active (see Vendor onboarding). Drafts cannot be transacted against.
• For competitive-bid categories, a completed sourcing event may be required before raising a PO. See RFQ + sourcing events.

Raise a requisition (requester path)

1. 1

   Open Procurement → Request a purchase

   The requisition form opens.

2. 2

   Pick the spend category

   Office supplies / IT equipment / professional services / capital / etc. The category drives the GL coding + the approval ladder.

3. 3

   Add lines

   Each line: item (from catalog or free-form) + quantity + expected unit price + requested vendor (optional — buyer may override). Catalog items pre-fill from preferred-supplier

   • last-paid-price.
4. 4

   Justify the spend

   Free-text business justification. For higher-tier approvers this is what they read first; specific beats generic.

5. 5

   Submit

   Requisition status → Pending approval. The first approver in the ladder receives the notification.

The approval ladder

Approval is tiered by amount and may also gate on category.

Approvers see the requisition in their Approvals inbox. Decisions are approve / reject (with note) / request-clarification (routes back to the requester). Approvers cannot approve their own spend.

PO creation + transmission

1. 1

   On final approval, the requisition becomes a PO

   A PO number is assigned + the PO is staged in Drafts (for buyer review).

2. 2

   Buyer reviews the PO

   Verify supplier + line items + terms + delivery instructions. The buyer can negotiate (the supplier may not match the requester's expected unit price) + record the agreed pricing.

3. 3

   Transmit to the supplier

   Electronically (supplier portal, EDI, or email PDF). The transmission timestamp is the order date.

4. 4

   Supplier acknowledges

   Suppliers with portal access confirm acceptance + expected delivery date. Non-portal suppliers acknowledge via return-email tracked at the PO level.

PO changes after transmission

Most workspaces allow some changes (delivery date, ship-to, quantity within tolerance) without re-approval; price increases above tolerance + scope expansions re-enter the approval ladder.

3-way match

The 3-way match is the workspace's primary spend control. AP cannot pay an invoice unless the three legs reconcile:

Matched invoices route to Payment release. Unmatched route to AP for resolution — the most common reasons are over-billing (quantity invoiced exceeds receipt), price variance (supplier billed at a different price than the PO), and missing receipt (invoice arrived before receipt posted).

Service POs (no inventory receipt)

For services, the receipt is a confirmation that the service was rendered, not a physical-goods receipt. Service POs default to either a milestone receipt (per deliverable) or a periodic receipt (per month / billing cycle).

1. 1

   Service is rendered

   Engaging department's contact confirms completion.

2. 2

   Receipt is posted via "Confirm service"

   On the PO, click Confirm service. The receipt records the rendered quantity (hours / deliverables / months).

3. 3

   Supplier invoices

   AP matches against the service receipt the same way as inventory receipts.

Every field, explained

Common gotchas

• "PO is auto-rejected because requester is the approver." Self-approval is blocked. Re-route to a peer or skip to the next approver in the ladder.
• "Supplier ships before we've raised the PO." Common in emergency procurement. Raise a retroactive PO with documented justification; AP holds the invoice until match is possible. Recurring retroactive POs are a process problem — escalate.
• "Invoice exceeds PO by 3%." Within tolerance — auto-passes the match, posts payment. Exceeding tolerance routes to manual review.
• "Multi-currency PO + currency moved between PO + invoice." The 3-way match is on PO currency; AP records the conversion at invoice posting. Significant FX movement may trigger re-approval per policy.
• "Service PO never got 'confirmed' but supplier invoiced." Common — engaging departments forget the receipt step. Workspace policy decides: AP holds for manual confirmation, or auto-confirms periodic service POs after the period closes.

Troubleshooting

How this is recorded

Every requisition, approval action, PO change, receipt, invoice match, and payment release writes to the PO's ledger. The ledger is the audit anchor for spend authorization — the artifact that proves every dollar that left the workspace went through the right approvals. Retention follows the audit-log retention FINANCE floor (default 7 years).