Can Tresora send payments to our banks?

Yes. That is what the module is. Tresora builds the instruction, carries it through the approvals your policy requires, and sends it to the bank over the channel that bank uses. The funds stay in your own accounts under your own agreements, and nothing is sent that you did not approve.

Who decides the approval path?

You do, and you change it without us. The steps, the amounts they bite at, which roles sit on them and who may release are all configuration. Every change to any of them is recorded on Authorization Changes, with the person who made it.

Which payment formats and channels do you use?

pain.001 for SEPA credit transfers and every other ISO 20022 bank, pain.008 for direct debits, and MT101 where a bank prefers it, over EBICS, SWIFT, host-to-host or the bank’s API. Status comes back on pain.002 and the debit on camt.054 or the statement itself. If one of your banks wants something else, we add it.

What happens when a bank rejects one?

The rejection lands on the order with the bank’s own reason code, and the order stays open. Nothing is retried on its own. Your position and your forecast keep that money as unpaid, because they read the same order rather than a report about it.

Execution and control

No payment leaves until your approvals are in. Then Tresora instructs your banks.

It reads what your ledger already holds as due, builds the file each bank takes, routes every order to the people your policy names, sends the instruction and reads the answer that comes back. Bulk runs and single orders, on the same reconciled figures every other screen reads.

Request a demo

Payments pending review · one run

Run value

EUR 4,823,500

Across 208 payments

Supplier transfers 168 payments: EUR 2,940,600
Cross-border transfers 31 payments: EUR 704,900
Transfers between your own accounts 9 payments: EUR 1,178,000

Held for review4

What it works from

What does the payments module actually do?

It builds the instruction your bank needs out of what your own systems already hold, moves it through your approvals, sends it, and lands the bank’s answer on the same order. Four sources go into it, and all four are yours.

What your ledger holds as due: The invoices and journal items your ERP has already approved for payment, with the entity, the amount, the currency and the value date they carry there.
Which account it leaves from: Your bank account catalog decides the ordering account for each entity: the agreement it sits under, the currency it holds, and the channel that bank answers on.
Who is being paid: Your counterparty records — the beneficiary, the account details held for it, the names and references it has appeared under, and every earlier payment the group made to it.
What your policy allows: Approval steps, the amounts they bite at, who may release and who may only look. It is configuration in the product, not something anybody has to build.

The file that leaves is the one that bank takes. pain.001 for SEPA credit transfers and every other ISO 20022 bank, pain.008 for direct debits, MT101 where a bank still asks for it, over EBICS, SWIFT, host-to-host or the bank’s own API. One file per account, split the way that bank wants it split. If one of your banks sends or takes something that is not here, we add it.

What stays yours

The funds stay in your own accounts, in your own name, under your own agreements with your own banks. Nothing moves that you did not authorize, and no instruction reaches a bank without the approvals your policy requires.

The approval path

Who has to sign it off before it leaves?

Whoever your own policy says, at the amount your own policy says. A step per role, a threshold per step, and an entity or an account may carry its own. A run stops at the step it has reached and names the person it is waiting for.

Entity controller: Every order raised at that entity, whatever it is worth. The first step is usually the person who knows the invoice rather than the person who knows the balance. Given
Group treasury: The whole run, once each entity has cleared its own. This is the step that decides today rather than tomorrow, because it is the one holding the position. Given
Chief financial officer: Any single order above the limit set for the entity paying it. Set that limit per entity, per account or per counterparty; a run with nothing above it never reaches this step. Waiting

Who can do what

Approval rights are set on Roles & Permissions and nowhere else, and changing them is itself a recorded event on Authorization Changes: who changed whose rights, and when. Seeing the group position does not carry the right to release a payment — the two are separate rights, and a person can hold either without the other. Every release, hold and rejection lands on the Activity Log with the name of whoever did it.

The controls

What stops a payment that should not go out?

A set of checks that run on every order before it can be released, each one comparing that order against something you already hold. An order that fails one stays where it is, with the comparison that held it written on it. Nobody has to notice.

