Skip to content

Implementation

Treasury projects rarely fail on the software. They fail on decisions nobody made.

The early weeks of a treasury implementation are spent finding out which of your own rules are written down anywhere. Where the schedule slips, it is almost always because a question about your operating model reached a vendor who was never in a position to answer it.

Published

Why do treasury implementations run late?

Because the work that looks technical is short and the work that looks administrative is not. Connecting a bank and reading a ledger extract are engineering problems with known shapes. Deciding which entity owns a shared account, or what counts as an internal movement, is a decision about how the group runs, and it is usually being made for the first time.

Those decisions surface in a fixed order and each one blocks the next. Nobody can classify movements until somebody says what the categories are. Nobody can approve a payment path until somebody says who approves. A plan that puts these in a “configuration” phase near the end has scheduled its riskiest work last.

The pattern repeats often enough to plan around. Where a rollout slips, look for the decision that has been open the longest rather than the integration taking the most effort.

What actually happens in the first weeks?

Data arrives and disagrees with itself. That is the point of the exercise, and a project that produces no disagreements early has not looked hard enough yet.

Statements come in for the accounts somebody remembered, and the list turns out to be incomplete. The ledger extract carries entities that were closed and misses one that was opened. Two banks use the same reference field for different things. Every one of those is cheap to fix in week two and expensive to discover in month six, which is why the first weeks are deliberately spent breaking things.

The useful signal at this stage is not how much reconciles. It is whether each thing that does not reconcile has a name. A run that produces one number and a shrug has told you nothing; a run that produces a list of differences with a reason on each one has told you exactly what work is left.

Which decisions belong to you rather than to the vendor?

Anything that encodes how your group operates. A vendor can tell you what the system does with each answer; only you can give the answer, and pretending otherwise is how a configuration ends up being somebody else’s guess about your business.

The recurring list is short. Which accounts belong to which entity, and who is allowed to see them. What makes a movement internal rather than external. Which counterparty names are the same company under two spellings. What difference is small enough to pass without a person looking, which is a threshold you set with your auditor and never one a vendor sets for you.

Write the answers down before the build, even where they are provisional. A written provisional rule can be changed in an afternoon; an unwritten one has to be rediscovered from whoever remembers it, and that person is on holiday in the week it matters.

How do you tell early whether it is going well?

Ask for the exceptions rather than the coverage. A demonstration of what matched is showing you the easy half. Ask to see the lines that did not, and whether each one carries the records behind it and the reason it was held.

The second check is repeatability. Run the same period twice and compare. A process that produces the same answer both times, from the same inputs, is a process. One that produces two answers is still a person with a spreadsheet, wherever it is hosted.

What to do about it

Put the decisions on the plan, not the integrations.

A treasury rollout is a sequence of answers about your own group, wearing the costume of a technology project. The connections and the file formats have known shapes and known effort; the schedule moves on the questions only your people can settle.

So build the plan around those. List them in week one, name an owner for each, and treat an open one as the blocker it is. What is left after that is work that can be estimated.

Where this is worked

What the first connections actually are

The technical half of a rollout is two things: the banks and the ledger. Both are read rather than replaced, and both are where the early disagreements come from.

Also asked

What people ask before they start

01How long does a treasury implementation take?
It depends on how many of your own rules are already written down. The connections and the file reading are predictable work. The schedule is set by how quickly your group settles account ownership, what counts as internal, and who approves what, so the fastest rollouts are the ones that answer those in the first two weeks.
02Do we have to replace our ERP?
No. The ledger is read rather than replaced, and nothing is written back to it unless you configure that. A treasury system that requires an ERP migration has turned one project into two, and the second one belongs to a different team with a different budget.
03What do you need from us to start?
One month of statements for a set of accounts you pick, and the matching ledger extract for the same period and the same entities. That is enough to produce a real reconciliation with real differences, which is the only version of a pilot that tells you anything.

Bring one month and one question.

One month of your own statements and the ledger extract that should agree with them. You bring the question this piece did not fully answer for your group, and we answer it on your own figures.

One session, whichever piece brought you here. No slides before the data.