Skip to content

The treasury platform

Every module answers a different question. They all read the same figures.

Cash position, forecasting, reconciliation, payments, intercompany. Each one is a set of screens over the same reconciled picture of every entity, every bank and every currency you run — which is why the next one is a configuration rather than another integration project.

The catalog

What it does, under the name you would look for it by.

Three questions get asked in the same meeting by three different people: where is the cash, is it under control, and what does it plug into. The catalog is grouped the way they are asked rather than the way we built it.

If what you need is not in these three columns, ask for it. A new module is configured on the same reconciled reality the ones above read from — it does not start another integration, and that is why this list keeps growing rather than closing.

One day in the group

The same figure, read twice, on two different screens.

Here is one day. Where the cash ended up, how it got there, and what is still waiting for a person — three screens doing three different jobs, with nothing exported between them.

Treasury position · at close

Total liquidity

EUR 185,200,000

Balances + deposits

Bank balances
EUR 162,800,000
Term deposits
EUR 22,400,000

Across 47 bank accounts

Cash flow statement · today

Closing balances

EUR 162,800,000

At today’s close

Opening balances
EUR 160,555,400
Money in
EUR +8,462,000
Money out
EUR -6,217,400

Net movementEUR +2,244,600

Reconciliation · statement lines

TODAY

Statement lines read

1,284

Today, across every account

Matched
1,251
Waiting for a person
33

Value of what is waitingEUR 318,400

The balances line on the first screen and the closing figure on the second are one number, not two calculations that happen to agree. And the lines the third screen is holding belong to that same day — named, priced and waiting, rather than absorbed into a total that looks finished.

Underneath all of them

There is one reality, and every module is a way of looking at it.

This is the part that is hard to build, and the reason a second module costs so little. Four properties, and a module inherits all four the moment it opens.

Reconciliation
Bank statement lines against ledger entries, and both legs of every intercompany movement against each other — continuously, not at close.
Consolidation
Entities in different countries, currencies and calendars resolved into one position that reads the same at group, country and entity level.
Reporting
Every figure opens onto the record underneath it: the statement line, the journal entry, the file it arrived in and the day it arrived.
The engines
The matching engine weighs competing explanations and scores them. The ledger engine keeps the evidence, the alternatives it rejected and the whole trail.

So a module does not arrive with its own copy of your data, and it does not arrive with its own opinion about what your cash was on Tuesday. It reads what is already there.

What the next one costs you

Adding a module is a configuration. This is the whole list of what you do.

The list is short because the work was done once. Read the left-hand side of each row: it is the part your team would normally be quoted for.

No second data load
The module reads the files and ledger extracts already arriving. Nothing new is exported, and there is nothing to reconcile between what the old module saw and what the new one sees.
No second set of master data
Entities, bank accounts, counterparties and categories are already mapped and already agreed. A new module inherits them on the day it opens instead of asking somebody to key them again.
No second integration project
Nothing is added at your banks, nothing changes in your ERP, and no new connection is opened. What changes is what the platform puts on screen.

Tell us what the screen has to answer and who has to sign it off. It is configured on the reality your own data already forms, which is why the catalog keeps growing and never closes.

Before you ask

The questions this page gets.

01Can we start with one module and add others later?
That is the normal way in. A module is a set of screens over the reconciled reality, so the second one does not re-open the first: no re-import, no re-mapping, no migration between them. Teams usually start where the manual work is worst and add outward from there.
02Do we have to replace the systems we already run?
No. Tresora reads your banks and your ERP and leaves both in place. Your ERP stays the system of record for the ledger, your bank portals stay exactly as they are, and nothing is written back into either unless you configure it.
03What if the module we need is not on this page?
Say what it has to answer and who has to approve it. It is configured on the same reconciled data every module above reads, so it arrives as a screen rather than as a project. The catalog is open on purpose.
04Who actually uses this day to day?
Treasury lives in the position, the calendar and payments. The controller lives in reconciliation and intercompany. Shared services lives in the exception queues. The CFO opens two screens a month and needs both to be defensible upward.
05Do all the modules share one set of permissions?
One set, defined once, in one place. Somebody who can see the group position does not thereby get to release a payment, and every change to who can do what is recorded with who made it. Access follows the identity provider you already run.

Start with the module that hurts.

Pick one. Bring one month of statements and one extract from your ERP, and we will show you that module running on your own figures — including the lines that do not reconcile.

The rest of the catalog stays where it is until you want it. Nothing is switched on that you did not ask for.