How do I enforce a purchasing policy in systems instead of relying on memory?

Preventive controls stop a bad outcome before it happens: required pre-spend approval, budget validation that warns or blocks, segregation of duties that prevents self-approval, mandatory PO for defined categories, vendor-onboarding gates before payment. Detective controls find problems after the fact: non-PO spend reports, exception and override logs, duplicate-payment detection, periodic control testing. A healthy program leans preventive (cheaper to stop an error than to unwind it) with detective controls as the backstop that catches what slips through and proves the preventive controls work.

Separate the five roles so no one person controls a purchase end to end - the requester can't approve their own request, the person who receives goods isn't the one who pays, the PO creator isn't the sole invoice approver. In a large team this is role assignment; on a tiny team where one person wears many hats, separate at minimum the approver from the requester and the payer from the invoice approver, and add a compensating control (an owner or external review of the combined-role person's activity). System-enforced role separation beats a policy that says "please don't."

Split the highest-risk pairs first: never let the same person both approve a purchase and pay for it, or both receive goods and approve the invoice. Where one person must wear multiple hats, add a compensating review - an owner or finance lead who reviews their combined activity periodically. Document the compensating control so auditors see the risk is managed.

Pre-spend approval enforced by the system, segregation of duties, an immutable audit trail, access controls over who can create POs and add vendors, and override/exception logging with review. SOX cares that controls are designed, operating, and evidenced - system enforcement makes all three demonstrable.

Run the lifecycle in one system that timestamps every action - request, approval, PO, receipt, match, payment - with user, document, and comment context, so the trail assembles itself. A trail stitched together from email and spreadsheets after the fact is what auditors distrust.

Documented approval matrix with system enforcement, segregation of duties, pre-spend approval, an audit trail, and vendor/access controls. Diligence and auditors will probe exactly these - having them operating (not just written) is the difference between a clean review and a finding.

Separate the permissions: vendor creation/banking changes are one role (with their own approval and verification), PO issuance another. Letting the same person add a vendor and pay it is a classic fraud and audit gap - split it structurally.

Audit your routing rules for the self-approval gap (requester = approver, or a delegation path that loops back), test it with sample transactions, and block it in the system so routing escalates past the requester automatically. Then review the override/exception log for other workarounds.

Sample transactions and trace each to a compliant approval trail; attempt a controlled bypass (a test self-approval, an over-threshold request) to confirm the system stops it; review the exception and override logs. Testing turns "we have controls" into "our controls demonstrably operate."

Stampli enforces segregation of duties by design rather than by policy document - separating invoice and payment approval, blocking self-approval through routing, and applying role-based permissions across requesting, approving, receiving, and paying. Every action lands in a complete, immutable audit trail with full context, and Procurement Administration's config layer (with its own admin audit log) is where preventive controls - approval routing, mandatory fields, budget guardrails - are set by finance, not IT. The platform's premise is that compliance built into everyday workflows is stronger than compliance asked for in a memo.