Zanders technology selection needs a conflict-and-decision record

Map the advisory role before the shortlist

The direct answer is to define the engagement role by decision. Record whether the adviser is helping benchmark the current function, design the target operating model, gather requirements, scan the market, issue and score a request, run demonstrations, perform technical or commercial diligence, negotiate, implement, operate managed services, or supply its own technology. Name the buyer owner, adviser responsibility, deliverable, evidence standard, review right, approval authority, and excluded decisions for each stage.

Keep advice, evidence, recommendation, procurement decision, contracting authority, configuration approval, payment release, and operating accountability separate. An adviser can prepare a well-supported evaluation without owning the corporate decision. Treasury, finance, procurement, technology, security, legal, data, accounting, risk, compliance, audit, and executive stakeholders may each retain decisions that cannot be delegated by a project label.

Disclose relationships and incentives

Create a dated disclosure record for vendors, products, implementation practices, managed services, software offerings, alliances, referrals, reseller arrangements, subcontractors, prior work, contingent fees, commissions, marketing support, data access, and other relationships that could affect or appear to affect scope or recommendation. The record should state who provided the information, the period covered, how it was checked, who reviewed it, and what mitigation applies.

A technology-partner relationship is not proof of bias, and absence from a public partner list is not proof of independence. The useful control is transparency joined to process: exclude conflicted evaluators where necessary, separate sourcing from scoring, require buyer validation, preserve dissent, and document why the candidate universe and weighting remain appropriate. Update the disclosure if commercial roles change during selection or implementation.

Keep requirements and scoring buyer-owned

Start with legal entities, banks, accounts, currencies, instruments, payment types, forecast horizons, accounting bases, policies, limits, data sources, integration architecture, volumes, jurisdictions, users, roles, resilience objectives, security and privacy needs, records, and exit requirements. For every scored criterion define the scenario, evidence requested, scale, weight, threshold, evaluator, conflict status, assumption, missing-evidence treatment, and decision consequence. A feature name or polished demonstration should not receive credit without representative proof.

Use the same scripts and difficult cases for each viable candidate: stale bank data, rejected payment, changed beneficiary, unavailable interface, segregation failure, incorrect valuation input, forecast revision, late actual, journal rejection, privileged change, and recovery. Preserve vendor answers, configured demonstration evidence, gaps, workarounds, dependencies, reference limitations, total commercial assumptions, implementation estimates, and evaluator notes. Do not manufacture precision by averaging fundamentally different concerns into one unexplained total.

Separate selection, contract, and acceptance

The selection record should identify the approved shortlist, final recommendation, decision owner, dissent, conditions, residual risks, disclosure review, procurement steps, and authorized outcome. The contract then needs product and service scope, responsibilities, pricing basis, milestones, data rights, security, service levels, subcontractors, change control, acceptance, remedies, transition, and exit. Neither a winning score nor signed contract proves that the system is implemented or fit for production.

Zanders' official site supports the attributed treasury advisory, technology-selection, partner, implementation, managed-service, and software positioning. It does not establish an engagement's roles, disclosures, candidate coverage, evidence, independence, recommendation, buyer approval, configured product, control effectiveness, implementation quality, financial result, or outcome. Corporate treasury and the buyer's accountable procurement, technology, risk, security, legal, finance, accounting, data, audit, and executive owners retain those decisions.

Enterprise buyer test

Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.

A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.

What we will watch next

Treasury Operations Review will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.