Most organizations approach TMS selection asking 'What is the best system for our needs?' It sounds reasonable. It is also the wrong question. This article reframes TMS selection as a design decision — not a technology decision.
Part of a Series
Treasury Clarity Series
Article 4 of 6 by Santhosh "Sonny" Koritala
Why TMS Selections Fail — Even When the Process Is "Done Right"
Executive Summary
Most organizations approach Treasury Management System (TMS) selection with a familiar objective:
"What is the best system for our needs?"
It sounds reasonable. Structured. Logical.
It is also the wrong question.
Because a TMS does not simply support treasury.
It defines how treasury operates, how risk is understood, how decisions are made, and how confidently leadership can act under pressure.
The real question is not: "Which system should we choose?"
It is:
"What kind of treasury organization are we designing — and can this system actually support it?"
This article reframes TMS selection as a design decision, not a technology decision — and explores why most organizations realize this only after implementation begins.
The Moment That Changes Everything
There is a point in almost every TMS journey where the tone shifts.
It doesn't happen during the RFP. It doesn't happen during vendor demos.
It happens later — often quietly.
When someone asks:
- "Why doesn't this flow the way we expected?"
- "Why is this harder than it should be?"
- "Why are we building workarounds?"
And the uncomfortable realization emerges:
The system is not wrong. It's doing exactly what it was selected to do.
That moment is not an implementation issue. It is a selection issue — revealed late.
The Hidden Assumption
Most TMS selections operate under a subtle assumption: that the organization already understands how it wants to operate.
In reality, many treasury functions are still evolving:
- Processes are fragmented
- Data ownership is unclear
- Controls are inconsistently applied
- Decision-making is not fully structured
The system is then expected to "bring it all together."
But systems don't create clarity. They expose the absence of it.
The Real Role of a TMS
A TMS is not just a tool. It is a constraint system.
It defines:
- What is easy — and what is hard
- What is visible — and what is hidden
- What is controlled — and what is left to interpretation
Once implemented, these constraints become embedded.
A TMS does not just support your operating model. It quietly enforces one — whether that model is intentional, or accidental.
Why Good Processes Still Lead to Misalignment
Even well-run selections often lead to disappointing outcomes. Not because they are poorly executed — but because they optimize for the wrong things.
Optimization Bias
How will this system shape how we operate under stress?
Demonstration Bias
Demos show clean workflows, ideal data, and perfect scenarios. They do not show exceptions, data inconsistencies, integration friction, or edge-case behavior. But those are precisely where systems are tested.
Alignment Assumption
Stakeholders often believe they are aligned — until the system forces decisions like:
- Who owns this process?
- Where does this data originate?
- What is the control point?
Alignment is not proven in meetings. It is proven in system design.
The Part No One Talks About
The most consequential decisions in a TMS selection are rarely documented. They show up as implicit choices:
- How much flexibility vs. control is acceptable
- How standardized processes should be
- How much dependency on upstream systems is tolerable
- How exceptions should be handled
These are not technical decisions. They are philosophical decisions about how treasury should function. And they are often made indirectly — through system selection.
The Shift: From Selection to Design
Organizations that get this right approach TMS selection differently. They do not begin with requirements. They begin with intent.
They Define How Treasury Should Behave
- How should decisions flow?
- Where should control sit?
- What must be visible in real time?
- What should never depend on manual interpretation?
They Accept Trade-Offs Explicitly
Every system introduces constraints. Instead of trying to avoid them, they ask: Which constraints are acceptable? Clarity here prevents frustration later.
They Test for Friction, Not Features
"How difficult is it to do this under non-ideal conditions?"
That is where real differentiation appears.
What Actually Determines Success
Whether the system behaves the way the organization needs it to — when things are not going smoothly. Because that is when treasury matters most.
Designing for the Days Ahead
A well-selected TMS does not just support today's processes. It enables:
- Clarity under pressure
- Consistency across scenarios
- Confidence in decision-making
- Visibility into what matters
It becomes part of the organization's operating discipline. Not just its technology stack.
Closing Thought
Most organizations believe they are selecting a system. In reality, they are selecting a way of working, a structure of control, and a model of decision-making.
The system simply makes that visible.
The difference between a successful TMS and a frustrating one is not capability. It is intentionality.
The series so far
Coming next
Article 5: Why Most Treasury Transformations Don't Deliver →Bring these insights to your treasury
Want to go deeper with Santhosh "Sonny" Koritala, or need hands-on help with your SAP TRM or treasury implementation? Share where you are and the right person will reach out.
About the Author
Treasury & Finance Transformation Leader
Discussion
Leave a comment
Sign in to join the discussion.
No comments yet. Be the first to start the conversation!
