How to improve payment security for treasury & finance teams

This article is written by Nomentia

Most larger companies process hundreds, if not thousands, of outgoing payments every day. These payments are crucial for the business and must be handled accurately and punctually. Yet, as the number of payments increases, their management can become challenging. Particularly when dealing with tens or even hundreds of bank accounts. Oftentimes, treasury and finance teams have to deal with a layer of complexity when they need to improve payment processes. To protect themselves against payment errors, fraud, or making payments to sanctioned beneficiaries. Which often requires implementing payment security process controls and other security measures.


In this article, we’ll talk about why it’s critical to have secure payment processes in place. What threats could your organization be facing. And how treasury and finance can tackle payment security within their own scope of work. While keeping processes as efficient as possible. As a bonus, we’ll provide a fraud risk management framework that can make dealing with process improvements less overwhelming.

Join the treasury forum at Treasurymastermind

Why are payment security and controls more relevant than ever before?

Financial scams are often directed towards treasury and finance teams, making these teams important stakeholders in payment security projects. In collaboration with IT and security professionals, they play a crucial role in ensuring payment security. Trustpair, SAP, and Accenture, payment did a survey that showed payment security is a top priority for finance and treasury professionals. With the increase in incidents of fraud and cyberattacks, companies can no longer ignore payment security. As a result, most teams are now actively reviewing their organizational processes to enhance safety. The survey also revealed that 56% of US-based companies fell prey to payment fraud in 2022.

IN 2022, 56% OF US COMPANIES HAD STILL FALLEN PREY TO PAYMENT FRAUD.

TREASURY & RISK SURVEY COMMISSIONED BY TRUSTPAIR & GIACT

The research study revealed that treasurers expect banks and system providers to take active role fighting against fraud attempts. To meet this growing demand, many advanced payment and TMS vendors have developed solutions to enhance payment security.

Differentiating between the types of payment issues that can occur

Even though some solutions provide the full suite of technical features for tackling payment errors, sanctions, and fraud. It is still important to differentiate between the security threats treasury and finance face because they require different approaches. Let’s consider some of the most common threats that can occur:

  • Erroneous payments: are typos, wrong amounts, double payments, or other errors that can occur while making payments.
  • Sanctioned beneficiaries: are usually payments processed to sanctioned beneficiaries that should not be allowed.
  • Internal fraud: could be employees with payment permissions who make fraudulent payments on purpose.
  • External fraud: some of the major trends include phishing, wire transfer scams, and invoice fraud where criminals trick employees into paying them.
  • Account takeovers: usually a hostile account takeover where an unwanted person can access a company’s payment systems to transfer money.
Payment issues overview

What belongs to payment security from a treasury and finance perspective, and how can you tackle it?

The question remains: what is really included in payment security from a treasury and finance perspective? And which threats can actually be fought by them? This can vary greatly, depending on the organization. The experience of teams, and the policies treasurers have established regarding security, among other factors. Different treasury professionals may have different opinions on what payment security entails. However, we have noticed some common themes that treasurers at our clients focus on from a technological standpoint:

Avoiding erroneous payments

Manual processes are susceptible to errors, particularly when they are performed repeatedly, leading to handler fatigue. This commonly results in erroneous payments through typos, outdated vendor master data, or mixing up beneficiaries, for example. These errors can be compounded over time. Resulting in time-consuming efforts to correct them, such as liaising with all involved stakeholders or seeking assistance from banks.

“MASTER DATA IS CRITICAL FOR PROCESS CONTINUITY. DATA ARE ASSETS, AND IF WE TALK ABOUT MASTER DATA, THAT IS REALLY A KEY ASSET, AND YOU NEED TO MANAGE MASTER DATA LIKE YOU MANAGE OTHER KEY ASSETS.”

MARK ROELANDS, RISK & COMPLIANCE CONSULTANT, GRC CONSULTING

An automated payment system, connected between your ERP and banks, can keep your master data automatically updated. And also, avoid outdated information. You can also avoid errors by setting up rule-based process controls. Or automated matching processes for reconciling financial records with bank statements. For larger single payment sums, double verification by a second person can be helpful in preventing errors.

