# Treasury Management System Requirements Checklist

Source: https://gravam.com/blog/treasury-management-system-requirements-checklist
Author: Tan Gravam
Published: 2026-07-23
Updated: 2026-07-26
Reviewed: 2026-08-02
Summary: A practical TMS requirements checklist — cash, connectivity, payments, risk, accounting, reporting, plus the non-functional requirements teams forget.

**A good TMS requirements checklist covers six functional areas — cash and liquidity, bank connectivity, payments, financial risk, accounting and compliance, and reporting — plus the non-functional requirements (integration, [security](https://gravam.com/blog/tms-cloud-security-and-data-residency), data, deployment, support) that teams routinely forget.** But the checklist below is only useful if every line traces back to a real need and is [prioritized must / should / could](https://gravam.com/blog/how-to-write-a-tms-rfp). A requirements list copied from a vendor's feature grid is worse than no list at all.

Use this as a starting point, delete what doesn't apply, and add the two or three things unique to your business that no generic list would contain.

## Start from your problem, not a feature list

Before the checklist, write down the questions you can't answer today and the decisions they block — _"we can't see group cash intraday," "we can't prove who approved a payment," "our forecast is one person's spreadsheet."_ Those become your **must-haves** and your success criteria. Everything on the list below is a prompt; your business need is what makes an item a requirement.

## The requirements checklist

### Cash & liquidity management

- [ ] Automatic import and consolidation of balances and transactions from all banks
- [ ] Intraday and end-of-day cash positioning across entities and currencies
- [ ] Cash flow forecasting (multiple horizons and granularities)
- [ ] Actual-vs-forecast variance tracking and forecast-accuracy measurement
- [ ] Cash pooling support (physical / notional; zero / target balancing)
- [ ] Intercompany positions and internal funding visibility

### Bank connectivity

- [ ] Statement import in your banks' formats (MT940, camt.053, BAI2)
- [ ] Payment file generation in required formats (pain.001 / ISO 20022, local formats)
- [ ] Connectivity channels you need (SWIFT, host-to-host, EBICS, API)
- [ ] Bank onboarding support and pre-built bank connectors
- [ ] Acknowledgement / status handling (pain.002) and end-to-end payment tracking
- [ ] Coverage for all your current banks — and easy addition of new ones

### Payments

- [ ] Centralized payment initiation (payment factory) if required
- [ ] Configurable approval workflows and limits
- [ ] Segregation of duties enforced in the workflow
- [ ] Sanction / compliance screening or integration to a screening tool
- [ ] Payment templates, recurring payments and bulk handling
- [ ] Full, exportable audit trail of who approved what, when

### Financial risk management

- [ ] FX exposure capture, valuation and reporting
- [ ] Interest-rate (and, if relevant, commodity) exposure and instruments
- [ ] Deal capture for hedges and instruments; lifecycle management
- [ ] Limit monitoring and breach alerts
- [ ] Hedge accounting support (IFRS 9 / your standard)
- [ ] Debt and investment portfolio tracking (schedules, interest, covenants)

### Accounting & compliance

- [ ] Automated accounting entries and posting back to the ERP/GL
- [ ] Reconciliation of treasury sub-ledger to the GL
- [ ] Support for your reporting standards and audit requirements
- [ ] Configurable controls, approvals and change logging
- [ ] Data retention and auditability that satisfies your auditors

### Reporting & analytics

- [ ] Standard treasury dashboards (position, forecast, exposure, debt)
- [ ] Configurable / ad-hoc reporting without vendor dependency
- [ ] Board- and CFO-ready reporting outputs
- [ ] Data export and, if needed, a data feed to your BI / warehouse
- [ ] Drill-down from a number to its source (provenance)

### Non-functional (the part teams forget)

- [ ] **Integration** — clean interfaces to your ERP and any middleware; documented APIs
- [ ] **Security** — SSO, role-based access, segregation of duties, encryption
- [ ] **Data** — master-data model, migration support, data quality tooling
- [ ] **Availability & performance** — SLAs, uptime, response times at your volumes
- [ ] **Deployment** — SaaS vs on-prem; hosting, region, data residency
- [ ] **Vendor** — implementation approach, support model, roadmap, references, viability

> Copy the whole list, then do two passes. First pass: delete every line that isn't a real need for _your_ business. Second pass: add the handful of requirements unique to you (a specific bank, a regulatory quirk, an odd entity structure). What's left is a requirements document you can defend — and score vendors against. It also tells you [which category of TMS](https://gravam.com/blog/best-treasury-management-system) you should be shortlisting in the first place: the requirements that survive the cull are usually a clear pointer to spreadsheet, ERP module or specialist system.

## How to prioritize: must / should / could

Tag every surviving requirement:

- **Must** — the system is genuinely unusable for you without it. Keep this list short; if half your requirements are "must," none of them are.
- **Should** — important, but there's a workaround you could live with for a while.
- **Could** — nice to have; a tiebreaker at most.

This is what lets you compare vendors on _what matters to you_ rather than on who has the longest feature list.

## Turn the checklist into a scoreable workbook

A checklist you tick is a start; a checklist you can _trace and score_ is a selection tool. Give every surviving requirement a row with these columns — then the same rows carry all the way into the demo scorecard and, later, UAT:

| Column | What goes in it | Why it earns its place |
| --- | --- | --- |
| **Req ID** | `CASH-01`, `PAY-03`, `CONN-02`… | Lets a demo score or a UAT test trace back to the line |
| **Requirement** | The capability, in _your_ words | Not the vendor's feature name |
| **Category** | Cash · Connectivity · Payments · Risk · Accounting · Reporting · Non-functional | Groups and balances the list |
| **Priority** | Must / Should / Could | Drives the weighting in the scorecard |
| **Business need** | The question it answers / decision it unblocks | Defensibility — a requirement with none gets cut |
| **Evidence** | Demo result, reference answer, UAT test ID | Proof it's actually met, not just claimed |

The payoff is traceability: every requirement line has an ID that flows into the [vendor demo scorecard](https://gravam.com/blog/tms-vendor-demo-questions-and-scorecard) and then into UAT, so "does it meet our needs?" is answered by evidence against IDs, not by which demo felt best.

## What usually goes wrong

- **Gold-plating.** A 300-line wish list where everything is "must." It can't be prioritized, so vendors optimize for feature-count and you can't tell them apart.
- **Copying a vendor's grid.** You inherit their framing and their strengths, and you miss the requirements specific to your business.
- **Ignoring the non-functional.** Integration, data, security and support decide whether the implementation succeeds — and they're the lines checklists skip.
- **No traceability.** Requirements no one can tie back to a business need; you can't defend them, and they bloat the evaluation.

## Using this in selection

A prioritized, business-anchored checklist becomes the backbone of your RFP and your vendor scorecard: each requirement is a scored line, weighted by must / should / could. That turns "which demo impressed us?" into "which system best meets the needs we actually have?" — the whole point of doing this properly. Score the shortlist against those weighted requirements in the free [TMS Vendor Scorecard](https://gravam.com/tools/tms-vendor-scorecard), and build the numbers behind the case with the [TMS Business-Case Calculator](https://gravam.com/tools/tms-business-case-calculator).

***

_See also [TMS vs ERP vs spreadsheets](https://gravam.com/blog/tms-vs-erp-treasury-vs-spreadsheets) and [when you need a TMS](https://gravam.com/blog/when-do-you-need-a-treasury-management-system)._

## Questions this article answers

**Q: What should a TMS requirements document include?**

Functional requirements across cash and liquidity, bank connectivity, payments, financial risk, accounting and compliance, and reporting — plus the non-functional requirements teams forget: integration, security and segregation of duties, data and master-data handling, deployment, and vendor support. Every requirement should trace back to a real business need, and each should be prioritized must / should / could.

**Q: How do you prioritize TMS requirements?**

Use MoSCoW — must, should, could, won't. 'Must' means the system is unusable for you without it; keep this list short and defensible. 'Should' is important but has a workaround. 'Could' is nice-to-have. Being honest here is what lets you compare vendors on what actually matters instead of on feature-count.

**Q: What non-functional requirements matter for a TMS?**

Integration (how it connects to your ERP and banks), security and segregation of duties, data handling and migration, availability and performance, deployment model (SaaS vs on-prem), and vendor support and roadmap. These decide whether an implementation succeeds far more often than any single functional feature — and they're the ones checklists usually skip.