System Selection and Vendor Commercials

Selecting a finance ERP is not a beauty contest and it is not a software procurement exercise. It is a decision about operating discipline: what you will standardize, what you will govern, and what you will be willing to change about how finance works. The vendor logo matters less than the choices you make during selection—choices that determine how much you will customize, how much you will integrate, and how predictable your delivery will be. Done well, selection produces a platform and a commercial structure that support fit-to-standard, stable scope, and manageable long-term cost. Done poorly, selection bakes in ambiguity, encourages scope inflation, and creates contracts that reward activity instead of outcomes.

This chapter focuses on the practical mechanics of selecting the right system and structuring vendor commercials. The goal is to run selection as a controlled decision process: requirements that don’t recreate the legacy, governance that prevents politics from driving outcomes, a total cost view that holds up under scrutiny, a partner choice based on delivery capability, and contracts that reduce downstream scope battles.

Keep one principle visible throughout selection: the system you choose will be the system you must operate. If a platform “works” only with heavy customization, weak controls, or fragile interfaces, it is not working—it is accumulating debt. Selection is your first opportunity to choose standardization over exception management.

7.1 Requirements and Fit-to-Standard Evaluation

Requirements are the first fork in the road. In many organizations, “requirements gathering” becomes a formalized way to preserve the past. Teams document every legacy exception, label it a must-have, and then judge vendors on who can reproduce it most easily. That approach guarantees customization, drives complexity into build and testing, and creates a system that feels familiar but remains expensive and hard to upgrade.

Fit-to-standard turns the conversation around. Instead of asking, “Can the system do what we do today?” you ask, “Can we run our finance processes using the system’s standard patterns, and what are the few gaps we truly must close?” Fit-to-standard: an evaluation approach that prioritizes adopting standard system capabilities and business process patterns, allowing deviations only when they are required by regulation or are truly differentiating to the business model.

Fit-to-standard works only if you distinguish non-negotiables from preferences. Use your target outcomes and decision principles as filters. If close acceleration is a target outcome, requirements should emphasize clean subledger posting, strong period controls, and standardized reconciliations—not “keep our current spreadsheet close pack format.” If controls uplift is a target outcome, requirements should emphasize workflow, access, audit trail, and evidence retention—not “allow local admins to create suppliers quickly.”

Organize requirements into four layers, and keep the first two layers short and crisp. If you over-invest in detailed feature lists before you agree on standard process patterns, you will recreate the legacy in a new language.

• Business outcomes: measurable results the program must deliver (close days, exception rates, audit findings).
• Process patterns: the standard ways you intend to operate (global COA, centralized supplier onboarding, standard intercompany).
• Functional capabilities: features needed to execute the patterns (matching tolerances, journal workflow, bank reconciliation).
• Technical and nonfunctional requirements: security, performance, data residency, integration, availability, and support.

The third layer is where many selections derail. If you have thousands of “requirements,” you do not have requirements; you have documentation. In practice, long lists create three problems: they overwhelm evaluators, they push vendors into generic “supported” responses, and they encourage stakeholders to protect local preferences by sheer volume. To keep evaluation grounded, define a small number of must-prove scenarios that reflect your messy realities. Must-prove scenario: an end-to-end workflow that vendors must demonstrate using configured data, showing posting logic, controls, reporting, and exception handling.

Good scenarios include corrections, reversals, and period-end timing. They test intercompany, multi-currency, approval routing, and recovery when something fails—not only the happy path. They also force a discussion about what will be standardized. For example, if three countries have three different invoice approval patterns, the scenario should test the standard pattern you intend to adopt and highlight what would be lost or gained by adopting it.

Use this template to define each scenario in a way vendors and internal evaluators can follow consistently.

• Scenario purpose: what business risk or outcome this scenario validates.
• Actors and roles: who performs the steps and what approvals occur.
• Data prerequisites: master data objects, hierarchies, and configuration assumptions.
• Steps and variations: normal flow plus one or two exception paths.
• Expected outputs: postings, audit trail, reports, and reconciliation points.
• Evaluation criteria: what “good” looks like, including usability, control strength, and traceability.

In fit-to-standard workshops, control the language and the decisions. Subject matter experts will naturally drift toward “we need to do it like this” unless you establish a disciplined facilitation model. Classify gaps consistently: Standard: adopt the vendor’s process. Configurable: adjust within supported configuration. Extendable: add through approved extension frameworks. Custom: modify core behavior; treat as last resort. Record the rationale, not just the label, because the rationale is what typically survives stakeholder pressure later.

Many “gaps” are not functional; they are adoption issues. Capture these as Adoption gaps: differences between current behavior and the standard process that require training, role redesign, or operating model change rather than system build. Treat adoption gaps as first-class work, with owners and actions, because they are often where value is actually created (for example, enforcing receiving discipline so three-way match works, or standardizing journal support requirements so audit evidence is complete).

