How to Choose a Treasury Management System

A treasury management system should answer which cash your business can use, what obligations will consume it, and who may move it. For a payment platform, those questions are harder than adding up bank balances: customer money, seller liabilities, reserves, pending settlements, and corporate cash can appear in the same operational reports.

Choose against your actual banks, entities, currencies, payment responsibilities, and controls. The practical test is whether the proposed product can reproduce a cash position and forecast from your records, then carry an approved instruction through the bank response and reconciliation. A polished dashboard does not establish that coverage.

Separate corporate treasury from the payment ledger#

A TMS may integrate with these systems or cover some overlapping functions. That does not make every TMS a marketplace subledger or every embedded-finance API a complete corporate treasury system. Document which system owns each balance, obligation, approval, and accounting entry before asking a vendor to automate it.

Stripe describes its current Treasury for platforms product as financial services for eligible connected accounts, including funds storage, bill pay, and cash flow management. Its documentation also distinguishes public and private preview availability and access requests. Treat that as an embedded-finance offering with specific eligibility, rather than assigning it a corporate TMS score based on its name. See Stripe Treasury for platforms.

Start with a cash position that excludes money you cannot use#

Consider an illustrative platform with $500,000 of bank cash, of which $300,000 is legally restricted customer money. Its processor reports another $100,000 available, of which $90,000 is owed to sellers, plus $30,000 pending settlement. Assume the remaining balances are unrestricted and usable by the corporate treasury team, with no overlap between the bank and processor records.

This is a defined example, not a general permission to use customer or seller funds. Actual ownership, safeguarding requirements, reserves, contractual payout commitments, and bank restrictions determine the exclusions. A provider balance marked available may still be unavailable for corporate spending. Keep those reasons visible rather than hiding them in a single net figure.

With $210,000 opening usable cash, $80,000 of expected available receipts, and $180,000 of corporate outflows, the week ends at $110,000. Against a $100,000 minimum buffer, the surplus is $10,000. If only $40,000 arrives, closing cash is $70,000 and the buffer shortfall is $30,000. A forecast should expose that timing sensitivity before payment approval.

Do not count a processor-to-bank transfer as a new external receipt if the processor cash was already in opening liquidity. Also preserve currency-level positions: a consolidated reporting-currency surplus does not prove that the paying entity has the required currency, bank access, or authority to fund its obligations.

Write requirements that a vendor can demonstrate#

A missing public documentation page means the capability is unverified. It does not prove the vendor fails. Conversely, a product-page claim is not proof that your bank connection, payment rail, or approval model works in the proposed edition. Record three states: documented scope, demonstrated fit, and unresolved requirement.

Keep unrelated personal tax requirements out of the procurement score. A founder’s FEIE analysis or FBAR filing is not automatically a TMS feature requirement. Add a tax or regulatory reporting integration only when the business has an identified obligation and the system has a defined role in producing its supporting data.

Compare current product scope without inventing vendor rankings#

The following examples establish useful starting points from vendor documentation reviewed on October 3, 2026. They are descriptions of published offerings, not independent certification, implementation results, or a recommendation that one vendor fits every platform.

FIS describes different treasury editions and Payment Hub products; do not assume a suite name includes every module. Review FIS product scope. HighRadius describes its treasury capabilities on its product page. Treat its advertised performance figures as vendor claims, not your expected savings.

Trovata currently presents a broader TMS offering, including ERP inputs to forecasting and workflows beyond cash visibility. An evaluation that labels it only a bank-data dashboard would miss that published scope. Check Trovata TMS and its cash forecasting offering, then verify the modules and connections proposed for you.

Use your own records in a short evaluation#

1. Reproduce one real cash position#

Provide a redacted bank statement, processor balance report, ERP obligations, and restricted-fund mapping for a defined date. Ask the vendor to reconcile opening cash, movements, and closing cash. Require the report to distinguish transaction date, value date, balance type, currency, and source timestamp.

Include a stale bank feed. If one account last refreshed yesterday, the screen should identify that age and the affected position. A missing balance must not silently become zero or be presented as a current observation. Agree how the team will operate while that source is unavailable.

2. Challenge the forecast assumptions#

Run the $210,000 example above or an equivalent case from your business. Delay a receipt, change a payout commitment, and alter an FX assumption. Ask who can edit assumptions, whether prior versions remain available, and how actuals will explain the variance. Forecast output informs a funding decision; it does not authorize a payment by itself.

3. Follow a payment through its actual states#

Use an approved evaluation environment to follow creation, approval, transmission, bank acknowledgment, settlement, and reconciliation. A generated payment file proves only file creation. An accepted API request or bank acknowledgment does not by itself prove that the beneficiary received money. Map each status to the evidence your operations team will see.

Test a duplicate submission and a timeout with an unknown outcome. The workflow should preserve the original reference, investigate status, and prevent an uncontrolled second instruction. Changing provider or retrying with a new reference before resolving the first attempt can create two payments.

4. Exercise controls and exceptions#

Change a beneficiary account, exceed an approval limit, and attempt self-approval by the creator. Record the configured outcome and audit evidence. Then test a rejected payment, a missing statement, and an out-of-order transaction. Identify who resolves each exception and how a correction reaches accounting without erasing the original event.

Compare costs and delivery capacity alongside features#

Request a quote that separates licenses, modules, bank connectors, implementation, support, and change charges. Include internal treasury, engineering, security, and accounting time. Ask whether costs change with entities, accounts, payment volume, currencies, environments, or additional data sources.

For illustration, a $40,000 annual license plus $12,000 of annual connectors, $30,000 implementation, and $20,000 internal delivery effort totals $102,000 in year one. The listed recurring external charges are $52,000 before other support or changes. These are invented budgeting figures, not vendor prices.

If the project saves 300 staff hours at $50 per hour, the quantified labor benefit is $15,000 a year. That alone does not cover $52,000 of recurring charges. Better liquidity decisions and stronger controls may justify the investment, but state those benefits and their evidence separately instead of disguising them as measured labor savings.

Before signing, assign bank onboarding, credential management, data mapping, reconciliations, approval configuration, and training to named owners. Obtain usable transaction and audit exports, a connector transition plan, and contractual exit assistance. A replacement project needs historical records as well as a working new dashboard.

Record a decision with conditions for going live#

Choose the offering that meets mandatory requirements and has a credible delivery plan. Keep unsupported items visible with an owner and a due date. A weighted score can compare remaining tradeoffs, but it should not allow an attractive forecast screen to outweigh a failed mandatory bank connection or approval control.

The decision record should name the edition and modules, demonstrated workflows, unresolved gaps, total cost assumptions, implementation owners, and release conditions. Introduce banks and entities in manageable groups, reconcile opening positions, and agree when the old workflow will stop accepting new payment instructions. Avoid two independent systems submitting the same payments during transition.