Every S2P program promises control, but only a few sustain it. The difference is whether policy becomes daily behavior with defensible evidence. Compliance is not a document repository or a set of training slides. It is a system of decisions: who is allowed to commit spending, under what conditions, through which channels, and with what proof.
This chapter shows how to design an enforceable policy framework, how to prevent and detect maverick spending without creating a bureaucracy the business routes around, how to be audit-ready by design, and how to manage exceptions so they remain rare, governed, and visible.
19.1 Policy Framework Design
Policy framework: the minimum set of rules, thresholds, and controls that governs how the organization sources, buys, and pays. A good framework is short, consistent, and executable in workflow.
Start with a simple hierarchy that mirrors the S2P lifecycle. In most organizations, five pillars are enough: delegation of authority, sourcing and competitive bidding, contracting, supplier onboarding, and invoice/payment controls. Each pillar should be written so a non-procurement manager can explain it in a sentence. If it takes a paragraph to describe a rule, it will be misunderstood and “fixed” with exceptions.
Delegation of authority: define who can approve commitments at different thresholds and for different risk classes. DoA is not only for requisitions. It must cover contracts, purchase orders, change orders, invoice exceptions, and urgent payments. The fastest way to break compliance is to enforce approvals in one object and allow a loophole in another.
Sourcing thresholds: define when competitive bids are required, when procurement must be involved, and what constitutes an acceptable single-source justification. Tie thresholds to both value and risk. A low-dollar purchase can be high-risk if it involves regulated work, data access, or site safety exposure.
Contracting standards: define when a contract is mandatory, which templates must be used, and which clause deviations require legal review. Policy should also define the “no contract, no order” categories where the business cannot proceed until terms are executed.
Supplier onboarding rules: define when new suppliers are allowed, what qualification tiers exist, and which checks are mandatory by supplier type. Make supplier creation a controlled workflow, not an email request to “set up a vendor,” and explicitly protect bank and tax updates with verification controls.
Invoice and payment controls: define match policy by category, what non-PO invoices are allowed, who can override tolerances, and what evidence is required for exceptions. Policy must also define required invoice references and escalation for repeated supplier noncompliance.
Once pillars are defined, translate them into system-enforceable rules: workflow routing, mandatory fields, blocking controls, and audit logs. The most useful artifact is a policy-to-control map: each policy statement links to the enforcing control, the owner, and the evidence the system produces. This prevents “policy drift” after go-live and accelerates internal audit alignment.
Make the framework usable by expressing rules as simple “if/then” logic that can be configured and tested. Example: if a commitment exceeds a threshold or a category is regulated, then require procurement review and competitive bidding steps. If a supplier is unqualified, block ordering and route to onboarding. Provide a one-page “how to buy” guide per role.
Design policy so it can scale globally. Use a global default with a small number of regional variations required by law or regulation. Avoid “preferences” becoming permanent exceptions. If a region wants different thresholds or controls, require a business case, quantify control impact, and set an expiry date so the exception is revisited.
Finally, define how policies are changed. Establish a small policy council: procurement, finance, legal, compliance, and IT, meeting monthly to approve changes and review exception patterns. Maintain a decision log so the organization can apply rulings consistently.
- Policy-to-control map: policy statement, control objective, enforcing behavior, owner, evidence location.
- Decision rights: who can approve exceptions, change thresholds, and grant temporary delegations.
- Versioning: effective dates, change log, and communication to impacted roles.
19.2 Preventing and Detecting Maverick Spend
Maverick spend: purchases made outside approved processes, suppliers, or contracts. It is often a rational response to friction, so prevention must combine experience design, clear channels, and targeted enforcement. If compliance depends on people choosing the “right” path under time pressure, compliance will fail.
Prevention begins with channel clarity. Users need to know where to go for common needs, and the compliant path must be faster than the workaround. Catalogs, preferred suppliers, and simple request forms are compliance infrastructure. When the system reduces steps for low-risk buying, it earns the right to be stricter where risk and value are higher.
Use layered enforcement. Steering controls: make preferred suppliers and contracted items the default in search and guided buying. Soft stops: require justification when users choose a nonpreferred option, creating data for targeted fixes. Hard stops: block high-risk behaviors once readiness is proven, such as preventing invoices without POs for addressable categories or preventing purchases from unqualified suppliers. Deploy hard stops in phases, tied to readiness metrics such as catalog coverage and supplier enablement.
Reduce “invoice-only buying” deliberately. Non-PO invoices are expensive and weakly controlled. Classify which invoice-only categories are truly required, then remove the rest through policy and channel redesign. Require business owner approval and coding standards for any remaining invoice-only invoices, and report volumes by business unit so leaders can intervene.
Cards are another common bypass channel. Treat cards as a governed spend source: define allowable categories, require receipts, and analyze card transactions to identify repeat patterns that should move into catalogs or contracts. Pair enforcement with a better alternative, or card policy will be ignored.
Do not ignore supplier-side behavior. Suppliers can enable maverick spend by accepting email orders, shipping without POs, or invoicing without required references. Reinforce expectations in contracts and on POs. For high-volume suppliers, track PO reference compliance and address chronic issues in supplier reviews.
Detection relies on data signals and a small set of repeatable analyses. Start with three core views. Spend outside preferred suppliers: spend in categories with contracted suppliers that are purchased elsewhere. Spend without a PO: invoice value not linked to approved orders. Threshold avoidance: split transactions that appear designed to stay below approval or bidding thresholds. These views capture most maverick behavior in a way leaders can understand.
Make maverick spend visible to the right owners. Provide monthly dashboards by business unit showing channel usage, non-PO invoice rate, off-contract spend, and exception reasons. Review them with leaders, not just procurement. Compliance is a management issue; procurement cannot “police” its way to sustained behavior change.
Build a pragmatic response model. Not every noncompliant transaction needs escalation. Use a tiered approach: education for first-time or low-value issues, targeted coaching for repeat patterns, and enforced controls for chronic or high-risk behavior. Use objective evidence from the system to keep interventions credible.
- Leading indicators: rising non-PO invoices, increasing off-contract spend, and approval bypass attempts.
- Detection queries: split transactions near thresholds, suppliers created without onboarding evidence, repeated urgent payments.
- Response tiers: educate, coach, enforce, and escalate, with clear triggers for each tier.
19.3 Audit Readiness
Audit readiness: the ability to demonstrate, at any time, that spend was authorized, controls operated as designed, and evidence is retrievable without reconstructing it from emails. The mindset is “audit by design,” not “audit after the fact.”
Begin with a control design matrix aligned to key risks: unauthorized spend, supplier master abuse and fraud, overpayment, contract leakage, and regulatory noncompliance. For each risk, define the control objective, the control mechanism (preventive or detective), the control owner, and the evidence produced. Evidence should be generated automatically where possible: approval logs, change histories, match results, exception reason codes, and supplier master change records.
Segregation of duties is the control most often weakened during implementation “to get things done.” Separate at least three capabilities: changing pay-critical supplier data, approving invoices or exceptions, and releasing payments. Also restrict who can change match tolerances and who can override controls. If you must grant temporary elevated access during cutover or hypercare, time-box it and document it with approvals and an access review plan.
Audit readiness also depends on retention and traceability. Define retention periods for contracts, approvals, invoices, and supporting documents, aligned with legal requirements. Preserve end-to-end linkage: sourcing event to contract, contract to PO or catalog, PO to receipt, receipt to invoice, invoice to payment. Missing links are where audits turn into forensic exercises.
Create a standard audit evidence package for high-risk controls so teams are not improvising. Include: current DoA tables, a role-to-permission matrix for sensitive actions, samples of bank-change cases with verification evidence, samples of invoice overrides with approvals, and reconciliation reports tying S2P totals to ERP postings. Refresh quarterly.
Test controls with real scenarios. In user acceptance testing, include audit walkthroughs such as: create a supplier and change bank details; approve a high-value requisition with correct DoA; change a PO price after approval; process a price-variance invoice; execute an urgent payment; and block a supplier due to a compliance issue. For each, verify evidence quality: logs, approvals, timestamps, and access rights.
Operationalize audit readiness after go-live. Establish monthly routines: sample supplier master changes, review tolerance overrides, reconcile invoice totals to finance postings, and review exception aging. When the business can show routine monitoring, audit becomes confirmation rather than discovery.
- Control design matrix: risk, objective, control, owner, frequency, evidence location.
- Access reviews: quarterly review of sensitive roles and temporary elevated access.
- Monitoring routines: supplier changes, overrides, reconciliations, and aging reviewed on cadence.
Document the monitoring routines and assign backups so controls persist.
19.4 Exception Management
Exceptions: deliberate departures from standard policy or process, approved through a governed path. Exceptions are how the organization keeps operating when reality does not fit the standard. The failure mode is when exceptions become frequent, invisible, and permanent.
Design exceptions as a small number of controlled types with standard reason codes and time limits. Examples include single-source justification, urgent buy, supplier not yet onboarded, invoice without PO for an approved category, and tolerance override. Each exception type should have a default approver, an escalation path, and required evidence. Evidence prevents exceptions from becoming “because I said so.”
Force clarity at the moment of exception. Require a reason code, a short justification, and supporting attachments where needed. Route exceptions to the correct authority based on value and risk. For higher-risk exceptions, require dual approval (for example, procurement plus finance or legal) to protect both control posture and commercial integrity.
Time-bound exceptions are essential. A single-source justification may be valid for a defined period or project, not forever. A tolerance override should be permitted once for a specific invoice, not for all future invoices. Encode expiry into the exception record and require re-approval when expiry is reached.
Manage exceptions with a cadence and a root-cause mindset. Track exception volumes and values by type, category, supplier, and business unit. Review the top recurring exceptions monthly and assign fixes. If “urgent buys” are common, channel strategy or approval speed is broken. If “supplier not onboarded” is common, onboarding is too slow or the business is requesting new suppliers unnecessarily. If tolerance overrides are common, PO accuracy, receiving discipline, or supplier invoice quality needs attention.
Watch for “exception debt.” Repeated approvals for the same reason usually mean a missing standard process or an unrealistic rule. Treat repeats like defects: assign an owner, set a remediation date, and decide to fix the process, tighten enforcement, or revise the policy. Close the loop so exceptions fall over time.
Create an escalation ladder that the business recognizes as fair. Start with education and process repair. Then tighten controls for specific patterns, such as requiring procurement review for a category or supplier. Finally, enforce consequences for chronic noncompliance, such as blocking non-PO invoices for a business unit or disabling card usage for a category. Escalation should be data-driven and communicated in advance.
Publish exception performance alongside compliance metrics. When exceptions are visible, business owners become partners in fixing root causes instead of using exceptions as an escape hatch. Over time, the organization learns a simple rule: exceptions are allowed, but they are owned, time-bound, and reviewed.
- Exception catalog: defined types, reason codes, owners, approvals, evidence, expiry rules.
- Monitoring: volume, value, aging, and repeat patterns by business unit and supplier.
- Root-cause actions: each monthly review produces fixes with owners and due dates.
Compliance and policy enforcement becomes sustainable when it is designed as an operating system: policies are few and clear, controls are embedded in workflow, behavior is guided through easy buying channels, audit evidence is produced automatically, and exceptions remain visible and managed. That is how S2P moves from “rules on paper” to controlled spend at scale.