A practical tool is a single, controlled gap log. It should be maintained by the design authority and used as the primary input to scope, cost, and risk decisions. Keep it tight and decision-oriented.

• Gap description: the specific difference between standard and your need.
• Type: standard adoption, configuration, extension, customization, or policy change.
• Business rationale: regulatory requirement, business model need, or preference.
• Impact: estimated effect on cost, timeline, controls, and upgradeability.
• Decision: accept standard, configure, extend, defer, or escalate.

Do not separate functional evaluation from data and reporting. Ask vendors to demonstrate using your draft COA segments and your entity hierarchy style, even if imperfect. This surfaces mapping, reporting, and governance implications early—when you can still change them cheaply. Also ask vendors to show how they handle master data governance, including duplicate prevention, approval workflow, and change logging for sensitive fields such as bank details.

Finally, enforce “requirements hygiene” so the requirements you do document remain usable. Requirements hygiene: simple writing and governance rules that prevent requirements from turning into solution designs or legacy documentation. Require each requirement to state the intent (what and why), not the implementation (how). Require a priority tied to outcomes. Require a source (regulatory, policy, business model). And require an owner who can approve tradeoffs. If you do this, your requirements become a selection tool instead of a customization wish list.

7.2 Vendor Shortlist, RFP, and Evaluation Governance

A disciplined evaluation process protects you from internal politics and vendor choreography. Politics shows up when stakeholders shape requirements to favor a preferred product. Choreography shows up when demos are polished performances that avoid your real risks. Governance keeps evaluation fact-based, comparable, and aligned to end-to-end finance outcomes.

Start with a rational shortlist: two to four vendors that plausibly fit your complexity and deployment intent. Use segmentation criteria first (multi-entity, multi-currency, intercompany, regulatory footprint), then practical constraints such as implementation talent availability in your markets and the vendor’s roadmap for the product line you would adopt.

Structure your RFP for comparability, not narrative. Build it around: your key scenarios, your nonfunctional constraints, your data and integration footprint, and your commercial assumptions. Require vendors to state explicitly what is standard, configurable, or requires extensions, and to identify any third-party products or add-on modules required. Require clear statements about upgrade cadence, release management responsibilities, environment strategy, and audit evidence retention.

Evaluation governance should include decision rights, scoring, and conflict resolution. Create three bodies with clear roles.

• Executive steering: sets decision principles, resolves major tradeoffs, and approves final selection.
• Design authority: senior finance and IT leads who own process and architecture decisions and evaluate fit-to-standard implications.
• Working teams: SMEs who execute scenarios, validate controls, and assess usability and reporting.

Define the scoring model early and keep it understandable. Weight categories based on your outcomes and risks. Ensure scoring includes: functional fit to standard patterns, controls and security, reporting alignment, integration and extensibility, total cost, and ecosystem/talent. Too many categories create false precision; too few categories invite politics. Also decide how you will handle “red flags” that override scoring (for example, failure to meet a regulatory constraint or a major data residency requirement).

Run demos as scenario labs with rules that force comparability. Provide scenarios in advance and require vendors to demonstrate the end-to-end flow, the postings, the audit trail, approval routing, the exception path, and the report outputs. Include “messy” prompts such as a rejected invoice due to a missing receipt, an intercompany mismatch, a payment rejection, or a late correction. The quality of a platform is often revealed by how it handles exceptions and recovery.

• Demo rule: no “future roadmap” claims count unless the capability is generally available and demonstrated.
• Demo rule: no custom code is allowed in demos unless the customization is explicitly proposed and costed.
• Demo rule: every scenario must end with evidence—postings, controls, and a report output that can be traced back.

Capture open items and require written follow-up with evidence, not promises. Evidence requirement: vendor responses must include the configuration approach, any dependencies on additional modules or third parties, and any licensing implications. Maintain an “assumptions register” for each vendor so you can compare where their proposal relies on assumptions about your data, your operating model, or your internal responsibilities.

Reference checks are where evaluation becomes real. Ask references about post-go-live realities: upgrade experience, integration stability, staffing quality, and the number of spreadsheets that survived. Ask what they would do differently about data governance, testing, and change adoption. Include at least one reference that resembles your complexity profile and operating model, and at least one reference in your regulatory context if audit expectations are high.

Do not defer security and compliance evaluation. Include role model depth, segregation of duties support, logging, privileged access, and data residency as first-class evaluation criteria. If internal audit must sign off, engage them during selection so you do not discover late objections after contract signature. Also evaluate operational security processes such as access provisioning, recertification, and emergency access, because these become day-to-day controls after go-live.

