4 Treasury Workstation Picks for 2026 [Decision Guide]

A treasury workstation is the cash, payments, bank-connectivity, and short-term risk layer that sits on top of the general ledger. It is not a bank portal, it is not an ERP cash module used in isolation, and it is not a spreadsheet that a treasurer rebuilds every Monday. Kyriba, GTreasury, HighRadius, and Bottomline are the four names this page scores. US Tech Automations sits above them as a proposed exception layer for payment files, variance alerts, and dual-control review — not as a fifth workstation.

TL;DR: Buy Kyriba when you need a global cash and payments workstation and will fund a real implementation. Buy GTreasury when debt, hedge, and cash need one record. Buy HighRadius when cash application and treasury forecasting should share one AI-heavy stack. Buy Bottomline when the pain is payments, bank connectivity, and payee controls more than a full TMS. Do not buy any of them if the only job is reconciling one operating account in the ledger you already close.

Who a treasury workstation is for

This page is for corporate treasury, shared-service finance, and financial-services operations teams that already have a ledger and still cannot produce a same-morning cash position, a payment file with dual control, and a bank-statement match without a shared drive. The stack usually includes an ERP, several bank portals, and a payments rail that does not talk to the forecast. Red flags: you only needed a bank login and a spreadsheet for one entity; your bank already hosts the only payment workflow you will ever run; you wanted a new GL and called it treasury software.

Financial-services firms that also market an advisory book can treat inbound as a separate buy from the workstation. Adjacent pages cover SEO for financial advisors, SEO tools for financial advisors, and what that work costs. Those pages do not pick a TMS.

Key Takeaways

• Kyriba, GTreasury, HighRadius, and Bottomline win different jobs: global cash/payments, debt-and-cash in one record, AR-connected forecasting, and payments/bank controls.

• No public workstation list price appeared on the vendor pages checked October 9, 2026; contact the vendors and include implementation, bank onboarding, and payment-rail fees in your budget.

• ACH Network: 33.6 billion payments according to Nacha (2024), valued at $86.2 trillion — the rail most workstation payment modules still have to clear.

• Orchestrate leftover review steps above the workstation; do not replace Kyriba or GTreasury with a glue stack if cash and payments are already the system of record.

How we evaluated the four workstations

A workstation earns its keep on three tests you can run in a sandbox: (1) can it ingest yesterday's bank activity and show a position you would send to the CFO, (2) can it originate a payment with dual control and a payee record that is not a free-text field, and (3) can it explain a forecast miss without a side spreadsheet. Weight the tests before the demo, or the vendor with the best slide deck wins. The weights, validation hours, and pass thresholds below are editorial judgment for planning your evaluation, not vendor scores or measured results.

Fail the row if the vendor cannot show a live bank connection, a payment with two people, or a forecast that uses the same opening cash as the position. "AI forecast" without the bank file is a demo, not a workstation.

Feature matrix

Facts below come from each vendor's public product pages as of 2026-09-20. Where a cell is "contact vendor," the public site did not publish a dated figure we could reprint.

Pricing and TCO (dated)

Pricing checked October 9, 2026.

We checked HighRadius's treasury pricing page, Bottomline's Paymode fee FAQ, and Kyriba's and GTreasury's product and sales-contact pages. No public monthly or per-entity workstation list price appeared on those pages. The honest TCO line is therefore: software quote + bank connectivity + implementation partner + payment-rail fees. Do not treat a "starting at" number from a third-party directory as a Kyriba or GTreasury price.

Bottomline's Paymode FAQ says Premium ACH recipients pay a transaction fee disclosed during enrollment. Virtual-card recipients pay their card provider's interchange fees, with no additional Paymode fees.

Industry operating facts (not list prices)

Industry operating facts. None of these is a vendor list price.

Payments fraud hit 79% of organizations according to AFP (2025 Payments Fraud and Control Survey, covering 2024). BEC remained the top avenue, cited by 63% of respondents according to AFP (same survey). A workstation that cannot lock payee changes and dual-control wires is buying the 79%, not reducing it.

