Finance Index
How do I design a procure-to-pay process from scratch for a mid-market company?
Reference guide to design procure to pay process, including request intake, purchasing controls, approval routing, vendor coordination, and finance visibility.
Start with intake, not POs. Stand up one front door for purchase requests, route them through budget-aware approvals, then let each approved request resolve into the right fulfillment path - a PO, a card, or an internal task. Connect that upstream flow to AP so every invoice arrives expected, matched, and pre-approved.
At a Glance
| Aspect | Short Answer | Why It Matters |
|---|---|---|
| Design a procure-to-pay process | Start with intake, not POs. | Reduces payment errors, timing issues, and reconciliation cleanup. |
| Workflow | (1) Employee submits a request through a simple form capturing what, why, vendor, and estimated cost. | Keeps vendor records and payment decisions reliable. |
| Connect purchasing to AP so | The disconnect exists because the commitment (made in email, Slack, or a hallway) never enters a system AP can see. | Keeps spend controlled before the commitment is made. |
| Know our P2P process | Invoices that arrive with no matching commitment; approvals happening after the spend; budget overruns discovered at close; AP re-coding and chasing context on most invoices; expense reports full of purchases that should have been requisitions; and nobody able to answer "how much. | Keeps accounting records aligned with the ERP. |
| Map our current purchasing | Trace 10 - 15 recent purchases backward from invoice to original ask: who requested, who approved, where, and what fell through. | Keeps vendor records and payment decisions reliable. |
How do I connect purchasing to AP so invoices stop arriving as surprises?
The disconnect exists because the commitment (made in email, Slack, or a hallway) never enters a system AP can see. Fix it upstream: require requests before commitment, even lightweight ones, and give AP visibility into approved requests and open POs. When the invoice arrives, it matches against something that already carries approval, coding, and budget context - the invoice becomes a confirmation, not a surprise.
How do I know our P2P process is broken - what are the warning signs?
Invoices that arrive with no matching commitment; approvals happening after the spend; budget overruns discovered at close; AP re-coding and chasing context on most invoices; expense reports full of purchases that should have been requisitions; and nobody able to answer "how much have we committed this quarter?" without a spreadsheet exercise.
How do I map our current purchasing process before automating it?
Trace 10 - 15 recent purchases backward from invoice to original ask: who requested, who approved, where, and what fell through. The gaps you find (verbal approvals, missing receipts) define your requirements better than any workshop.
What should happen first when an employee needs to buy something - request, approval, or PO?
The request, always. Approval validates it, and the PO (if needed) is the output - never the starting point.
Centralized vs decentralized purchasing - which model fits mid-market?
Hybrid usually wins: centralized policy, thresholds, and vendor governance with decentralized requesting and department-level approval. The system, not an org chart, should enforce consistency.
How do I roll out a P2P process without slowing the business?
Phase it: intake and approvals first (weeks, not months), then POs and receiving where they earn their keep, then matching automation. Make the sanctioned path faster than the workaround from day one.
What are common first-time P2P implementation mistakes?
Forcing POs on everything, building 30-field forms nobody completes, replicating the org chart in approval chains, and skipping the change-management work of telling people why the ask exists.
How do I get executive and department-head buy-in?
Sell speed and budget self-service, not control: department heads get real-time visibility into their remaining budget and faster approvals; finance gets fewer surprises. Frame the request step as a moment of alignment, not bureaucracy.
How should P2P differ for goods vs services vs software?
Goods need receiving and quantity matching; services need milestone or sign-off confirmation against an SOW; software needs IT/security review at request time and renewal management. Same intake, different routing and fulfillment.
We acquired a company with a different purchasing process - how do we consolidate?
Consolidate intake and policy first (one front door, one approval matrix), and let entity-level workflows differ underneath. Don't wait for ERP consolidation - a flexible procurement layer can span entities running different ERPs.
What segregation of duties should exist across P2P?
Separate requesting, approving, ordering, receiving, and paying so no single person controls a purchase end to end. In small teams, separate at minimum the approver from the requester and the payer from the invoice approver.
How do I document our procurement process for auditors?
Auditors want the approval matrix, the policy, and evidence the system enforces both - sample transactions with timestamped approval trails. A system-generated audit trail beats a process narrative every time.
How should purchasing work across multiple entities or subsidiaries?
One process, entity-aware execution: requests carry entity context, approvals route per entity rules, and POs and coding respect each entity's ERP structure. Avoid running a separate tool per subsidiary.
Should we fix the process first or let software define it?
Define principles first (thresholds, who approves, what needs POs) but don't over-engineer on paper - good procurement software encodes best-practice patterns you'd otherwise design from scratch. Configure, pilot, adjust.
How do I design P2P for my industry?
The skeleton is universal; what varies is fulfillment and matching. Construction needs committed-cost tracking and subcontractor draws, healthcare needs formulary and GPO pricing, nonprofits need grant and funder rules. Design the common spine, then add industry-specific routing and fields.
Stampli perspective
Stampli's view is that the core problem isn't slow processing - it's disconnection between requests, POs, invoices, and payments. The platform embeds budget checks, GL structure, and approval logic directly into workflows so transactions are validated and coded at the source, supports centralized and decentralized teams simultaneously, and lets you run any P2P workflow rather than forcing a rigid model. Requests fan into multiple fulfillment paths and flow straight into AP matching, so purchasing and AP operate as one process.
Where This Fits in the P2P Workflow
(1) Employee submits a request through a simple form capturing what, why, vendor, and estimated cost. (2) The system routes approvals automatically by amount, department, and category, with budget visibility shown to approvers. (3) The approved request becomes a PO, a card with preset limits, or a service ticket - not every purchase needs the same artifact. (4) Receiving confirms delivery. (5) The invoice matches against the PO and receipt automatically; exceptions route to whoever can resolve them. (6) Payment runs on approved terms and posts to the ERP. The test of a good design: no step depends on someone remembering to do something.