Ensuring payments aren’t sent to any sanctioned beneficiaries

To comply with regulations and ensure security, most companies must check their payments against unwanted beneficiary lists. This can be achieved by verifying payments against public lists like OFAC’s, EU’s, and other institutions. As well as private blocklists or allow lists. As world politics continue to shift, these lists keep evolving, and hence, they need to be updated regularly.

Manual sanctions screening, i.e., uploading and downloading spreadsheets against sanction databases,. Or manually searching lists each time a payment batch is processed, can take a lot of time. Therefore, our customers have found that sanctions screening is most suitable as an automated step of a payment process flow in a payments hub every time payments are executed.

Preventing fraudulent payments

Fraud is a recurring topic for many companies and is challenging to spot when hundreds of daily payments go out to various stakeholders. However, preventing fraud is critical, as the losses can affect cash flow and liquidity planning. Organizations must tackle multiple types of fraud, each requiring a slightly different approach. 

Some of the most common frauds are wire transfer scams, phishing, and fake invoicing. On the one hand, most of these derive from human vulnerabilities; hence, you should educate employees to identify such fraud. On the other hand, intelligent payment technologies can recognize some of these irregularities as they stand out from ordinary payments. By scanning vendor master data automatically, for example. And, of course, larger payment sums should always be verified by several people. So that the financial loss is not too significant.

To avoid internal fraud, users should be given limited rights in payment processes. There should always be several people checking payments regularly. And the consequences of fraud should be made clear in Treasury policies to avoid any ambiguity.

Ensuring that payment processes are standardized and creating company-wide visibility

Most companies we help have many local payment operations worldwide, where processes and systems can differ per location. This usually leads to a lack of transparency over processes and security, even the cash flow, on a group level.

In some cases, our customers want to centralize payments to a group-wide level. And have global processes enforced. In other cases, local entities still have more responsibilities. In most cases, companies want to use the same payment technology to tackle global payments, and the solution is rolled out country by country until all entities use the same system. A single system provides transparency into all payment-related cash flow, allows processes to be easily enforced, and allows users to be optimally managed. An additional benefit is that you can leverage payment technologies to streamline intercompany payments and payments in various currencies to minimize the associated costs.

Basic system security like SSO and MFA

One of the most crucial aspects of payment processing is controlling who can access your bank accounts or payment systems, how safe it are, and their rights to execute payments. Basic functionalities like multi-factor authentication (MFA) and single sign-on (SSO) are considered essential by treasury professionals to keep their data safe and prevent unwanted logins. Typically, we see that companies require this for logging into payment technologies, and sometimes verification codes are even used when executing larger payment batches or sums.

User management and audit trail

One excellent control mechanism for security is user management. Once your treasury and finance teams expand, with multiple entities and bank accounts, it becomes hard to have a bird’s-eye view of which users are managing what processes and what they should be allowed access to. Not to mention all the new joiners and people quitting the organization, which needs to be kept track of. Without central user management, it can quickly become overwhelming and time-consuming.

That’s the reason why most companies look at tools for central user management, even integrated with HR systems, to keep track of newcomers and leavers. A TMS, for example, allows admin users to easily assign roles or user rights to specific teams or individuals without giving them too few or too many permissions. For instance, group treasury can set permissions so that a local entity can access its own cash flows and execute local payments, but cannot access the data or payments of other entities or groups.

“TO ENSURE SAFE PRACTICES, THE PRINCIPLE OF LEAST PRIVILEGE IS A GOOD RULE OF THUMB: NEVER GIVE MORE RIGHTS TO PEOPLE IN THE SYSTEM THAN THE TASKS THEY ARE ACTUALLY PERFORMING ACCORDING TO THEIR ROLE.”

TAPANI OKSALA, HEAD OF PARTNERS, NOMENTIA

On top of that, there’s often a demand by the treasury and finance for audit trails. This means that organizations can see exactly what users do in systems in case something goes wrong (incidentally or on purpose) and review the logs afterward. This helps while planning any follow-up actions.

4 or 6-eye principles

