FiSTWorks is not a treasury management system, and a treasury management system is usually a poor way to create an ACH file. They solve different problems. This post sets out what each one covers, where they overlap, and how to decide which one a finance team actually needs.
What a treasury management system does
A treasury management system, or TMS, is the finance team's view across every bank account and every obligation. The typical scope is:
- Cash visibility. Balances and transactions pulled from every bank, every day, in one place.
- Cash forecasting. Projected inflows and outflows by week or month, built from receivables, payables, payroll and debt schedules.
- Bank account management. Who has signing authority on which account, and the audit trail when it changes.
- Payments. Initiating wires, ACH and international payments from one screen, often with multi-level approval and fraud screening.
- Debt, investments and FX. Tracking facilities, deposits and hedges, and the accounting entries they generate.
- Bank connectivity. Links to each bank through its host-to-host channel, SWIFT or an API, which the vendor builds and maintains.
The payments module is the only part that overlaps with FiSTWorks, and even there the TMS generally sends instructions through its own bank connections rather than producing a file you handle yourself.
What FiSTWorks does
FiSTWorks does three things and stops.
- Validates NACHA files. The ACH Validator checks a file against the NACHA formatting and business rules and reports every problem by line and field. It is free and needs no account.
- Creates NACHA files. ACH Drafter holds your company, bank and recipient details and builds PPD, CCD, CTX, WEB and TEL files from them, checked before download.
- Sends them to your bank. Files can be uploaded through your bank's portal, or sent to the bank's SFTP server from inside the Drafter, with return and NOC files read back from the same server.
It does not hold balances, forecast cash, manage signatories, send wires, or move money. Your bank originates and settles every transaction, as it does today.
Side by side
| Treasury management system | FiSTWorks | |
|---|---|---|
| Who it is for | Finance teams managing many accounts, currencies or facilities | Businesses, property managers and banks that need correct ACH files |
| Cash visibility and forecasting | Core function | Not covered |
| Wires, international, FX | Core function | Not covered |
| ACH origination | One payment type among several, through the vendor's bank connections | The whole product: build, validate, send, read returns |
| NACHA validation of a file you already have | Rarely offered | Free, no account |
| Bank connectivity | Built and maintained by the vendor per bank | Your bank's existing SFTP server or portal |
| Holds or moves money | No, but may route payments through its own connections | No; your bank does |
| Pricing model | Annual contract, usually priced by modules, accounts and users | Monthly subscription; plans on the pricing page |
| Implementation | Months: bank connectivity, data mapping, approval design, training | Hours: enter company and bank details, add recipients, create a file |
| Who runs it | Treasury or a system owner in finance | The bookkeeper or controller who runs payroll and payables |
When you need a TMS
You need a treasury management system when the problem is visibility and control across many accounts, not the mechanics of one payment type. The usual signs:
- More bank accounts than one person can reconcile by logging in to each one.
- Cash forecasting done in a spreadsheet that is wrong by the time it is finished.
- Wires and international payments every week, with approval rules the bank's portal cannot enforce.
- Debt, investment or hedging positions that someone has to track and account for.
If that is your situation, FiSTWorks is not a substitute. It may still sit alongside the TMS for the ACH file work the TMS handles awkwardly, such as a rent-collection debit file or a one-off vendor batch that the TMS's connection does not cover.
When ACH file software is enough
Most businesses that send ACH files have none of the signs above. They have one or two operating accounts, a payroll run, a vendor payment run and perhaps a collection run, and the problem is producing a file the bank accepts without a day of rework. For them a TMS is months of implementation and an annual contract for a payments module they would use for one payment type.
That is the case FiSTWorks is built for. The Validator catches format errors before the bank does, the Drafter removes the hand-building that causes them, and the file goes to the bank you already have. If you are also weighing a payment processor against your own bank, ACH File Software vs Payment Processors covers that choice.
For banks
Community banks evaluating a TMS for their commercial customers face the same scope question from the other side. Most commercial customers do not need treasury software; they need to send a correct ACH file. The banks page describes how FiSTWorks's validator can be offered to those customers under the bank's own brand, without building or supporting a treasury platform.