Same Day ACH volume surpassed 1.2 billion payments and $3.23 trillion in 2024 according to Nacha. That speed is why a workstation has to match value date and amount on the same morning, not overnight in a spreadsheet. Liquidity, payments, risk, and working capital are the public module set according to Kyriba. Cash, payments, debt, and risk sit in one TMS story according to GTreasury's treasury management system page. Those are category facts, not prices.

Four vendor profiles

Kyriba — global cash and payments workstation

Best fit: a treasury that already runs multiple banks, currencies, and payment types and needs one liquidity and payments record instead of a portal farm. Public pages at Kyriba describe liquidity, payments, risk, and working-capital modules as the product, not a thin cash dashboard. Implementation usually means bank connectivity, payment formats, user roles, and a cutover where the spreadsheet is banned for the morning pack. Limitations: no public list price on the pages checked October 9, 2026; contact the vendor; implementation is a project, not a weekend toggle; you still need someone who owns bank onboarding. Disqualify if you have one operating account and a ledger rec that already finishes. Ask for a sandbox that shows yesterday's statements, a dual-control payment, and a forecast that uses the same opening cash as the position — not a slide about AI.

GTreasury — cash, debt, and risk in one book

Best fit: treasurers who cannot explain debt, hedges, and cash from two systems and a spreadsheet. GTreasury's treasury management system page puts cash, payments, debt, and risk in the same TMS story. The migration that actually slips is instrument history: coupons, hedges, and facilities that live in a shared workbook with no owner. Limitations: contact vendor for price; if you have no debt book, you are paying for a module you will ignore. Disqualify if the only pain is sending ACH from the bank's website. Ask to see a cash position and a debt schedule produced from the same legal-entity record, then ask who can change a payee without a second approver.

HighRadius — treasury attached to the cash-application engine

Best fit: teams that already feel HighRadius on the AR side and want the forecast to use the same cash-application reality. HighRadius public pages lead with autonomous finance, cash application, and treasury as connected work, not as a standalone TMS that ignores invoices. Limitations: contact vendor; easy to buy more modules than the treasurer will own; if AR is a different vendor's fortress, the "one stack" pitch is a second implementation. Disqualify if you needed a payments-only tool and have no AR automation agenda. The test is whether applied cash and the morning position can disagree without someone noticing before the 9:00 a.m. pack.

Bottomline — payments and bank connectivity first

Best fit: payment operations, payee controls, and bank connectivity are the job, and a full TMS would sit unused. Bottomline public pages emphasize payments, digital banking, and related controls. That is the right category when fraud and payee-master discipline hurt more than forecast variance. Limitations: contact vendor; cash positioning and debt are not the headline; you may still need a TMS later if the treasurer's morning pack is the constraint. Disqualify if you already originate payments cleanly and the gap is forecast vs actual. Ask how a payee change is dual-controlled and how an ACH return lands back on the original payment, not in a mailbox.

Cash-position recipe (worked example)

A 3-entity corporate treasury with 12 bank accounts, about 1,400 outbound payments a month, and a $4.2 million average daily operating cash balance still starts the day in three portals. The event that should close the loop is not a meeting: if the firm uses Stripe Treasury for a payments legal entity, treasury.outbound_payment.posted is the object that says the money left; the workstation still has to land the same payment on the cash position and the bank statement. For 10 business days, count three numbers only: minutes to a signed morning position, unmatched payments at 10:00 a.m., and forecast-vs-actual dollars on the operating entities. If unmatched stays in the dozens, you do not need a fifth dashboard — you need bank connectivity and dual control on payee changes.

