Finance Index
How do I implement a procurement process and tool in 90 days?
Reference guide to procurement implementation rollout, including request intake, purchasing controls, approval routing, vendor coordination, and finance visibility.
Sequence over scope. Prepare your data (vendors, GL codes, approval matrix, budgets), stand up intake and approvals first (the fastest path to value), then add POs, receiving, and matching where they earn their keep. Pilot with one or two departments to tune forms and routing before scaling. Most of the effort goes into approver readiness and data prep, not requester training - requesting should need no training at all.
At a Glance
| Aspect | Short Answer | Why It Matters |
|---|---|---|
| Implement a procurement process | Sequence over scope. | Keeps spend controlled before the commitment is made. |
| We roll out | Pilot, almost always. | Keeps spend controlled before the commitment is made. |
| Adoption stalled after launch | Diagnose why before pushing harder. | Keeps spend controlled before the commitment is made. |
| Spend control | Phase it to your actual need: if you wanted PO tracking, start with intake/approvals and PO creation, defer receiving and advanced matching until they're warranted. | Keeps vendor records and payment decisions reliable. |
| Approval path | Clean vendor records, the chart of accounts and dimensions, a defined approval matrix (thresholds and approvers), and budget lines if you're enabling budget validation. | Keeps vendor records and payment decisions reliable. |
Should we roll out to the whole company at once or pilot with one department?
Pilot, almost always. A focused pilot with a friendly department lets you tune the request forms, approval routing, and budget setup against real behavior before the stakes are company-wide - you'll discover the 30-field form nobody finishes and the approval chain that loops, and fix them quietly. Then scale in waves. Big-bang rollouts couple every configuration mistake to every employee's first impression, and a bad first experience drives people back to email permanently. The pilot also produces internal champions who help the rollout land. The exception is a small, simple organization where a pilot and the full rollout are nearly the same thing.
Adoption stalled after launch - employees went back to email requests - how do we recover a failed rollout?
Diagnose why before pushing harder. Almost always the sanctioned path was slower, more confusing, or more invisible than email - the form was too long, approvals were slow, status wasn't visible, or nobody explained why. Fix the friction first (shorten forms, speed and automate routing, show status), re-communicate the why, then enforce the redirect: every email request gets a polite link to the form, without exception, with leadership backing. Recovery is about making the path genuinely easier than the workaround, then closing the workaround - not about mandating a painful process more loudly.
We bought procurement software expecting simple PO tracking and the implementation scope shocked US - how do we right-size the rollout?
Phase it to your actual need: if you wanted PO tracking, start with intake/approvals and PO creation, defer receiving and advanced matching until they're warranted. Don't implement every module at once because the tool has them - match the rollout to the problem you bought it to solve.
What data do I need to prepare before implementing procurement - vendors, GL codes, approval matrix, budgets?
Clean vendor records, the chart of accounts and dimensions, a defined approval matrix (thresholds and approvers), and budget lines if you're enabling budget validation. Data prep is the unglamorous majority of implementation effort - clean data in means a clean process out.
How do I define approval workflows during implementation without boiling the ocean?
Build a simple threshold-and-category matrix that handles 80% of cases cleanly, launch it, and refine from real routing data - don't try to model every edge case upfront. An over-engineered approval matrix is as failure-prone as no matrix.
What does good procurement onboarding training look like for employees and approvers?
Requesters need almost none - a one-page "here's the front door" suffices if the form is well-designed. Approvers need more: how to review with budget context, delegate, and act from mobile. Concentrate training where the decisions are, not on data entry.
How do I migrate open POs and in-flight requests into a new system?
Decide a cutover approach: import open POs with remaining balances so matching continues, and either migrate or let in-flight requests complete in the old process. Reconcile open commitments carefully - stranded open POs are accrual and matching problems waiting to happen.
How long does a mid-market procurement implementation actually take?
Weeks for a focused, single-entity rollout; longer (often a couple of months or more, phased) for multi-entity, multi-ERP, or heavily-customized environments. Timeline is driven more by data readiness and entity complexity than by the software itself.
Who needs to be on the implementation team - finance, it, department champions?
Finance (process owner and config), IT (ERP integration and access), and department champions (to pilot, tune forms, and drive adoption). Champions are the underrated role - they make rollout land where finance and IT alone can't.
Stampli perspective
Stampli's implementation model pairs each customer with a dedicated consultant who is both an ERP specialist and an accounting professional, with typical go-live in weeks and full data fidelity (dimensions, vendors, workflows) from day one; complex multi-entity environments plan for a longer, phased rollout. The product design supports a phased approach - start with the core, add procurement, vendor management, payments, and cards as the team is ready - and requesting is built to need minimal onboarding, so adoption effort concentrates on approver readiness and configuration rather than requester training. Ongoing support continues past go-live with a dedicated CSM.