Plan the decision moment. Use governance bodies to create a recommendation with documented tradeoffs and decision principles. If the steering committee overturns the recommendation, require explicit rationale. That discipline prevents downstream blame games and keeps delivery aligned.

7.3 Total Cost of Ownership and Contract Benchmarking

Total cost of ownership is where many CFOs become skeptical—and rightly so. Subscription pricing can look manageable while implementation, integration, environments, and ongoing support create a much larger cost profile. A credible TCO model makes the true cost visible and creates commercial leverage because you can negotiate based on quantified drivers rather than general discomfort.

Build TCO as a lifecycle model. Include at least five years and separate costs into: software costs, implementation costs, internal costs, and run costs. Then model the multipliers: number of users, number of entities, number of interfaces, number of environments, and release cadence. Those multipliers are scope decisions you control, so they should be visible in steering discussions.

Software costs: subscription or license, required modules, add-ons, and any third-party products needed to meet requirements (tax engines, document capture, reconciliation tools). Validate how nonproduction environments are priced and what is included versus extra. Clarify metrics (named user, concurrent user, consumption) and test whether the metric matches your operating reality, including occasional approvers and inquiry-only users.

Implementation costs: SI services, vendor services, data migration, integrations, reporting, testing, training development, and cutover support. Implementation cost is heavily influenced by customization and by the number of variants allowed. The most expensive implementation is usually the one with the most exceptions. Require transparency in staffing mix and assumed client contributions so the cost model is not built on wishful thinking.

Internal costs: SME time and backfill, finance change leadership, data cleansing, and the cost of running the business during testing and cutover. These costs are commonly underestimated because organizations assume SMEs can “do it on the side.” If internal effort is not resourced, critical workstreams stall and the program pays through schedule slips and quality shortcuts.

Run costs: application support (L1–L3), managed services, integration monitoring, security administration, release testing, and enhancements. Run cost is where customization debt becomes visible because every custom object and fragile interface must be maintained and retested. Also include the cost of maintaining your reporting layer and data pipelines, which often outlast the project team and become a permanent capability.

Benchmarking is not about finding the lowest price; it is about avoiding traps and structuring terms that match your operating reality. Watch for escalation clauses, restrictive audit rights that create surprise charges, inflexible user metrics, and renewal terms that weaken price protection. Also benchmark implementation commercials: a low rate can be offset by a staffing model that requires more people or more senior resources, or by heavy reliance on subcontractors you did not evaluate.

Commercial negotiations should focus on the levers that matter most in ERP economics.

• Price protection: limits on annual increases, renewal caps, and commitments for future modules.
• Flexibility: ability to scale user counts down after divestitures and to add entities without punitive re-pricing.
• Support terms: response times, severity definitions, and included versus billable support services.
• Auditability: clear audit rights and transparent true-up mechanisms that avoid surprise invoices.

Create at least two cost views to test sensitivity: cost by user type (core finance versus occasional) and cost by complexity drivers (entities and interfaces). Use these views to model growth, acquisitions, and divestitures so leadership understands the cost implications of the strategy they are pursuing.

Do not ignore the commercial impact of integration and reporting. Middleware licensing, API usage fees, security tooling, and analytics platform costs can materially change TCO. Include these costs and use them as negotiation points: either reduce requirements through standardization or secure commercial relief.

Finally, tie cost to risk. If a vendor or SI proposes an aggressive timeline, validate whether it is realistic given data quality and internal capacity. If not, cost will show up later through change orders or extensions. A credible TCO model includes explicit contingency aligned to known risk areas: data, testing, integrations, and change adoption. Make contingency visible and then manage it through governance, not as an unspoken buffer.

7.4 Implementation Partner Selection

For most organizations, the implementation partner has more impact on outcomes than the software vendor. The partner influences design quality, fit-to-standard discipline, data and integration execution, and the daily rigor of program management. Yet partner selection is often treated as a procurement exercise focused on rates. Your objective is delivery capability: the ability to execute with predictable quality under pressure.

Start by defining the delivery model you need. Some organizations need a partner to lead end to end because internal capability is limited. Others need a partner to provide specialized roles while the client leads governance and design. Delivery model: the allocation of responsibilities across client, SI, and vendor, including who owns design decisions, configuration, testing, cutover, and change management.

Evaluate partners on five dimensions.

• Fit-to-standard discipline: evidence that the partner can challenge requirements, limit variants, and avoid customization drift.
• Industry and process depth: ability to translate industry realities into standard patterns and controls.
• Data and integration capability: proven methods for data governance, migration rehearsal, and interface operability.
• Program leadership and PMO strength: integrated planning, dependency management, RAID discipline, and transparency.
• Staffing model quality: the specific people, their experience, continuity plans, and the mix of onshore/offshore.