A simple yet efficient way to ensure that something isn’t wrong with a payment or payment batch is by including 4 or 6 eye principles into a payment process, for example, when a payment is about to be made. This way, a second or even third pair of eyes must verify the details of the payments being made to ensure they are correct. In payment hubs, you can set rules for when these principles should be applied, and the second reviewer will automatically receive a notification once their attention is requested.

Detect and respond notifications

Treasury and finance departments have a lot of tasks and processes to manage simultaneously. It can be hard to determine where their attention is needed most urgently. However, when attention is required, it is usually quite urgent. The same goes for payment security – if there is an issue, it is important that the relevant person be notified immediately. Although banks can notify users when there is a problem with a payment, this is only after the payment has been processed. Payment technologies can automatically identify almost any step in the payment process that requires attention and send notifications to the right user based on different sets of rules. This eliminates the need for emails to be sent back and forth between colleagues and other stakeholders. And if a payment somehow slips through, a hub can be integrated with the bank to ensure that the bank’s feedback is shown.

Payment matching or reconciliation

One of the most effective ways to prevent payment errors and fraud is by reconciling transactions with bank statements or invoices to ensure that all payments match payables. This is especially important when dealing with a large number of suppliers and payments. By using a system that can connect to your banks and ERP system, you can make sure that all necessary payment data is accurate and not missed. Such setups will greatly reduce errors related to manually going through each invoice and settling them.

However, payment security involves more than just technical solutions that are mentioned above. Other important topics that our partners and clients usually address include:

Employee awareness training

A big challenge for many companies is that fraud, errors, or scams start with an email or message to an employee via different channels. One important way to tackle this is to train employees, not just in treasury but in all teams, to identify scams. Most organizations do so through security awareness training that is usually initiated by IT and Security teams. Suppose something unwanted happens anyway; it’s best to have the proper incident response procedures in place to tackle it immediately.

“SAFE AND SECURE CULTURE IS NOT BEING CREATED BY STORING PDF DOCUMENTS WITH INSTRUCTIONS ON A SHAREPOINT, IT NEEDS FOLLOW-UP AND TRAINING. ALSO, THE COMPANY CULTURE NEEDS TO BE FOSTERED IN SUCH A WAY THAT PEOPLE FEEL COMFORTABLE STEPPING FORWARD AND POINT OUT THINGS THAT AREN’T IN ORDER.”

MARK ROELANDS, RISK & COMPLIANCE CONSULTANT, GRC CONSULTING

Treasury policies

One way to influence your payment security is by establishing the right payment-related policies that can be enforced company-wide. If they are easy to understand and can easily be followed without making processes inefficient, they can help ensure more secure practices.

Invoice approval procedures

Your invoice and vendor authenticity are important to maintain the integrity of your payables. One way to avoid fraud, especially with invoicing scams posing a threat to organizations, is to ascertain that your invoicing procedures allow you to identify fraud quickly. Irregular payments, such as those outside of approved countries, to new bank accounts, or irregular amounts, should always raise suspicion and be verified. In addition, you should encourage your team to ensure safety by cross-referencing vendor information when irregularities occur.

Incorporating these technical layers into the payment process is critical to efficient security against threats. On top of all technical security implementations, the human risk element should be tackled, which is sometimes an even bigger challenge as cyber threats and other scams continue to evolve and keep getting more challenging to identify for employees. Careful employee guidance and training should be a great first step in tackling that.

Where do start with payment security processes?

While facing the dual demands of optimizing payment processes cost-effectively and keeping security measures to mitigate financial losses from fraud and cybercrime efficient, organizations can find an effective solution in a payment factory. It’s an approach that offers a combination of automation and process security, tackling both challenges simultaneously.

Still, it can be daunting for some to initiate implementing a new system, such as a payment hub, to address payment security concerns. Therefore, we advise to begin by examining your current processes and identifying areas that can be improved. If you discover that your current methods can only scale to a certain extent, it may be worthwhile to investigate the various technologies available on the market. 

How a response framework can help in dealing with incidences 

As your treasury and finance organization continues to work with payment security, it usually keeps identifying additional improvements. When dealing with multiple treasury processes, it can be difficult to determine which ones to focus on first. To simplify matters, you can follow a process framework like the fraud risk management cycle developed by the European Court of Auditors (ECA). It shows the need for establishing the right processes and policies, and running risk assessments, after which the right controls can be developed to improve your current processes. As it is a continuous process, the process repeats itself constantly.

