Why Payments Should Run Through Your TMS Instead of Your ERP

Most companies create payments in their ERP, and many send them to the bank from there too. Whether your team exports a payment file into a bank portal or runs an ERP bank integration built by IT, the ERP is doing a job it was never designed for. It knows what you owe. It was never built to manage the connection to each of your banks.

This is the payments question treasury teams ask most in our TMS demos. When teams weigh a treasury management system vs ERP for payments, the answer comes down to which system each job belongs in. The ERP decides what to pay. A treasury management system (TMS) gets those payments to every bank under one set of controls and brings back what each bank did with them.

Bank connectivity was never the ERP’s job

Every bank has its own file formats and its own rules for what a valid payment looks like. Connecting an ERP to a bank means your IT team builds that connection with the bank and maintains it for as long as you bank there. Each new bank is another build.

Many ERPs can’t connect to bank APIs at all, so they rely on files. Tools like SAP’s multi-bank connectivity give you a channel to the bank, and your team still has to build and maintain what goes through that channel for each bank.

A TMS vendor maintains those connections for every customer on the same bank. The work your IT team would do once for your company, the vendor does once for all of its clients, and keeps doing as the banks change.

Bank formats change more often than ERP teams expect

Banks update payment formats on their own schedules. The move to ISO 20022 across the major payment rails added new required fields, including more detailed beneficiary address information, and some banks now reject payments that leave those fields out.

Each change means someone updates the mapping and tests it with the bank before the bank’s deadline. In an ERP integration, that someone is your IT team, and payment formats are one of many priorities on their list. In a TMS, the vendor updates the mapping once for each bank and every customer on that bank gets the change.

One approval workflow can cover every bank

Each bank portal has its own approval flow and often its own security token. A company with five banks has five approval processes to train people on and five sets of entitlements to maintain.

A TMS applies the same approval rules to every payment, at every bank and every entity. Trovata TMS supports multi-level approvals and multi-factor authentication (MFA) on release. Approvers can sign off from a mobile device, and teams can add bank-specific rules where a bank or entity needs them. Every payment keeps its approval history and supporting documents in one audit trail.

Approvers in the TMS don’t need to mirror the entitlements set up in each bank portal. Teams set entitlements up during implementation and manage them in the TMS from then on. When someone leaves the company, their access comes off every bank in one step. Many teams also use the move to cut the number of people who hold portal access at all, which reduces fraud exposure.

The TMS connects to the bank directly

Treasury teams often ask whether sending payments through a TMS bypasses bank security. It doesn’t. A bank portal is one front end the bank offers its customers. A TMS sends payments through a separate direct channel into the bank, and banks process payments from these channels every day as instructions their customer has approved.

The direct connection also removes a weak point. Exporting a payment file from the ERP and uploading it to a portal leaves a file sitting on someone’s computer or a shared drive, where an account number can be changed before it reaches the bank. A TMS sends the approved payment straight to the bank with no file for anyone to open in between.

A payment sent is different from a payment confirmed

Many ERP setups mark a payment as paid the moment the file goes out. The bank hasn’t confirmed anything at that point. It may still reject the payment for a closed account or missing beneficiary information, and the ERP will keep showing it as paid.

A TMS tracks each payment through the statuses the bank sends back, from sent to acknowledged to confirmed, and stores the confirmation reference, such as a Fed reference number for a wire. Rejections show up with the bank’s reason. Those statuses can flow back to the ERP so it clears the payment only once the bank has confirmed it. Confirmation timing depends on the bank, and it ranges from seconds to several minutes.

That changes who answers the question of where a payment is. Your AP team and your suppliers get the answer from the system instead of from someone in treasury logging into a portal.

Payments cover far more than real-time rails

Real-time and API-based payments get a lot of attention, and they’re one part of what treasury sends. Most companies also send ACH batches and wires, and many send SWIFT, SEPA, CHAPS, or direct debit payments across borders.

A TMS that only supports API payments covers the banks and rails that offer APIs and leaves everything else in the portals. Trovata TMS sends payments across ACH, wires, SWIFT, SEPA, CHAPS, direct debit, and other international rails, using API, file, and SWIFT connections depending on what each bank supports.

The ERP stays in the process

Moving payments to a TMS doesn’t remove the ERP. The ERP still holds your vendors and invoices and builds the payment run. It sends that run to the TMS through one interface, and the TMS handles every bank from there. Confirmations and remittance details flow back to the ERP.

When a payment is rejected, your team fixes the details in the ERP, where the vendor record lives, and resends it. That keeps the ERP as the system of record for what you owe and keeps the TMS as the system of record for what the bank did.

Teams don’t have to move everything at once. An ERP-to-bank connection that works well today can stay in place while the harder banks move first, and many teams start with wires before they move AP batches.

The case gets stronger with every bank you add

With one bank and a small team, the portal may be enough. Each additional bank adds another integration for IT to maintain, another approval flow, another set of entitlements, and another place to check when a payment goes missing. New entities and new countries add to that work faster than most ERP teams can absorb it.

Two signals tend to show up first. An ERP bank integration breaks every time a bank changes its format, and payment status questions land on treasury because nobody else can see what the bank did.

Want to see how your payment workflow would run through Trovata TMS? Schedule a demo. For more questions to bring to your evaluation, read 26 Questions to Ask in Your Next TMS Demo.

Frequently asked questions

What is the difference between a treasury management system and an ERP for payments?

An ERP decides what to pay, and a treasury management system gets those payments to the bank. The ERP holds vendor records and builds the payment run. The TMS manages the connection to each bank and tracks what the bank does with each payment.

Can an ERP send payments directly to banks?

Yes, and it takes an integration your IT team builds and maintains for each bank. Many ERPs rely on file transfers because they can’t connect to bank APIs, and every bank format change requires an update on your side.

Does sending payments through a TMS bypass bank security?

No. A TMS sends payments through a direct channel into the bank, and banks treat payments from that channel as approved instructions from their customer. Approval rules and MFA are enforced in the TMS before the payment leaves.

Do TMS approvers have to match the approvers set up at each bank?

No. Entitlements are set up during implementation and managed in the TMS from then on. That lets one approval workflow apply across every bank and lets you remove a user’s access to every bank in one step.

What happens when a bank rejects a payment sent from a TMS?

The rejection appears in the TMS with the bank’s reason. Your team corrects the details in the ERP and resends the payment, and the ERP clears it only after the bank confirms it.

Do I have to stop using my ERP for payments to use a TMS?

No. The ERP still builds the payment run and sends it to the TMS through one interface. Teams can move banks and payment types in stages and keep an ERP-to-bank connection that works well.

Which payment types can a TMS send?

It depends on the TMS. Trovata TMS supports ACH, wires, SWIFT, SEPA, CHAPS, direct debit, and other international payments through API, file, and SWIFT connections.