Insist on named key roles, not only résumés. The proposal should identify the program leader, solution architect, data lead, testing lead, and change lead, along with availability and continuity plans. Key role continuity: commitments or governance mechanisms that prevent critical roles from being rotated out after the sales cycle.

Ask partners to explain how they run the hard parts: resolving cross-country design conflicts, preventing test cycles from becoming endless, executing conversion rehearsals, and running cutover and first close support. Request sample artifacts such as decision logs, test strategies, conversion rehearsal plans, and hypercare playbooks. You are assessing operational maturity, not sales polish.

Accelerators can reduce risk, but only if they remain supportable. Ask how accelerators are maintained across upgrades and how they are supported after go-live. Also observe how the partner challenges assumptions in working sessions. If they always agree, they may be avoiding issues that will surface later at greater cost.

Be realistic about your internal responsibilities. Partners typically assume timely decisions, SME availability, data cleansing, and business readiness activities. If you cannot meet those assumptions, schedule and cost will drift regardless of partner quality. Partner selection is inseparable from internal resourcing reality.

7.5 Contracting and SOW Structuring

Contracts are operating mechanisms. They determine how scope is interpreted, how changes are handled, what “done” means, and whether incentives align with outcomes or with billable activity. Poorly structured statements of work are a major cause of downstream scope battles and disputes. Good SOWs create clarity, reduce ambiguity, and provide levers for governance.

Write your SOW around deliverables and acceptance criteria, not vague phases. Deliverable-based SOW: a contract structure where work is defined by tangible outputs (design artifacts, configured processes, tested integrations, trained users) with explicit acceptance criteria and review windows. This structure reduces arguments because it defines what must be produced and how it will be judged.

Acceptance criteria must be objective. “Configured and tested” is not objective unless you define the tests, the exit criteria, and the evidence required. For example, an interface deliverable might require: successful end-to-end test with control totals, documented error handling, monitoring alerts configured, and a runbook approved. A reporting deliverable might require: validated trial balance tie-out, certified close pack reports, and sign-off by finance report owners.

Make “done” include operability. In many programs, build is considered complete when configuration exists, even if monitoring, runbooks, and ownership are undefined. Add acceptance criteria for operability: monitoring in place, support procedures documented, and handover completed. If you do not, the program will push unfinished operational work into hypercare, and hypercare will expand.

Write change control like you expect to use it. Define a mechanism where a change request includes business value, impact on schedule and cost, and a tradeoff proposal (what will be removed or deferred). Require governance approval thresholds so that minor changes are handled quickly and major changes are escalated appropriately. Also define what is not a change (for example, fixing defects against agreed requirements) so you do not pay for rework disguised as “change.”

Align commercials to delivery reality. Time-and-materials can be appropriate when scope is uncertain, but it requires transparency and strong governance. Fixed-price can work only when acceptance criteria are tight; otherwise, risk shows up through change orders. Hybrid models are common: fixed price for well-defined deliverables and T&M for discovery or uncertain work.

Be explicit about assumptions and client responsibilities: SME availability, decision turnaround times, data cleansing tasks, access to source systems, and business readiness activities such as training attendance. Then manage these responsibilities through governance as operational dependencies, with visible metrics (for example, decision turnaround time and test participation rates).

Define the boundary between implementation and hypercare. Hypercare: the defined post–go-live support period with heightened staffing, triage processes, and performance metrics. Specify duration, severity definitions, response times, and exit criteria to steady-state support. Without clarity, hypercare becomes an open-ended extension of the project and a quiet extension of spend.

Protect yourself with knowledge transfer. Require documentation standards, configuration repositories, and runbooks as deliverables. Require training for internal support teams and clear handover milestones. If you rely on a partner long-term, do so intentionally through a managed services agreement with measurable SLAs and a clear enhancement intake process.

Use this contracting checklist to reduce downstream risk.

• Scope clarity: in-scope and out-of-scope lists are explicit, including interfaces and reports.
• Deliverables: each phase produces tangible artifacts with review and approval steps.
• Acceptance: objective acceptance criteria and evidence requirements are defined.
• Change control: process, thresholds, and tradeoff expectations are explicit and usable.
• Staffing commitments: key roles and continuity expectations are documented.
• Transparency: reporting cadence, metrics, and access to underlying plans and logs are required.
• Risk ownership: responsibilities for data, testing, integrations, and business readiness are clear.
• Hypercare: scope, staffing, SLAs, and exit criteria are defined.
• Knowledge transfer: documentation and handover deliverables are contractual, not optional.

When selection and contracting are done with this level of rigor, you reduce the probability of “surprise complexity” later. You also create a healthier dynamic with vendors and integrators: fewer debates about interpretation, more focus on outcomes, and clearer accountability for the decisions that drive cost, schedule, and quality.