Receipt Confirmation in Payments: VoP Name Check

In payments, receipt confirmation means one of two things. Before you pay, it is the confirmation that the account you are about to credit belongs to the party you named - the payee name check. After you pay, it is the confirmation that the money reached that account. Neither of them is an email read receipt, and neither is a supplier replying 'received, thanks'.

That distinction is worth spelling out, because almost every page ranking for the phrase is an email-client tutorial. Those pages explain how to request a read receipt in Gmail or Outlook, and they are correct about email. They say nothing about IBANs, payee names or settlement - which is the part that matters when money is involved.

What 'receipt confirmation' means - and what it doesn't

Three different things share the phrase, and mixing them up is how finance teams end up relying on the weakest one.

• An email read receipt or delivery receipt: a signal from the recipient's mail client that a message was delivered or opened. It is a message-level event.
• An acknowledgement of receipt: a human or automated reply saying 'we have your message, invoice or delivery'. It is a statement by the recipient.
• A payment receipt confirmation: evidence that a specific amount reached a specific account, plus - before that - evidence that the account belongs to the intended payee.

Only the third one is about money. An email read receipt tells you a message was opened. It does not tell you that the invoice was genuine, that the bank details in it were correct, or that any money moved. A payment confirmation is a different mechanism entirely: it comes from the payment system, not from a mailbox.

Why email-style receipt confirmation fails for payments

The limits the email tutorials themselves admit are exactly the limits that make email useless as a payment control. Receipts are optional. The recipient can refuse. Different clients behave differently. So a missing receipt is ambiguous: it could mean the message was never read, or that the reader simply declined to send a receipt.

Apply that to a payment. A supplier emails 'please confirm receipt of our new bank details'. You reply, they reply, and everyone feels confirmed. But nothing in that exchange checked whether the IBAN belongs to the supplier. If the supplier's mailbox was compromised, the person replying may be a fraudster, and the confirmation is worthless. The same applies in reverse: a supplier saying 'payment received' does not prove the money landed in the right account - it proves someone saw a credit.

The fix is not a better email. It is a check that runs between the two banks, where the account holder record lives. That check is Verification of Payee (VoP) in the EU and SEPA, and Confirmation of Payee (CoP) in the UK. If you want the background on what the EU check is, our explainer on what Verification of Payee is covers it; here we stay on the confirmation angle.

Receipt confirmation before you pay: the payee name check

The pre-payment confirmation is short and mechanical. Your payment service provider (PSP) - your bank or payment institution - sends the payee name and IBAN to the PSP that holds the destination account. That PSP compares the name with its own account holder record and answers with a standardised outcome. You see the answer before you confirm the payment.

1. 1 You enter or select a payee name and an IBAN.
2. 2 Your PSP sends the name and IBAN to the payee's PSP.
3. 3 The payee's PSP compares the name with the account holder record and answers.
4. 4 Your PSP shows you the outcome, and you decide whether to send, correct the details or stop.

There are four possible answers, and each one asks something different of you.

• Match - the name is consistent with the account holder. Proceed with normal confidence.
• Close match - the names are similar but not identical, for example a missing middle name or a trading name instead of a registered name. The check usually returns the name held on the account, so you can confirm it or correct your record.
• No match - the name does not belong to that account. Stop and re-check the details through a channel you already trusted, such as a phone number from your own records.
• Not available - the payee's PSP could not answer, for example because it is unreachable or outside the scheme. Neither good nor bad news; treat a new or changed payee with extra care.

The check is advisory. It does not block the payment, and the decision stays with you. That is deliberate: the point is to put a clear, bank-sourced answer in front of the person releasing the money, at the moment they can still act on it. Our guide to reading each VoP outcome goes deeper on what to do with a close match or a no match.

What confirmation comes back after a SEPA payment

Once the payment is sent, the confirmations you get are about status, not about identity. They answer 'did the money move?' rather than 'was this the right payee?'.

• Accepted: your PSP has taken the payment instruction and passed it on. The money has left your account or is about to.
• Settled or credited: the payee's PSP has credited the account. For a SEPA instant credit transfer this happens within seconds; for a regular SEPA credit transfer it follows the scheme's cut-off and settlement cycle.
• Returned or rejected: the payment did not complete, for example because the account was closed or the details were invalid. The money comes back, usually with a reason code.

None of these retroactively proves the payee was the one you intended. A payment can settle perfectly into an account that belongs to someone else - that is exactly what happens in invoice redirection fraud. Settlement confirmation tells you the transfer worked. The name check is what tells you it went to the right place. Keep the two separate in your head and in your records.

Receipt confirmation for corporates: supplier and payroll IBANs

For an accounts payable or treasury team, receipt confirmation is a data question before it is a payment question. You hold hundreds of supplier and employee bank records, captured at different times by different people. Some are out of date. A name check is only as good as the name you send it.

1. 1 Confirm at onboarding: run a name check when a supplier or employee is first set up, and store the verified name that comes back.
2. 2 Confirm before each payment run: run the check across the whole payment file before release, so a single mismatched account is flagged while you can still fix it.
3. 3 Confirm on change: a new IBAN or a changed name is the moment to check again - and the moment to call the supplier on a number you already had, not one from the email that announced the change.
4. 4 Record the outcome: keep the result, the responding institution and the time with the payment record, so you can show what was checked and when.

That last point is what turns a check into a control. A vendor's emailed 'please confirm receipt of our updated details' is not a control, because it confirms a message, not an account. A stored name-check outcome is: it is evidence that a bank compared the name with the account holder record on a specific date. Our article on Verification of Payee in supplier onboarding covers the wider process; the confirmation record is the piece that survives an audit.

Payroll deserves its own line. The riskiest moment is not the monthly run but a bank-detail change request. Confirm the employee's name against the new IBAN when the change arrives, and again before the file is released.

Receipt confirmation for banks and PSPs: requesting vs responding

If you run a payment service, the confirmation layer your customers see is built from two directions, and both have to work.

• As a requesting PSP, you send the name and IBAN to the payee's PSP and must return a clear outcome to your customer - including the held name on a close match, and a sensible message when the answer is not available.
• As a responding PSP, you receive requests about your own account holders and must answer them accurately and quickly, with the right scheme code.

The responding side is the one teams underestimate. If you hold customer accounts, other PSPs will ask you about them, and a slow or wrong answer becomes someone else's confusing payment screen. Our page on Verification of Payee for banks and the guide to being a responding PSP cover the build in more detail.

How to word a receipt confirmation request

Most 'kindly confirm receipt' emails ask for the weakest possible evidence. Ask for the specific things instead, and say what you will do with them.

• Ask for the name-check result: 'Our bank returned a match for the name and IBAN we hold. Can you confirm the account name exactly as it appears on your statement?'
• Ask for the payment reference and amount: 'We are paying invoice 4471, EUR 12,400, reference INV-4471. Please confirm the reference you will see on your statement.'
• Ask for the settlement date: 'Please confirm the date the credit appears on your account, so we can close the item.'
• Ask for a change to be confirmed out of band: 'If your bank details change, we will call the number on file before updating them. Please do the same with us.'

Notice what these requests have in common: each one asks for something a bank or an accounting system produces, not something a person can type from memory. That is the difference between a confirmation and a courtesy.

RoxPay delivers Verification of Payee on the SEPA scheme through one REST API and a dashboard, covering both the requesting and the responding direction. It returns the standardised outcomes - match, close match, no match and not available - in well under a second, with the verified name on a close match, for a single payment or a whole payment file.