Choosing Procurement Software: Deployment Model, Scorecard and Demo Questions

Choosing procurement software can easily turn into a comparison of feature lists: does it offer approvals, supplier records, reporting and mobile access? These are important questions, but on their own they do not show how well the system fits the company's operations. The real differences often emerge when a requisition is incomplete, an approver needs a substitute or a data transfer fails.

It is therefore worth assessing three things together: the feasibility of the deployment model, demonstrable compliance with requirements and the total lifecycle cost. The method below helps ensure that decisions following demonstrations are based on documented findings rather than impressions.

1. The foundation of selection: clearly defined processes and responsibilities

First, define where the process to be supported begins and ends. Does it cover only requisition through approval, or does it also include requests for quotation, purchase orders, confirmation of delivery or service completion, and invoice verification? A solution suited to a single subprocess may differ from one that supports procurement operations across multiple organizational units.

Alongside procurement, involve finance, IT, the information security officer and representatives of the requesting departments. Each stakeholder sees different risks: procurement focuses on lead times, finance on budget controls, IT on integration, and users on day-to-day administration.

• Process boundaries: which steps will move into the new system, and which will remain in the ERP?
• Rules: which value thresholds, cost centers and procurement categories affect approval?
• Exceptions: how are urgent, incomplete or subsequently amended requisitions handled?
• Outcomes: what improvements do you want to achieve in lead times, requests returned for correction and traceability?

Document the current state as well. Without baseline data, it will be difficult to determine after implementation whether operations have actually improved. A few clearly defined metrics are sufficient to start with.

2. Cloud-based or on-premises deployment?

The deployment model is not merely a technology decision: it determines operational responsibilities, update procedures and the cost structure. Neither model is automatically more secure or less expensive; the specific terms of service and internal capabilities must be considered together.

Cloud-based operation

In the cloud, the provider typically takes on several infrastructure and application operations tasks, but the exact scope is defined in the contract. Less internal infrastructure preparation may be required, while access management, data quality and enterprise integration still need attention.

Ask where primary data and backups are stored, what access support staff have, which subcontractors are involved and how data can be exported. Clarify the update schedule, the availability of a test environment and the measures needed to handle network outages and maintain continuity of work.

On-premises deployment

On-premises deployment can provide greater direct control over infrastructure, but may also involve more internal responsibilities. Those responsible for servers, databases, backups, monitoring, vulnerability management and recovery must be identified in advance. Postponing updates can also create compatibility and support risks later on.

For both models, request commitments on availability and recovery. RPO defines the acceptable data loss window, while RTO specifies the target recovery time. When connecting a cloud application to an on-premises ERP, assess the network connection and the reprocessing of failed data transfers separately.

3. Weighted scorecard: making proposals comparable

Separate requirements into mandatory conditions and criteria that can be scored. An attractive price or an impressive user interface should not compensate for an unmet mandatory security or integration requirement. Such a gap should be grounds for exclusion unless an acceptable, contractually committed solution is agreed.

The following weighting, totaling 100 percent, can serve as a starting point. Adjust the weights to reflect company priorities before the demos.

• Process fit – 25%: requisitions, approvals, substitute approvers, exception handling, confirmation of delivery or service completion.
• Integration and data management – 20%: ERP connectivity, master data, interfaces, error logging and export.
• Security and compliance – 15%: permissions, authentication, audit logs, retention policies.
• Usability – 15%: ease of submitting requests, task overview, search and accessibility.
• Implementation and support – 10%: project methodology, training, documentation and incident management.
• Scalability and adaptability – 10%: load capacity, support for new organizational entities and changing rules.
• Total lifecycle cost – 5%: comparable costs calculated over the same time horizon.

Rate each item from 0–5: zero should indicate a missing capability, while five should indicate a fully suitable, verified capability. Define the meaning of intermediate scores in advance as well. The weighted score is the score achieved divided by five, multiplied by the percentage weight. This gives a maximum total score of 100 points.

Support each score with evidence: demonstrated functionality, documentation or a contractual commitment. Clearly distinguish between standard features, configuration options and capabilities requiring custom development. A feature promised for a future release is not equivalent to a solution that can already be tested.

4. Demo questions that reveal how the system actually works

Send every candidate the same scenario, preferably with anonymized sample data. For example, have a request that exceeds the budget go through multi-level approval while one approver is absent. Then change the amount, process partial fulfillment and finally introduce an integration error.

Features and user experience

• What happens with an incomplete request? Is the data already entered retained?
• After the amount changes, when does approval restart, and on what basis?
• How are substitute approvers, escalation and reasons for rejection handled?
• Can users see who is currently handling the request and which steps come next?
• How can the request, purchase order and partial fulfillment be linked?

Integration, security and change management

• Which system is the authoritative source for each type of master data, and how is synchronization handled?
• Who is notified of failed data transfers, and how is duplicate processing prevented?
• Can you demonstrate how access to data and actions is separated by role?
• Which events does the audit log record, and how is it protected against modification?
• Who can modify approval rules, and how can changes be tested and rolled back?

At the end of the demo, have a designated user complete a typical task independently. This quickly reveals which steps are intuitive and where training or interface improvements are needed.

5. Support and scalability: ensuring continued operation after implementation

For support, ask for specific terms rather than promises of “fast assistance”: service hours, language, incident categories, escalation procedures and committed response times. Response time is not the same as recovery or resolution time. It should also be clear which reported issues are classified as defects and which are treated as chargeable change requests.

Do not measure scalability solely by user numbers. Concurrent activity, the volume of requests and attachments, reporting workloads and integration frequency also matter. When adding new sites or companies, the ability to extend the permissions and organizational model is equally important.

Request load-testing evidence that reflects your expected operations, or agree on a measurable acceptance test. Always assess test results in the context of the data volume and environment tested.

6. Total cost and a verifiable final decision

Compare proposals over the same time horizon and using the same assumptions. In addition to licensing or subscription fees, include implementation, configuration, integration, data migration, training, infrastructure and internal labor. Also account for the costs of updates, modifications and eventually exiting the solution.

Clarify the pricing unit: named user, concurrent access, module, transaction or storage? Examine how fees change as usage grows and how much test environments or additional connections cost.

For shortlisted solutions, verify uncertain, high-risk requirements through targeted testing. Evaluate against predefined acceptance criteria, then incorporate key commitments into the contract. Keep a record of why the particular system was selected.

Summary: choose operational performance, not the demo

An informed procurement software selection rests on documented processes, manageable operations and proven capabilities. A weighted scorecard helps you compare options, a targeted demo reveals gaps, and a total cost calculation makes the longer-term implications visible.

Considering an xFLOWer solution as well? Request an expert consultation and demo based on your own procurement scenarios. Bring your mandatory requirements, scorecard and most challenging exceptions: these provide a basis for a meaningful discussion about process fit.

This article is part of our comprehensive guide: Procurement Software: A Complete Guide from Selection to Efficient Operations