When that leftover work is "the payment posted in the rail but not in the workstation, or posted twice," a proposed US Tech Automations workflow could subscribe to treasury.outbound_payment.posted (or the vendor's payment-export webhook), match on amount, value date, and payee identifier, and open a dual-control exception if any of the three disagree. Prerequisites: a payment API or SFTP export you already own, a named reviewer, and a rule that never auto-releases a payee-master change. Human review is the release, not the after-the-fact email. This is a configurable design, not a live customer result.

When the leftover work is "the forecast missed because AR cash was still in a spreadsheet," a second proposed US Tech Automations path could pull the workstation's opening cash, the AR cash-application file, and the bank statement, then hand a variance list to the same reviewer before the 9:00 a.m. pack. This proposed exception layer does not replace Kyriba or GTreasury as the cash book.

Spreadsheets, Zapier, and the workstation as system of record

The real alternative is not "do nothing." It is Google Sheets plus bank CSVs plus Zapier, Make, or n8n watching a mailbox for MT940/BAI2 files, posting a Slack alert, and calling a payments API. Those tools can keep run histories, retries, error branches, and an audit trail when you design them that way. You still own idempotency (double payments), who can change a payee, retention of bank files, and a human before a wire leaves. A proposed agentic workflow design would use the workstation as the cash system of record and only automate the exception: match, flag, wait. It would not become a second cash book.

When NOT to use US Tech Automations: the workstation already produces the morning position, dual-control payments already post, and forecast-vs-actual is a report the treasurer trusts. If Kyriba or GTreasury is already the system of record for the only workflow you have, do not add an orchestration layer so a slide can say "AI." If Bottomline already runs payee controls and the bank file matches, stop.

Common mistakes

Buying a full TMS because the bank portal is ugly. Scoring "AI forecast" before bank connectivity. Letting AP keep a second payee master. Skipping dual control because the team is small. Treating HighRadius as a TMS-only buy when the value is AR plus treasury. Treating Bottomline as a cash-positioning suite. Printing a third-party "starting at" price as if Kyriba published it. Ignoring Nacha's 33.6 billion ACH payments as if wires were the only fraud surface. Building Zapier payments without idempotency keys.

A useful sandbox week looks like this: load 30 days of statements for every account you actually use, originate one ACH and one wire with two named people, change a payee and prove the second person had to approve, then rebuild yesterday's cash position without opening a bank website. If any of those four steps needs a hero in a shared inbox, you do not have a workstation yet — you have a reporting layer. If all four already work in the tool you own, stop shopping and close the exception list instead.

If the same firm also has to prove inbound ROI for the advisory side, use whether SEO is worth it for advisors as the marketing math — not as a substitute for the cash position.

Frequently asked questions

What is the best treasury workstation software right now?

Kyriba for global cash and payments, GTreasury when debt and cash must share a book, HighRadius when AR cash application should feed the forecast, Bottomline when payments and bank connectivity are the job. There is no universal winner.

How much does treasury workstation software cost?

Contact the vendor. No public workstation list prices appeared on the Kyriba, GTreasury, HighRadius, or Bottomline pages checked October 9, 2026. Bottomline separately describes Paymode transaction-fee terms in its FAQ. Budget implementation, bank connectivity, and payment-rail fees, not a homepage sticker.

Is a treasury workstation the same as a bank portal?

No. A portal shows one bank. A workstation ingests many banks, positions cash, and originates payments with controls the ledger cannot see.

Can we stitch this in Zapier or Make instead?

Yes for alerts and file drops, if you own retries, idempotency, payee-change control, and a human release. That is not a TMS. It is a fragile payments bus.

When is HighRadius a better buy than Kyriba?

When cash application and collections are already the constraint and the treasurer will live in that stack. When the constraint is multi-bank liquidity and payments, Kyriba or GTreasury is the closer category.

When should we skip a workstation entirely?

When one entity, one bank, and a ledger rec already finish. Buy the bank's payment tools and close the books.

Treasury workstations earn their keep on a signed morning position and a payment that cannot leave without two people. Score those two tests, date every quote, and only then decide whether an exception workflow above the cash book is even a remaining job.

Run a 40-file sample before you sign. A ranked logo is not a posted result. A demo is not a close. A contract leftover is not a reason to skip dual control.