ERP buying checklist: from requirements to approval

Use an ERP buying checklist to collect evidence for a decision, not to generate a vendor score from impressions. Establish mandatory workflows, ask each supplier to demonstrate them, normalize the commercial scope, and approve a delivery plan with named owners. A useful procurement file should let a colleague understand the recommendation without attending every meeting.

Define the approval gates

Begin with a business problem and an accountable sponsor. Write the outcomes the project must deliver and the constraints it must respect, such as launch windows, team capacity, connected applications, and required controls. Separate mandatory requirements from preferences. A preference should not silently eliminate an otherwise viable proposal, while a mandatory requirement should not be traded away through a high score elsewhere.

Use gates that reflect increasing commitment: requirements approved, shortlist justified, workflows demonstrated, commercial scope normalized, delivery plan validated, and contract approved. Record the evidence needed for each gate and who can approve it. A gate is not complete because a meeting took place. It is complete when the stated question has an answer supported by the agreed evidence.

Build one decision file

File section	Minimum useful evidence	Approver
Requirements	Critical workflows and exceptions	Process owners
Product fit	Scripted demonstration results	Business and IT
Cost	Comparable multi-year ledger	Finance
Delivery	Resources, dependencies, milestones	Sponsor and project lead
Risk	Open issues and agreed responses	Relevant risk owners
Contract	Final scope and commercial documents	Authorized signatories

Keep supplier assertions separate from tested results. “Supports inventory” is an assertion. A recorded test that receives a partial order, handles a damaged item, and reconciles stock is evidence for a defined workflow. If a capability depends on an add-on, a custom extension, or a future release, record that dependency and its cost rather than marking the feature simply present.

Compare quotes on your own worksheet

Send the same scope baseline to every finalist. Ask for user tiers, required modules, implementation tasks, integration work, assumptions, recurring services, and exclusions. Record a quote version and validity date. If one vendor proposes a different architecture or phased approach, show the difference explicitly. Do not force materially different scopes into a single total and call the outcome comparable.

For an illustrative comparison, Proposal A might have $28,000 annual subscription and $40,000 delivery while Proposal B has $24,000 annual subscription and $55,000 delivery. Over three years before other costs, A is $124,000 and B is $127,000. The lower subscription does not produce the lower modeled total. These invented figures illustrate arithmetic only; neither proposal represents a real vendor or typical project.

Validate delivery capacity before signing

Ask the partner to identify the roles assigned to discovery, configuration, migration, integrations, testing, and cutover. Confirm which named people are committed and how substitutions are handled. Request a resource plan for your own team as well. Finance staff who close the books cannot automatically spend the same days mapping data and testing workflows. Capacity conflicts are project dependencies, not minor scheduling details.

Write acceptance tests before the contract is final enough to constrain them. Include expected inputs, successful outputs, exceptions, evidence, and the approving role. Agree how defects are classified and who decides that a milestone is accepted. Your legal adviser should review how those practical acceptance procedures interact with contractual payment and remedy provisions.

Finish with a conditional recommendation

The recommendation should name the preferred approach, explain the evidence, disclose cost assumptions, and list unresolved conditions. If a critical interface has not been tested, say what test remains and whether approval depends on it. Avoid broad claims such as “future-proof” or “fully compliant.” Describe the concrete requirement satisfied and the evidence available for that statement.

Retain a decision log. When a requirement changes, record who requested it, why it changed, and how it affects scope, cost, risk, and timing. This gives implementation a usable baseline and reduces later arguments about what procurement intended. The checklist is the index to that evidence; it is not a substitute for the evidence or the professional judgment needed to approve a real purchase.

Approval worksheet

Before the final approval meeting, circulate a short decision brief rather than the entire procurement archive. State the business problem, selected approach, scope boundary, total modeled cost, buyer resource requirement, and open conditions. Link each important conclusion to its supporting document. A reviewer should be able to distinguish an accepted risk from an unanswered question without reconstructing the sales process.

Ask the sponsor to confirm what would invalidate the recommendation. Examples include a materially different license interpretation, an unsuccessful critical interface test, unavailable buyer staff, or a changed launch constraint. Record the agreed response if one of those conditions occurs. Finally, transfer the decision file to the implementation lead and confirm that the project baseline matches the approved purchase. Procurement is complete when delivery can understand and execute the commitment, not merely when the preferred vendor has been announced.

FAQ

How many suppliers should be shortlisted?

Choose a number your team can evaluate seriously. There is no useful universal target. Each finalist should receive the same critical workflows and a comparable opportunity to clarify scope and assumptions.

Should a checklist produce a percentage score?

A completion percentage can organize work, but it cannot establish suitability. One unresolved mandatory requirement may matter more than many completed minor items. Preserve hard gates and explicit exceptions.

Who owns the final decision?

The organization's authorized decision makers. Business, finance, IT, security, procurement, and legal roles should approve the aspects within their responsibility. A consultant's recommendation does not replace internal accountability.

Sources

NIST Small Business Cybersecurity Corner — security review resources for the appropriate approval gate.

Continue the workbook

Use the ERP total cost calculator for your own scenario, the quote readiness checklist to track evidence, and the cost structure comparison to review purchasing models.