The beneficiary’s bank details: Against the account held for that counterparty in your own records, and against the account every earlier payment to it actually went to. A first payment to new details is a decision somebody makes, never what happens by default.
The amount: Against what this counterparty has been paid before, and against the limit set for the entity paying it. An order that clears both still goes down the approval path; one that clears neither does not reach it.
The duplicate: Against every other order in the run, and against what has already gone out under the same message reference: the MsgId on a pain.001, the sender’s reference on an MT101. Paying one invoice twice is the most expensive error in this module and the easiest one to make.
The beneficiary itself: Against your counterparty records: the account number, the aliases, the names it has been booked under in each entity. A payee the group has never paid before is marked as exactly that.

Payment orders · held for review

Order value

EUR 96,400

Supplier transfer, from a euro account

Beneficiary bank details: CHANGED
Amount against this beneficiary: ABOVE
Duplicate in this run: CLEAR
Beneficiary in your records: KNOWN

Held in this run · 4 ordersEUR 268,300

And the check that runs after it has left

A bank connection can drop after the request has already gone out, and then the honest answer is that nobody knows yet. Tresora does not send it again on its own. The run parks, the order says why, and a person confirms with the bank what it actually received. Paying a supplier twice is worse than paying them late.

The answer back

How do you know the bank actually paid it?

Because the bank says so twice, and both answers land on the same order. First the status report, per instruction, carrying the bank’s own reason when it refused one. Then the debit itself, on the statement, matched back to the order that caused it.

Payments reconciliation · today

Instructions sent

204

In 5 files, one per account

Accepted by the bank: 202
Rejected, with the bank’s reason: 2

Matched to the debit · 197 paymentsEUR 4,206,800

The bank’s status report: pain.002, read per instruction rather than per file: accepted, accepted with a change, or rejected with the bank’s own reason code and the text it sent alongside.
The debit on the statement: camt.054 where the bank sends one, and the statement line itself on camt.053, MT940 or whatever that bank uses. This is the event that proves the money left, and it is not the same event as the acceptance.
The match back to the order: On the references that traveled with the file: the end-to-end id, the instruction id, the UETR, the bank’s own transaction reference. What the bank did and what your ledger says stop being two questions with two answers.

A rejection does not vanish into an inbox. It stays on the order with the bank’s reason on it, and the position, the forecast and the close all keep counting that money as unpaid — because all three are reading the same order rather than a copy of it.

Around the desk

Who works in this every day?

Three desks, three different screens, one run. Shared services builds it and resolves whatever a check held. Treasury releases it and watches the answers arrive. The controller never opens it and still sees the result, because the debits it produced are already matched when the close starts.

Who it is for

What it reads from and feeds

Before you ask

The questions this module always gets.

01Can Tresora send payments to our banks?: Yes. That is what the module is. Tresora builds the instruction, carries it through the approvals your policy requires, and sends it to the bank over the channel that bank uses. The funds stay in your own accounts under your own agreements, and nothing is sent that you did not approve.
02Who decides the approval path?: You do, and you change it without us. The steps, the amounts they bite at, which roles sit on them and who may release are all configuration. Every change to any of them is recorded on Authorization Changes, with the person who made it.
03Which payment formats and channels do you use?: pain.001 for SEPA credit transfers and every other ISO 20022 bank, pain.008 for direct debits, and MT101 where a bank prefers it, over EBICS, SWIFT, host-to-host or the bank’s API. Status comes back on pain.002 and the debit on camt.054 or the statement itself. If one of your banks wants something else, we add it.
04What happens when a bank rejects one?: The rejection lands on the order with the bank’s own reason code, and the order stays open. Nothing is retried on its own. Your position and your forecast keep that money as unpaid, because they read the same order rather than a report about it.
05Can somebody who sees the cash position release a payment?: Only if you gave them that right. Viewing and releasing are separate rights on Roles & Permissions, and a person can hold either without the other. Every release is written to the Activity Log with the name of whoever made it, and so is every change to who holds which right.

Bring one run you already made.

Send us a payment run you sent last month and the files your banks answered with. We will show you that same run here: the approvals it would have needed, the order a check would have held, and the confirmations landing back on it.

Request a demo See the whole product

Nothing is sent to your banks during a demo. The module is switched on when you say it is.