Fraud risk management framework

In addition, we always recommend you spar with your payment system to improve processes, be it a bank, ERP, TMS, or payment hub. Most of them have the necessary tools to help you fight payment threats better and more efficiently.

ALSO READ

Check our other blogs

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%.

Why I am raising this

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?

Why a buyer budgets for training at all

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?

Where training ranks

Share of 111
Training46.8%
Cloud or SaaS delivery21.6%
FX and hedging12.6%
ERP integration12.6%
Cash flow forecasting10.8%
Debt and investment10.8%
Reporting and dashboards10.8%
Multi-entity groups8.1%

Why it comes out as “training”

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.

What a buyer can take from it

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.

If you are a young vendor, most of these are not for you

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.

What clarity is worth

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.

Also Read

Join our Treasury Community

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.

Myths and realities

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.

What is a debit note?

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.

Myth #1: invoices can be “approved” or not approved

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.

Myth #2: Payables are the same as invoices

In the ordinary course of business, accounts payable teams in corporate clients approve payments and not invoices.

A few key points:

  1. Valid invoices are posted to a supplier account in the general ledger at the full amount demanded by the supplier (see above). If debit notes are raised, they are also posted.
  2. The amount due to the supplier is the balance on the supplier account in the general ledger – equal to invoices posted less debit notes posted.
  3. When it comes to paying a supplier, it is the outstanding and due balance on the supplier account that is settled. The due balance is calculated by taking all the items posted to the supplier account that are due on or before the current date, summing them up and subtracting payments already made.
  4. The result is a payable amount – a figure that will be settled to the supplier, usually via a payment run. That figure may be made up of many individual transactions (invoices, debit notes and credit notes). The key approval step is at the time of the payment run.

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.

  • Reason 1: if all the supplier invoices are financed by the same bank, there’s no need to try and unpick a balance that has been settled and split it into individual invoices.
  • Reason 2: nothing to do with debit notes, so just mentioned here for completeness: most general ledgers cannot handle more than one account payee record per currency – so this one record gets changed from the supplier banking details to the financier banking details and then all the money due to the supplier simply goes to the financier. Again, this avoids the need to try and split the payment into the individual invoices involved.

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.

Myth #3: debit notes are somehow “outside” SCF

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?

  • The amount due under the invoice (without set off, counterclaim etc), or
  • the amount payable in respect of the invoice at the time of purchase, which could include amounts that are already planned to be netted from the invoice payment.

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?

Myth #4: debit notes specifically relate to invoices

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.

Myth #5: we can ignore debit notes in SCF

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:

  • debit notes cannot be posted to the general ledger in the usual way
  • debit notes have to be tracked “off-system” with recovery of the debit notes handled away from the settlements and payments process.

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.

Debit notes and SCF – are there solutions?

Yes – it requires a modern approach to the way that the supply chain finance platform is developed and operates.

There are three approaches:

  1. Manual: Corporate accounts payable teams handle the debit notes away from the SCF program with manual tracking and recovery. SCF program is then simple as it is fed with an “approved invoice” file and all invoices are simply settled at their face value. Debit notes are tracked in a spreadsheet and suppliers are required by procurement teams to deduct them manually from future invoices.
  2. Delay debit notes: The corporate accounts payable team runs two processes:
    • Debit notes are allocated to invoices before they are included in the file transmitted into the SCF platform; early payments to suppliers are then net of debit notes that were outstanding at that specific moment; and then
    • Those invoices that are in the SCF program are then ring-fenced from the further application of debit notes against them by the accounts payable team – so the SCF financier is not exposed to any netting and will be paid in full. This requires some careful management of posting processes and dates applied to debit notes in the ERP to ensure debit notes are not deducted from financed invoices. One way to do this is to post debit notes with future due dates to defer processing and delay their recovery, leading to earlier due invoices that are financed always being paid in full; this is a cost to the business though.

Also Read

Join our Treasury Community

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.”

Also Read


Join our Treasury Community

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.