26 Questions to Ask in Your Next TMS Demo

A new treasury system will shape how your team works for years. Whether you’re replacing a system you’ve outgrown or buying your first treasury management system (TMS), the demo is your best chance to see how the software will work with your banks and your team before you sign anything.

The questions below came from treasury teams in our recent TMS demos, and each one includes why treasury teams ask it and what the answer means for your business. Lead with the ones tied to the reason you’re evaluating a TMS, such as daily visibility across all of your banks or one approval workflow for payments. They work with any vendor on your list, including us.

Bank connectivity

Every report and payment in a TMS runs through the connection to your banks, and bank timelines usually decide the go-live date.

1. “Which of my banks have you connected to before, and which would be a first-time build?”

Send the vendor your bank list before the demo. They can come back with which banks they connect to today and which would be a new build. Balance reporting and payments often run on separate connections, so ask about both.

2. “How long does it take to connect a bank, and who controls that timeline?”

Timelines vary more from bank to bank than from vendor to vendor, because each bank runs onboarding through its own implementation team. Ask which of your banks have moved quickly for other customers. Your team can often start the bank paperwork in parallel with the TMS contract.

3. “When a feed breaks, how do we know if it is your issue or the bank’s, and who calls the bank?”

Feeds will fail at some point, so the useful question is who owns the fix. A vendor that connects many companies to the same bank often spots a bank-wide problem before customers do. Ask who monitors the feeds and who opens the ticket with the bank.

4. “What happens when a bank changes its file format?”

Banks change formats on their own schedules, and payment messaging on the major rails has moved to ISO 20022. A vendor maintains one mapping per bank for every customer it serves. Without that, your IT team maintains its own for each bank you use.

5. “How long do you keep the raw bank files, and can I get them?”

Transformed data shows what the system did with the bank’s file. The raw file shows what the bank sent. When a balance is questioned in an audit or a dispute, the raw file settles it, so ask how long it’s kept and whether your team can download it without a support request.

6. “Do my banks charge for the connection, and which ones?”

Banks charge for API access and file transmission, and the fees vary by bank. The vendor can tell you which connection type it would use at each bank, and your relationship manager can tell you what that connection costs. 

7. “How current is the balance I see, bank by bank?”

A demo usually shows the most current feed available. Your own banks will vary, with some sending intraday updates and others sending prior-day files. Add this question to the bank list you send ahead, so you know which accounts you can fund or sweep before the wire cutoff.

Data and transaction rules

Tagging rules decide which category every bank transaction lands in, and those categories feed your cash reports and forecasts.

8. “Show me how you tag one transaction, then show me the rule it created.”

A rule your team can read is a rule your team can fix. Ask to see one created live, then ask what happens when a transaction fits two rules. How the system decides between them tells you how much cleanup to expect.

9. “What happens to the transactions the rules miss?”

New counterparties and inconsistent bank descriptions will always slip through some rules. Ask where those transactions go and whether a rule you fix today applies to the transactions that came in before it.

10. “Is matching rule-based or model-based, and can I see why it matched?”

Your controller and your auditor will ask why two items were matched. A system that shows its logic lets your team answer on the spot. Ask the presenter to open a matched item and walk through it.

11. “Can I get the bank statement as a PDF, and would my auditor accept what this system produces?”

Statement availability depends on the bank and the connection type. Ask the vendor to include it in their review of your bank list. Every bank on that list is one fewer portal your team logs into during audit season.

Cash forecasting

A forecast is as useful as your team’s confidence in it, and that confidence comes from measuring it against what happened.

12. “How do we test the forecast for accuracy before we rely on it?”

Ask how the system reports variance against actuals, by week and by category. Category-level variance shows you which cash flows drive the misses, so your team knows where to focus. Ask how much history the model needs before those numbers mean something.

13. “Where do my bespoke calculations live, in the system or in my spreadsheet?”

Some calculations belong in Excel, like a covenant model or a joint venture distribution waterfall. Ask where the vendor’s forecasting stops and how live bank data reaches your workbook. The answer tells you which spreadsheets your team keeps and which ones stop needing manual updates.

