This article is written by Nomentia
With complex global operations, decentralized ways of working across treasury, finance, and accounting, a lack of process automation, and security concerns on the rise, you may be considering a payment hub for your enterprise. When juggling multiple priorities and all the operational tasks already stretching your organization, the implementation project may seem dreadful.
It’s not a secret: Setting up a payment hub can be heavy-duty. Depending on the complexity of the case (number of entities enrolled, in which countries you roll it out, how many banks and bank accounts you have, whether you connect multiple ERPs, etc.), it may take anywhere from several days to several years. Nevertheless, if it’s done right, the payment hub can have significant business impacts—not just in improving ways of working but also in realizing cost savings.
To explain how to set up a global payment hub on an enterprise scale, we will go through the main challenges, the project team and its setup, ways of working, lessons learned from our customers, and the benefits and business impact after the successful implementation.
All payment hub projects are different. While we have been working on small projects where we only connect one ERP and a few banks, and it only takes days to a few weeks, we have also been delivering large-scale projects for enterprises that could take even as long as one to two years of commitment. Whenever we undertake a massive project, both parties understand that it’s a long commitment and, therefore, a forward-looking project plan is essential.
The challenges of implementing a payment hub are unique for each organization, but in our example, we will focus on the complex, enterprise-scale implementations where clients were dedicated to creating a payment factory within their organization. Keep reading even if you are implementing a less complicated solution, as the article gives some great insights for planning any payment hub implementation.
Many Nomentia clients have undertaken massive payment hub projects with operations in over 100 countries. Even just operating in tens of countries has its challenges. If you must implement the payment solution in countries with strict legislation, like China or India, having a good implementation partner with experience is an advantage.
Why do global operations make implementation complicated? One reason is integrating ERPs, financial systems, and banks. The other reason is more abstract: people generally don’t like change.
It’s not unusual for local entities to have their own operational procedures; the process can also often be highly manual, if not entirely manual. In some cases, an integration between the internal system and the bank, like an ERP, may exist to execute payments automatically. Still, on a group level, you may have very little visibility on this. In addition to having localized operational procedures and local systems, each country and entity may have its own banking partner. Later on, we will discuss how working with many banks can complicate implementation.
Moving away from the current ways of working comes as a big shock for many, even though you are trying to implement improvements that can benefit everyone. If you want to implement an immediately successful project, you must involve all necessary stakeholders in managing the change and getting the essential project-planning information.
Based on our first challenge, you may have already guessed the next one: A scattered system landscape can make the implementation project complex. If you have acquired new units from different regions, it’s possible that instead of running the business on one central ERP system, you have several ones used locally. Payment files may also be generated in other systems. If system consolidation is not currently possible, you should at least connect all source systems to the selected payment hub, allowing the payment files to be automatically forwarded to the correct bank.
Having a scattered system landscape naturally poses a few challenges:
In an enterprise-scale project where tens of entities are involved, having good change management practices, ways of communication, and clear guidelines will set you up for success.
The new payment hub will impact how hundreds of people work daily; at worst, moving from manual processes or local ways of working to a centralized, automated approach could be something people may even fear or be concerned about.
Communicating how your operations will change positively when you introduce the new processes will help people perform their jobs well and make them feel involved in the project from day one. Your colleagues can also be great allies when you need to understand how to work with different banks globally.
Choosing your team is the most essential part of the project! You don’t need a big team, but you should include people who understand your financial processes, how they work now, and how they should work when you automate them.
Also, involve an excellent project manager to communicate with the payment hub provider, keep the project on track, and hold people accountable for the progress.
Having one or two IT resources can also be helpful throughout the project. As you deal with integrations, although the payment hub vendor usually takes care of most of the integration work, your IT team members will still need to help the vendor, participate in the end-to-end testing process, handle master data management, and provide all the necessary technical details.
It’s also a good idea to clearly outline the ways of working for your project team. Identify the core team, the communication channels for sending each other instant messages and following the progress, your meeting cadence, and where you will share information with the larger group.
‘Not all banks are the ‘same’—this is some of the best advice for when you start a payment hub project. Before you even begin, you must have a list of the banks you will need to connect with, and your local employees should be able to help point out the unique challenges with each (e.g., if the bank would not accept standard payment file formats and you would need to convert the file your ERP generates).
The list will also help you identify the best ways to connect with the banks, whether you create direct connections, use SWIFT, or have specific local connection requirements.
In your implementation plan, schedule plenty of time for setting up the bank connections. It is usually more challenging than creating connections with ERPs; in the case of the ERP, your IT team can control the pace. With banks, many factors are out of your hands, and sometimes, all you can do is wait or comply with the requests from the bank.
It’s tempting to create a very tight project timeline. In a recent survey, our client said smart time management positively impacted their implementation project.
‘Be wise and flexible; you can avoid delays in the projects, and you will have the flexibility to realize quick wins during the project, like adding different types of payments.’
Of course, delivering the project as soon as possible is still a priority, but leave room for surprises (e.g., when you deal with longer timelines than expected with the banks) and time for experimenting; maybe you will be able to realize a few unexpected features during the implementation project. Solution consultants from vendors will normally guide you almost effortlessly when you can implement a feature, even if you haven’t planned it before.
Companies come to us with different reasons why they would like to implement a payment factory. A very common theme is automation – in some cases, we are taking the client from 100% manual processes to almost 100% automation. (You can’t always avoid manual payments, but it’s still possible to process them through the payment factory, and that’s what manual payment templates are for.)
In many cases, having more control over outgoing payment processes is the main priority. The group wants more control over all payments, and centralization is the theme we need to focus on. The opposite can also be true, though: In one case, our client wanted to implement a payment factory but without centralization. They wanted to use one tool for all of their entities but still allow them some freedom in executing their payments.
Another emerging theme is, of course, security and compliance. As fraud increases, CISOs/CIOs often push the Treasury Department to implement a payment factory. Thus, most major providers offer two capabilities vital for the CISO office: fraud detection (often utilizing AI or a rule-based engine) and audit trails for every transaction.
Regardless of your priorities, you will most likely realize some of the following business impacts:
Even if you are not going for a centralized approach, you will have a tool that all global users can use to execute payments. If your goal is centralization, having a payment hub between your banks and systems will standardize the process and improve productivity in all units.
A scattered system landscape can become expensive for an enterprise. By integrating all ERP systems and financial software into the payment hub, you can achieve complete automation. The payment hub can fetch payment files from the different systems and send them to the correct bank. Depending on the size of the project, clients have reported that integrating all their IT systems where payment files are located can result in hundreds of thousands of savings.
Managing bank accounts takes time and effort. As a positive outcome, most of our clients are closing bank accounts and, thus, realizing savings from tens of thousands to over one hundred thousand euros.
A standardized way of working equals compliance. Adding audit trails, security measures like MFA, and the six-eyes principle are just the basics. Forward-thinking teams are investing in automated fraud detection and erroneous payment prevention to reduce the chances of payment fraud and errors that have increased over the last few years.
While reducing the number of FTEs should not be the project’s ultimate goal, at least you won’t be hiring people to do mundane manual tasks, and your workforce can focus on more critical projects, like forecasting future cash flows. This will also transform the role of your department within the organization. You will be able to take the department from an operational role to that of a strategic advisor if that’s your priority.
Implementing a payment hub on a global scale in tens of countries for tens of subsidiaries and hundreds of users is a large undertaking. It will require excellent project and time management and an exceptionally dedicated team. Establish a common goal initially, and make sure everyone knows their role and why the project matters. Also, for the implementation to succeed, you must choose the right supplier. The payment hub supplier should provide a payment hub with all the functionality you need to manage your payments. Still, in addition, they should be able to support you with IT integration, bank connections, project management, and communication. Working with a payment hub provider that fits your team well is very important because you will spend a lot of time together in weekly meetings. Choosing the best partner may involve more than just finding the best technology.
The best approach ultimately depends on your organization and requirements. Some clients start with creating a payment factory, knowing they will continue the project and create an in-house bank and moving away from working with hundreds or thousands of bank accounts, using internal accounts instead, implementing a POBO and COBO approach, and even managing intercompany loans in an in-house bank.
Some may want to implement something other than an in-house bank, and they can manage their cash flows very well with just a payment factory and add liquidity management to complement the service and forecast your company’s cash balances based on accurate data from the payment hub.
Whatever your approach is, setting up a payment hub can be a significant change for the better if you are not yet automating your payments on a global scale.
Treasury Masterminds is a community of professionals working in treasury management or those interested in learning more about various topics related to treasury management, including cash management, foreign exchange management, and payments. To register and connect with Treasury professionals, click [HERE] or fill out the form below to get more information.
By Alex Cannon
Across 111 European public tenders for treasury systems, training is named in 47% of notices. The highest-ranked treasury capability is FX and hedging, at 13%.
uropean public bodies have to write down what they want from a treasury system, in public, before anyone can bid.
It all gets published on TED, the European Union’s procurement journal.
I looked at 111 notices, published between May 2018 and October 2026.
Training appears in 47% of them.
After that, the highest-ranked treasury capability is FX and hedging, at 13%.
A product that a qualified professional cannot operate without a course has been designed badly.
This market has stopped treating that as a defect and started pricing it in instead.
Some training is unavoidable. A treasury system touches bank mandates, approval limits and payment files and no amount of good design removes the need to show a new user how a particular organization has set those up.
A degree in the domain, 40 hours of instruction and a consultant on call is not that. That is a product nobody can learn by using it.
The newer products in this category are not like this. You open one, click around for an afternoon and it explains itself.
So why are buyers still signing for dinosaur software and then signing again for somebody to explain it?
Nobody buying a treasury system is new to treasury.
The people who will use it know what a forward contract is, what a cash position is, which balances get swept at the end of the day.
The training in these notices is not teaching them their job. It is teaching them the product.
What they are paying to be taught is where things are, what the screens are called, which order the steps go in and what the system wants before it will let you do the obvious thing.
The European Central Bank bought its treasury management system in 2018 for €16,534,744. Since then it has signed two consultancy frameworks for that same system: €7m in 2020 and €11.7m in 2025.
That is €18.7m to be helped with a system it paid €16.5m for. The advice has outgrown the software, at an institution staffed with some of the most qualified treasury professionals in Europe.
A degree in the domain, a budget to learn the software and consultants on retainer for the parts that stay unclear.
Does nobody else find this strange?
| Share of 111 | |
|---|---|
| Training | 46.8% |
| Cloud or SaaS delivery | 21.6% |
| FX and hedging | 12.6% |
| ERP integration | 12.6% |
| Cash flow forecasting | 10.8% |
| Debt and investment | 10.8% |
| Reporting and dashboards | 10.8% |
| Multi-entity groups | 8.1% |
Nobody writes “this software is confusing” into a procurement document.
You can write 40 hours of training into a contract. You can name a number of sessions, a count of on-site days, a trainer’s qualifications. All of it is enforceable, it survives legal review and a bidder can put a price on it.
You cannot write “make it obvious” into a contract.
So the learning curve gets stated in the only currency procurement accepts, which is people and days. Training tops this list not because treasury teams want courses, but because it is the one line where a buyer can put a number on the distance between signing and competence.
Score time-to-competence. Half your peers write training into their requirements.
If “how long until my team runs this without you” is not a line on your scoring sheet, you are scoring a different purchase than the one you are making.
The demo is run by the person who wrote the training. Ask what the fifth week looks like for somebody who wasn’t in the room.
And read a few notices yourself.
Public bodies publish requirement sets at a level of detail corporate buyers keep private, written by people who had to think a whole project through before they were allowed to publish anything.
Public tenders look like an open door. They mostly are not.
A public buyer has to justify the decision in writing, to people who were not in the room.
That incentive produces the oldest reflex in enterprise software: nobody ever got fired for buying IBM.
The notice encodes it, through reference requirements, revenue and insurance thresholds, years of comparable deployments and a scoring sheet that rewards the familiar answer.
Nearly half of the treasury software awards that reported a bid count drew a single bid, which is the sound of a decision made before publication.
Unless you hold something specific, an existing relationship with the buyer, a local presence the notice requires, a capability in the specification few others can meet, bidding is an expensive way to lose.
What is useful in these documents is not the opportunity. It is the requirement set, telling you what the incumbents are being paid to compensate for.
None of this is the consultants’ fault. If a system takes a month to explain, somebody is going to get paid to explain it.
That is real work and there is real demand for it.
What I keep coming back to is how calmly it gets signed off. Nobody at the ECB had to argue that the treasury system was hard to use. The money went through as consultancy, twice, five years apart and the word “confusing” never had to appear in a document.
So if you are building in this category, that is the number to look at.
You do not have to beat them on functionality. You have to be the system a treasurer can open on Monday and use by Wednesday with nobody sitting next to them.
Treasury Masterminds is a community of professionals working in treasury management or those interested in learning more about various topics related to treasury management, including cash management, foreign exchange management, and payments. To register and connect with Treasury professionals, click the button below.
This article is a contribution from our content partner, PrimeTrade
I never would have thought, at the start of my emerging career as a trade banker, supply chain financier and potential “Master of the Universe” (per Tom Wolfe), that debit notes would be interesting, and that thirty years later I might be writing a blog about them.
But here we are!
It is quite a long post, but this is a topic that merits a detailed treatment, even if the subject matter is rather dry and somewhat technical.
This post sets out five myths about invoices and debit notes.
These myths can lead to various confusions, complications and inefficiencies when it comes to supply chain finance.
The post aims to set out clearly how things normally work in the real world of general ledgers and corporate ERPs. It also digs into the implications for SCF and for the design of platforms that help suppliers to access supply chain finance.
There are generally three strategies used to deal with debit notes in supply chain finance – and these are covered in the final section.
With the right design and approach, debit note recovery can be automated and fully-optimised – no more spreadsheets, no more manual tracking, and no need to get suppliers to deduct debit notes from future invoices.
A debit note acts as the evidence in the buyer’s books for a reduction in its expenses.
So it is issued by the buyer’s accounts payable team to a supplier when the buyer seeks to pay less than it has been invoiced.
For supplier financing transactions (including SCF), a debit note can be an unwelcome event. If an invoice has been financed and even purchased by a financier, the financier typically relies on the invoice being paid in full.
What if I told you that “invoices always get approved”?
A valid invoice is one that is properly addressed, is from a recognised counterparty (ie: a supplier), has the right taxes on it shown in the right way, and which adds up correctly.
Valid invoices always get approved and there is a good reason.
This is a fundamental part of the way financial controls work. A valid invoice has been received representing a claim for payment from a supplier and it will be posted in full to the general ledger.
If this didn’t happen, we would get in a mess very quickly. Accounts payable teams cannot use their discretion and post valid invoices to the general ledger with whatever numbers on them they decide might be right.
Audits would be failed and financial controls would have broken down.
If the invoice from the supplier is for an amount that is too high (for whatever reason), a debit note is raised by the buyer so the supplier gets less money. The question is “what’s the debit note?” not how much of the invoice should be approved.
Some accounts payable teams will, alternatively, ask the supplier to raise a credit note and the invoice remains pending and not posted until the credit note is received. Here, for ease of explanation, we assume the debit note route is the one that the accounts payable team uses.
In the ordinary course of business, accounts payable teams in corporate clients approve payments and not invoices.
A few key points:
This makes supply chain finance and supplier financing tricky – since bankers and lawyers like to think in terms of transactions rather than balances.
Bankers purchase invoices not balances.
Debit notes do not conveniently fit into this model.
Whilst the corporate client may be settling a balance that is due to a supplier (invoices less debit notes),
bankers want the invoices that they have purchased to be paid in full to them.
This is also one of the two main reasons why many corporate clients operate an all-or-nothing model with suppliers when it comes to supplier financing.
These two reasons mean SCF programs can lose a lot of agility. There’s no easy way to move suppliers between financiers, and no easy way to have dynamic management of funding, switching suppliers between financiers whenever needed (even daily) to optimise the use of limits and mix in own treasury funds as a funding source.
I made a statement earlier about “valid invoices always being approved”.
The key question for the accounts payable team when they are deciding what the supplier might be owed is not how much of the invoice to approve.
The key question is: how big should the debit note be?
Yes, that’s right. The full amount of a valid invoice is always posted to the ledger but if there is a reason to pay less than the full amount, then a debit note needs to be raised.
The questions being answered by the accounts payable team reviewing purchase orders, delivery paperwork and the invoice (ie: the 3-way match) are (a) whether a debit note should be raised and (b) how much it should be for?
For example, the invoice face value is 100, but there is a shortage on the delivery of value 5. So that means the invoice of 100 is posted to the ledger, and a debit note of 5 is created and posted – and 95 is the balance on the supplier account, which is what will be settled in due course.
As stated above, the general ledger is an account-based (ie: balance-based) system.
The supplier account is credited with the full amount of the invoices and debited with debit notes to reach the correct amount that should be paid to the supplier when a payment run is operated.
So what is the bank buying when it provides supplier financing?
Is it an “approved payable” (an invoice that is net of specified debit notes) or is it an “approved invoice” (due at face value without deduction)?
This is a key documentary point and one which might not always be clear in the paperwork used to support supply chain finance. On the one hand, the bank wants to buy invoices free and clear of any debit notes. On the other hand, the corporate client may well want the ability to net pre-existing debit notes (at the time of financing) against those invoices.
Is the IPU for the same amount as the invoice? What exactly is the claim that the bank is buying and relying on here – the invoice or the payable amount (at IPU creation-time) in relation to each invoice? If the supplier financing is documented on the basis that the bank is buying the IPU (and not the invoice) – query the accounting treatment and whether the arrangement might then become financial indebtedness in the books of the corporate obligor?
Debit notes “sort of” relate to invoices – but this is an artificial construct and not one that is required in the ordinary course of business.
Companies typically want to collect claims (debit notes) against suppliers immediately. Why wait?
Invoices are posted with a due date (in the future) that reflects when the amount claimed by the supplier should be paid.
Debit notes are often posted with an immedate due date.
That means debit notes are usually collected by set off against the next amount due to be paid to the supplier – ie: as soon as possible. There’s no waiting.
That would be the case even if the debit note might relate to a delivery where the invoice(s) for that delivery are not due to be paid for many days.
And debit notes may also arise that are wholly unconnected with individual deliveries – for example, where there are volume rebates or programme-wide discounts to be recovered.
As mentioned above, settlements clear the due portion of the balance outstanding on the supplier account.
The settlement is calculated by adding up all the transactions that are due and ignoring future-dated transactions. The debit note is always due immediately and is included as soon as possible in any payment that is made to the supplier. The invoice may be due in the future and has to wait.
The idea that this specific debit note goes with that specific invoice is typically a myth when it comes to the practical reality of payables and settlements.
Most platforms ignore debit notes. These are “someone else’s problem”.
That’s why many accounts payable teams don’t like supply chain finance and specifically prefer to limit the size and scope of programs to a handful of large suppliers.
And many SCF platforms ignore debit notes completely.
Corporate clients are expected to provide them with a nice and tidy file of “approved payables” which are guaranteed to be paid in full no matter what else may be going on.
This makes life easy for the platform and easy for the bankers and lawyers involved.
But this also makes life complicated for the corporate accounts payable team.
If clean “approved invoice” or “approved payable” files are to be provided to the SCF platform, this typically means that:
This can mean that many clients end up failing to collect all the debit notes that they might claim, or end up having to track debit notes manually in excel and away from the general ledger. This all leads to extra work for everyone, compromising financial controls and adding costs and complexity.
Yes – it requires a modern approach to the way that the supply chain finance platform is developed and operates.
There are three approaches:
Treasury Masterminds is a community of professionals working in treasury management or those interested in learning more about various topics related to treasury management, including cash management, foreign exchange management, and payments. To register and connect with Treasury professionals, click the button below.
This article is written by our partner, Cobase
Oracle NetSuite is a cloud-based ERP platform designed to bring core business processes together in one environment, spanning financial management, reporting and consolidation as well as areas such as billing, projects, CRM and operations. Its multi-entity and multi-currency capabilities make it particularly relevant for organisations whose financial complexity increases as they expand internationally.
Around the core ERP sits a broad ecosystem of implementation partners, technology providers and integrated applications. As companies scale, this ecosystem becomes increasingly important. The ERP may sit at the centre of the finance architecture, but it also needs to connect effectively with the wider financial landscape, including banks, payment providers and other specialist applications.
One of the partners operating in this ecosystem is Novutech, a European finance transformation and NetSuite specialist supporting growing and international organisations with ERP implementation, integration and optimisation.
We spoke with Marta Obrador, Director, Business Transformation Practice & UK Lead at Novutech, about the type of companies NetSuite is best suited to, what makes ERP transformations successful and why bank connectivity should be considered as part of the wider finance architecture.
What type of companies are the best fit for NetSuite, and what makes the platform stand out from other cloud ERP solutions?
“For me, the best fit is really a company in motion: a business that is scaling quickly, expanding internationally or simply dealing with increasing financial complexity.
As organisations add entities, markets and currencies, finance needs more structure without creating more fragmentation. That is where NetSuite is particularly strong. It gives companies a single cloud-based foundation for financial management, consolidation and broader operational processes, while still giving them room to grow.
What matters is that finance teams gain the structure and visibility they need without having to redesign the whole environment every time the business changes.”
As an implementation partner, where do you add the most value and what do successful ERP projects tend to get right from the start?
“Our value lies in connecting people, processes and technology. An ERP project is never only about implementing a system. You also need to think carefully about how people will use it and how the processes around it should work.
The strongest projects usually get a few fundamentals right early on: clear ownership, good-quality data, the right integrations and, importantly, clear priorities.
I also think focus is critical. Companies sometimes try to solve everything at once. The better approach is to focus on what really matters, make good use of best practices and build a realistic path to adoption. That creates a much stronger foundation for the transformation.”
How are customer expectations around finance and treasury changing, and what does that mean for the role of the ERP?
“Finance is moving away from simply recording what happened in the past. Teams are increasingly expected to provide insight, support decisions and help shape what happens next.
That changes the role of the ERP as well. It needs to become a trusted platform for decision-making, not just a place where transactions are recorded.
At the same time, the ERP cannot operate in isolation. If you want finance processes to become truly efficient, it also needs to connect well with banks, payment processes and the wider finance technology landscape. That is where the conversation increasingly moves from ERP alone towards a more connected finance architecture.”
Where does ERP-to-bank connectivity typically become challenging, particularly for companies operating across multiple banks and countries?
“The real challenge is not usually connecting to one bank. Complexity starts to build when a company has several banks, entities, countries, accounts and payment formats, but still wants one consistent process.
Without the right connectivity layer, that complexity often ends up with the finance team. People are moving between bank portals, uploading or downloading files, fixing exceptions and reconciling transactions manually.
As the organisation grows, that becomes increasingly difficult to scale. You may have implemented a strong ERP, but if the banking side remains fragmented, a lot of manual work still remains. Ideally, you want to abstract that complexity away from the finance team.”
What does a strong ERP-to-bank setup look like to you, and what should companies consider when designing it?
“For me, a strong setup creates one trusted flow from payment creation in the ERP through to bank execution and then back into reconciliation and reporting.
Automation is obviously important, but it should never come at the expense of control. You still need clear visibility, the right approvals and enough flexibility to support how the organisation operates.
Companies should also think beyond the situation they have today. If you know you are likely to add entities, countries, banks or accounts, the architecture needs to support that. It is much better to design connectivity as part of the overall finance architecture than to keep adding separate bank interfaces over time.”
Why do you like working with Cobase, and what does combining your ERP expertise with Cobase’s banking connectivity bring to customers?
“What we like about the combination is that it extends the value of NetSuite beyond the ledger and into the day-to-day banking and treasury processes.
NetSuite provides the financial core, while Cobase creates a consistent connection between that core and the banking landscape. For internationally growing companies, that is particularly relevant because the number of banks, accounts and entities can increase quite quickly.
Customers should not have to choose between having a strong ERP and having strong banking connectivity. By combining our NetSuite and transformation expertise with Cobase’s multi-bank connectivity, we can help create a finance architecture that is much more connected and scalable.”
Treasury Masterminds is a community of professionals working in treasury management or those interested in learning more about various topics related to treasury management, including cash management, foreign exchange management, and payments. To register and connect with Treasury professionals, click the button below.
