Picture a Tuesday morning in a mid-sized distribution company. A credit transfer for a few thousand euros appears on the bank statement. The description holds a reference code nobody recognises, and the name next to it is not on the customer list. It is the fourth credit that week still waiting to be confirmed. Someone in accounts searches the shared inbox for a remittance advice. Someone else filters the open invoices by amount, hoping one of them matches. Then a message arrives from sales: the customer says they paid on Friday, so can the next order go out? The money is in the account. Nobody can yet say whose it is.
Receiving money and understanding a receipt are two separate events, and the bank statement only records the first. The rest depends on what the payer chose to type. In a SEPA credit transfer, the free-text remittance field holds up to 140 characters. The European Payments Council, which manages the SEPA schemes, says this field enables the beneficiary to reconcile payments with receivables automatically. It is also optional. Some payers write the invoice number, others leave the field blank, and the company receiving the money has to work out the rest.
The name on the transfer adds a second doubt. Under the SEPA rules, the payer's name should be the name of the account holder being debited, and that may not be the name the team knows. A customer may trade under a brand and pay from the account of its legal entity. An owner may pay from a personal account, or a parent company may settle invoices for its subsidiaries. SEPA has an optional field for these cases, called "Ultimate Debtor" in the payment message, for the person or company on whose behalf the payment is made. When the payer leaves it empty, the only name the payment carries for the payer is the account holder's.
It helps to keep three questions apart, because they tend to get merged. The first is who sent the money, meaning the account holder on the transfer. The second is which customer or commercial relationship the payment belongs to, which may be another company in the same group. The third is which document, or documents, the payment settles. One transfer can pay four invoices at once and deduct a credit note. Knowing the sender answers the first question. It does not answer the other two, and treating it as if it did can lead to receipts being allocated to the wrong invoice.
A receipt nobody can place does not stay a single task. Until someone identifies it, the customer's account still shows the invoice as overdue, and the ageing report shows a debt that has in fact been paid. The credit controller may send a reminder to a customer who has already paid, and sales may hold an order for a client who is up to date. Each step is small. Together they become a run of emails, calls and spreadsheet searches, and they reach the customer just after the customer did what was asked.
Volume makes this a routine problem. In 2024, SICOI, the Portuguese interbank clearing system, processed 223 million SEPA credit transfers worth €443.8 billion, according to Banco de Portugal. Each of them carried whatever description the payer chose to write, or none at all. A company that receives hundreds of transfers a month needs only a small share of unclear ones to keep someone busy. Each unclear entry waits until someone finds the email or the phone call that explains it.
Identifying the counterparty changes where the work starts. In nBanks, global settings let each company decide how its customers and suppliers are identified and created as counterparties. With automatic identification switched on, the nBanks AI works out which counterparty is behind each bank transaction, using the information the banks provide. The aim is to detect and standardise counterparties, so that payers and beneficiaries can be recognised across the company's financial activity. Companies can also let the AI create a counterparty that is not yet on their list, or update the list through integrations such as E-Fatura, the Portuguese tax authority's invoice portal.
Identification has limits. Knowing the payer is not the same as categorising the movement or reconciling it with invoices, and on the nBanks platform these are separate functions. Identification works from the information the banks provide, so when the description is empty and the account holder is unknown, the decision still belongs to a person. In nBanks, that person can comment directly on the bank transaction and mention colleagues, and the company's accountant can join the conversation. The answer then stays attached to the movement instead of going back and forth by email. The AI handles the cases the bank data can settle, and the team keeps its attention for the ones that need judgement.
Go back to that Tuesday morning. The money arrived early, and the balance did not change after that. What changed, hours or days later, was that someone could say who paid, on behalf of which customer, and for which invoices. Until that moment the company had a value on its statement. Afterwards it had a receipt it understood, and a customer it could stop chasing.
Sources