TMS Vendor Demo Questions and Evaluation Scorecard
How to evaluate TMS vendors: the questions to ask in a demo, and a weighted scorecard to compare them — driven by your requirements, not their sales script.
Evaluate TMS vendors against your own prioritized requirements using a weighted scorecard, and drive the demos with your scenarios and hard questions — not the vendor's script. Score each on functional fit, bank connectivity, integration, implementation approach and viability, weighted by what actually matters to you. The vendor with the best-looking demo is not the same as the one that best fits your needs — and telling them apart is the whole job.
This gives you the questions to ask and a scorecard to compare vendors fairly.
Don't let the vendor run the demo
A vendor demo is designed to impress on the vendor's strengths, using the vendor's clean data and happy path. If you sit back and watch, you learn what they're good at, not whether they fit you. So take control: send every vendor the same handful of your real scenarios in advance, and make the demo about those.
Questions to ask in a TMS demo
Cash & forecasting
- Build today's group cash position live from statements like ours — how many clicks, how much manual work?
- Show a forecast built from data like ours; how is accuracy measured over time?
- How does it handle our entity and currency structure?
Bank connectivity
- Which of our specific banks do you have pre-built connectivity for?
- What formats and channels (SWIFT, host-to-host, EBICS, API; MT940, camt.053, pain.001)?
- How long does onboarding a new bank typically take, and who does the work?
Payments
- Show a payment through an approval workflow and segregation of duties like ours.
- How is the full audit trail — who approved what, when — exported?
- Sanctions / compliance screening: built in or integrated?
Risk & accounting
- Show FX exposure capture, valuation and hedge accounting (if relevant to us).
- How are accounting entries generated and posted back to our ERP?
Integration & implementation
- How does this integrate with our ERP — real interfaces, documented APIs?
- Walk us through a typical implementation: phases, timeline, who does the work.
- What are the most common reasons your implementations run late?
- How is data migration handled?
Vendor & support
- What does support look like after go-live? SLAs?
- What's on the product roadmap, and how often do you release?
- Reference customers of our size and complexity we can speak to?
The evaluation scorecard
Score each vendor 1–5 on each dimension, weight by importance to you, and total. The weights matter as much as the scores — set them from your priorities before you see the demos, so a polished presentation can't quietly re-weight your judgement.
| Dimension | Suggested weight | What you're scoring |
|---|---|---|
| Functional fit | 30% | Coverage of your prioritized must/should requirements |
| Bank connectivity | 20% | Pre-built coverage for your banks, formats, onboarding effort |
| Integration | 15% | Clean, documented ERP integration; realistic effort |
| Implementation | 15% | Credible approach, timeline, who does the work, references |
| Vendor viability | 10% | Stability, roadmap, support, reference quality |
| Total cost of ownership | 10% | Licence + implementation + run, over the horizon |
Weighted score = Σ (dimension score × weight). Do it for every vendor on the same scenarios, and the winner is visible in the numbers — not in whose demo felt best.
What a passing answer has to show
A question only works if you know what a good answer looks like — otherwise a confident non-answer scores the same as real evidence. Set the evidence bar before the demo, and score against it.
| Question | A weak answer (score low) | The evidence you actually need |
|---|---|---|
| Which of our banks are pre-built? | "We support all major banks" | Named coverage for your banks, with the format/channel for each |
| Build our position live | A polished, canned happy-path | Your statements, the click-count and every manual step exposed |
| Typical implementation? | "Usually a few months" | A phase plan, who staffs it, and the named reasons projects slip |
| ERP integration? | "We have an API" | A documented interface, a real effort estimate, a reference doing it |
| Forecast accuracy | "Highly accurate" | How accuracy is measured and improved over time, on data like yours |
The pattern: a passing answer is specific to you and shows the work; a failing one is a confident generality. Score the generalities down, however smooth they sound.
How to score fairly
- Same scenarios, same scorers. One panel scoring every vendor against identical scenarios.
- Score during, decide after. Fill the scorecard right after each demo while it's fresh; compare totals once all are in.
- Tie requirements to scores. Each functional line should trace to your requirements checklist, so "fit" means fit to your must-haves.
What usually goes wrong
- Demo dazzle. Choosing the slickest presentation, which rewards presentation skill, not fit.
- Feature-counting. Picking the longest feature list instead of the best fit to prioritized needs.
- Ignoring connectivity and implementation. The two dimensions that most determine success, most often under-scored because they're less exciting in a demo.
- No weights up front. Setting importance after the demos, so the impressive vendor retroactively looks essential.
Making the decision
Combine the weighted scores with the business case and the references. The right choice is the vendor that best fits your prioritized requirements, connects to your banks, integrates cleanly and can be implemented realistically — proven on your scenarios, scored on your weights. Then the hard part begins: implementing it without losing control.
Part of the Treasury Management Systems guide. Build your requirements first (checklist), then the business case, then plan the implementation. The newsletter sends one finance-systems pattern, product decision or build lesson every two weeks.
Frequently asked questions
How do you evaluate a treasury management system vendor?
Score each vendor against your own prioritized requirements using a weighted scorecard — functional fit, bank connectivity, integration, implementation approach and vendor viability — and drive the demos with your own scenarios and hard questions rather than the vendor's script. Weight the dimensions by what matters to you, run the same scenarios for every vendor, and decide on fit and total effort, not on which demo was most polished.
What questions should you ask in a TMS demo?
Ask them to run your real scenarios — build today's position from your banks, run a real payment with your approval flow, show a forecast from your data. Then probe connectivity (which of my banks are pre-built?), integration (how does this connect to my ERP?), implementation (typical timeline, who does the work, what goes wrong?), data migration, and support and roadmap. Avoid letting them demo only their happy path.
What matters most when selecting a TMS?
Fit against your prioritized must-haves, the strength and coverage of bank connectivity for your banks, a realistic integration and implementation path, and vendor viability. Licence price matters least of these — a cheap system with poor connectivity or a painful implementation costs far more overall. Weight your scorecard accordingly.