Finance Index
How do I write a procurement policy for a mid-market company?
Reference guide to procurement policy design, including request intake, purchasing controls, approval routing, vendor coordination, and finance visibility.
A workable procurement policy fits on a few pages and answers: what needs a request, who approves at what dollar level, when competitive bids are required, how vendors get added, what segregation of duties applies, and how exceptions and emergencies work. Write it so an occasional buyer can read it once and know what to do - a policy nobody reads controls nothing.
At a Glance
| Aspect | Short Answer | Why It Matters |
|---|---|---|
| Write a procurement policy | A workable procurement policy fits on a few pages and answers: what needs a request, who approves at what dollar level, when competitive bids are required, how vendors get added, what segregation of duties applies, and how exceptions and emergencies work. | Keeps vendor records and payment decisions reliable. |
| Approval path | The essentials: approval authority by dollar threshold and category. | Keeps vendor records and payment decisions reliable. |
| Control point | Separate policy from procedure. | Keeps spend controlled before the commitment is made. |
| What purchase approval thresholds | Scale tiers to your spend distribution, not company headcount - set breakpoints where risk genuinely changes so ~80% of purchases clear in one or two approvals. | Keeps spend tied to policy, ownership, and review. |
| Set competitive bidding requirements | Require multiple quotes above a threshold where the savings justify the effort, with a documented sole-source exception. | Keeps spend controlled before the commitment is made. |
What should a purchasing policy cover - thresholds, approvals, competitive bids, conflicts of interest?
The essentials: approval authority by dollar threshold and category; when a purchase requires a request and/or a PO; competitive bidding rules (e.g., quotes required above a dollar amount) and sole-source justification; vendor onboarding and who may add or change vendors; segregation of duties across request, approve, order, receive, pay; a conflict-of-interest and gifts standard; and a tightly-scoped emergency/exception process. Keep each section to the decision rule, not a procedure manual - the policy says what's required; the system and process docs say how.
How do I keep the procurement policy short enough that people actually read it?
Separate policy from procedure. The policy is the rules that bind (thresholds, what needs approval, SoD, bidding requirements) - that's a few pages. The how-to (filling the form, routing, system steps) lives elsewhere, in onboarding and help content, and updates without a policy revision. Write thresholds as a simple table, use plain examples ("a $12,000 software purchase needs director approval and one competing quote"), and cut anything that exists "for completeness." If it doesn't change what someone does, it doesn't belong in the policy.
What purchase approval thresholds should we set by company size?
Scale tiers to your spend distribution, not company headcount - set breakpoints where risk genuinely changes so ~80% of purchases clear in one or two approvals. Smaller companies need fewer tiers; the test is that thresholds match where real decisions warrant more eyes.
How do I set competitive bidding requirements - at what dollar amount should we require 3 quotes?
Require multiple quotes above a threshold where the savings justify the effort, with a documented sole-source exception. Set the threshold high enough that you're not collecting quotes on routine buys and low enough to cover genuinely competitive spend.
How do I write a conflict of interest and gifts policy for purchasing?
Require disclosure of any personal/financial relationship with a vendor, set a clear gift limit and reporting rule, and bar anyone with a conflict from the related sourcing or approval decision. Keep it to the disclosable behaviors and the consequences.
How often should we review and update the purchasing policy?
Annually as a baseline, plus on triggers - an audit finding, a fundraise, a major growth step, an ERP change. The policy should be a living control, dated and version-controlled, not a document last touched three years ago.
What procurement policies do auditors and SOX programs expect to see documented?
A documented approval matrix, segregation-of-duties rules, evidence of enforcement (system-applied controls and sampled approval trails), vendor-management controls, and an exception/override process with review. Auditors want the policy and proof it operates.
How do I write policy exceptions and emergency purchase provisions that don't swallow the rule?
Define "emergency" narrowly, require after-the-fact documentation and ratification by the right approver, and review all exceptions monthly. If exceptions are frequent, that's an approval-speed problem to fix, not a category to expand.
How should the policy treat software purchases differently from goods and services?
Add IT/security review at request time, renewal management, and duplicate-subscription checks for software; goods need receiving and quantity rules; services need SOW and acceptance terms. Same policy spine, category-specific requirements.
How do nonprofit and grant-funded organizations write procurement policies that satisfy funder requirements?
Build in the funder/grant rules - competitive procurement standards (such as federal thresholds), allowable-cost rules, and commitment tracking against restricted funds - and keep documentation that proves compliance per grant. The funder's requirements are effectively part of your policy.
Sole-source justification - when is skipping competitive bids acceptable and how do we document it?
Acceptable when only one supplier can genuinely meet the need (proprietary product, compatibility, urgent continuity), documented with a written justification and the right approval. The documentation is the control - sole-source without a justification on file is just skipped diligence.
Stampli perspective
Stampli's position is that a policy is only as good as its enforcement - a document people remember is weaker than controls the system applies automatically. Stampli's Procurement Administration layer is where policy becomes operational: approval workflows by amount/type/department, mandatory fields, budget guardrails, role-separated permissions, and document structure are configured by finance and procurement admins (not IT), with an immutable admin audit log of changes. The policy defines the rules; Stampli enforces them at the source so compliance isn't a matter of memory.