14. “Can I forecast by entity, bank, and currency, and roll it up?”

Consolidation is where forecasting tools differ most. Share your entity, bank, and currency structure before the demo so the vendor can show a forecast built on something close to yours, rolled up into your reporting currency.

Payments and controls

A payment demo shows the release. These questions cover the approvals before it and the bank’s response after it.

15. “Why would I send payments through this instead of the bank portal or the ERP?”

This is the payments question we hear most in our demos. Moving payments into a TMS changes where approvals happen and what the bank sends back after a file arrives. Read why payments should run through your TMS instead of your ERP.

16. “Do approvers in your system have to match approvers at the bank?”

Two approval lists will drift apart over time, and a mismatch holds up payments. Ask where approval authority lives and what the bank checks when a payment arrives.

17. “What happens when a payment is rejected at the bank?”

Many systems mark a payment complete once the file is sent. The bank’s acknowledgment and confirmation come later, and a rejection can come back at either point. Ask to see each status a payment moves through and where the bank’s rejection reason appears.

18. “Can I control the order payments are released?”

Some payments depend on others, like funding a disbursement account before payroll releases from it. Ask whether the TMS can sequence releases or whether your team manages the order by hand.

19. “Can I trace one vendor payment inside a batch?”

Banks often report status on the batch as a whole. Ask whether the TMS shows the status of each payment inside it, because that’s the detail your team needs when a supplier calls.

20. “When someone leaves, how do I remove their access across every bank at once?”

Offboarding one person across several bank portals is manual work and a common audit finding when it slips. Ask to see a user disabled in the TMS and what happens to their access at each bank.

Security and AI

Your security and IT teams will review any TMS you choose. Raising these questions in the first demo gives them what they need early.

21. “How do your user permissions relate to what the bank allows each person to do?”

A user restricted in the TMS may still hold broader rights at the bank. Ask which set of permissions governs what that person can see and release, and ask to view the system as a restricted user.

22. “Where does the AI run, what data does it see, and does any of it train a model?”

Your security team will need all of these answers in writing. Asking in the demo starts that review early and tells you how prepared the vendor is for it.

23. “What stops us from dropping our bank data into a general AI tool ourselves?”

A general AI tool can analyze any file you give it. The hard part is producing that file every day, from every bank, with every transaction cleaned and categorized the same way. Ask the vendor how its AI gets its data, because that answer is the core of your business case.

Implementation and references

How a vendor talks about implementation before you sign is a preview of how they’ll work with you after.

24. “Do you have a sandbox we can use before signing?”

A sandbox runs on sample data. Your evaluation depends on how the system handles your data. Ask what the vendor can show you using your own bank information before you sign.

25. “What do you need from us to go live on time, and what has made implementations fail?”

Implementation teams know which delays repeat across projects. Ask for the list. Bank signers and account lists are common items, and your team can have both ready before kickoff.

26. “Can I talk to a customer at my size, on my banks, using this for the same thing?”

A reference that looks like your company tells you more than a general one. Ask them how long their bank connections took and what they’d plan differently.

Test these questions on Trovata

Bring your list to a Trovata TMS demo. Click here to book a demo.

Frequently asked questions

What should I ask in a TMS demo?

Ask about the parts of treasury work that happen after go-live. That includes failed bank feeds, rejected payments, transactions the rules miss, and what the vendor needs from your team to launch on time.

Should I send my questions to the vendor before the demo?

Yes. Sending questions ahead lets the vendor build the demo around your banks and workflows, so what you see reflects your setup.

Is it normal to need more than one TMS demo?

Yes. Evaluations often include follow-up sessions focused on one area, such as payments or forecasting. Ask for one whenever a question needs more time than the first demo allowed.

Why do treasury teams ask about the bank portal or the ERP in TMS demos?

Most teams release payments from one or both today. Moving payments into a TMS changes where approvals happen and what the bank sends back, so teams want to understand that change before they commit. Read our full piece on this question.