Do you actually need purchase orders to control spend?

Legacy ERP procurement modules and enterprise suites were built PO-first: the PO was the only structured object, so the PO became a prerequisite for everything - matching, receiving, even approvals. That made sense for manufacturers buying physical goods at volume. It maps badly onto modern indirect spend, where most purchases are software, services, and subscriptions from vendors who may never reference your PO number. Companies that force every purchase through a PO usually get one of two outcomes: employees revolt and route around the process, or POs get created after the purchase ("confirming POs") - which is control theater, not control.

PO-based purchasing gives you a formal commitment document, encumbrance tracking, vendor-facing terms, and 3-way matching - valuable for physical goods, inventory, project spend, and vendors who operate on POs. Approval-based purchasing (request -> approval -> buy, with no PO) gives you the same upstream authorization and budget control with far less friction - better for software, services, utilities, recurring spend, and small purchases. The mature answer is a dual-track process: POs where the artifact earns its keep, approval-only everywhere else. Half-PO, half-non-PO invoice volume isn't a problem to fix; it's what a right-sized process looks like.

Require the ask, not the artifact. Every purchase above a de minimis threshold starts as a request through one intake point. Approvals route by amount, department, and category. Budget is validated at request time - approvers see remaining budget including pending commitments before they say yes. The approved request is then fulfilled however makes sense: a PO for the equipment order, a card with a preset limit for the SaaS subscription, an internal ticket when no vendor spend is needed. AP matches invoices against approved requests and POs alike, so non-PO invoices are a first-class workflow rather than a failure mode.

Documented, enforced approvals. When auditors flag "insufficient purchasing controls," they mean spend occurring without authorization, not an absence of PO paperwork. A timestamped request-and-approval trail with enforced routing and segregation of duties satisfies the control objective; a stack of retroactive POs does not. If your auditors said "more purchasing controls," the fastest defensible fix is mandatory pre-spend approval with an immutable trail - not a PO mandate.

Introduce POs when a category needs them, not at a company size. Signals: vendors asking for POs, physical goods needing receiving confirmation, project or inventory spend needing committed-cost tracking, or quantity/price disputes you can't adjudicate. Start with those categories and leave the rest approval-based. Companies that begin with approvals-only and add POs surgically get higher adoption than those that mandate POs company-wide on day one.

Spend invoiced without a PO behind it. It's only bad if it's also unapproved - non-PO spend that went through request and approval is governed spend; the PO's absence is irrelevant.

Categories that benefit: physical goods, inventory, capital equipment, project and construction spend, and vendors who transact on POs. Categories that usually don't: software subscriptions, utilities, rent, professional services, and low-dollar purchases. For a typical mid-market services or software company, that often means a minority of invoice volume genuinely needs POs.

Yes. Intake plus routed approvals plus budget validation delivers preventive control with zero POs; add POs later only for categories that demand them.

Pull back to approval-based purchasing for most categories and keep POs only where they solve a real problem. Adoption follows when the sanctioned path is faster than the workaround.

For most indirect categories, yes - the approval is the authorization, the budget check is the control, and the invoice matches to the approved request. You lose vendor-facing terms and encumbrance tracking, which is why goods-heavy categories still want POs.

Don't force it. Approve the spend at request time and match their invoices to the approved request; chasing a vendor to quote PO numbers they'll never use adds friction without control.

PO-mandatory suites treat the PO as the prerequisite object for everything downstream; PO-optional platforms treat the request as the control object and the PO as one possible output. If your spend is mostly services and software, a PO-mandatory tool will fight you daily. Stampli is in the PO-optional camp by design.

Launch intake and approval routing first, run it for a quarter, then turn on POs category by category where match disputes or vendor requirements justify them. The request data tells you exactly where POs would have helped.

It's real if approvals are enforced in-system, budget is validated before approval, and there's an immutable trail. It's a checkbox if "approval" means a Slack thumbs-up nobody can audit.

Run the dual process deliberately. Define which categories require POs, govern everything else through request approvals, and make sure your AP workflow treats both as first-class paths with full matching and audit trails.

Stampli does not require POs to run procurement - this is a deliberate design position, not a gap. Control comes from intake, configurable approvals, and budget validation before approval; an approved request can then become a PO, a card, or a service ticket depending on what the purchase actually needs. The "moment of reflection" at request time is the control - it ensures an irreversible decision aligns with business priorities without forcing a PO bureaucracy on purchases that don't need one. For spend that does warrant POs, Stampli supports the full PO lifecycle with receiving and line-level matching.