A confirmation receipt is an acknowledgement that something was received. In payments it is the document or message that says a specific amount reached a specific account. That is useful, and it is also the limit of what it does: a receipt confirms arrival, not identity. It tells you the money landed in an IBAN, not that the IBAN belonged to the party you meant to pay.
That gap is the whole subject of this article. Almost every page ranking for 'confirmation receipt' is an email template or a business-writing guide, and none of them connects a receipt to the payee's identity. Here you get the payments version: what each document evidences, what it cannot be used for, and where a name-to-IBAN check fits before the money leaves.
What a confirmation receipt actually confirms
Three different things share the phrase, and mixing them up is how a finance team ends up relying on the weakest one.
- A payment acknowledgement: a receipt confirming that a payment was received, usually with the amount, the date and a reference. This is the meaning that matters when money is involved.
- A delivery or read receipt: a signal from a mail client that a message was delivered or opened. It is a message-level event, not a money-level one.
- A formal acknowledgement receipt: a signed document naming the recipient, the item and the date - used for documents, goods or cash handed over in person.
All three confirm arrival. None of them confirms identity. A payment acknowledgement proves a credit appeared on an account; it does not prove the account holder is the supplier, the employee or the landlord you had in mind. A read receipt proves even less: it proves someone opened a message.
Arrival is not identity
Every kind of confirmation receipt answers 'did it arrive?'. None of them answers 'did it arrive at the right party?'. Those are two different questions, and only the second one protects your money.
Confirmation receipt vs proof of payment vs remittance advice
A payer and a payee exchange several documents around one payment. They are often treated as interchangeable, and they are not: each is issued by a different party and evidences a different fact.
- Confirmation receipt (confirmation of receipt): issued by the payee, or by the payee's bank on the payee's behalf. It says 'we received this'. It is evidence of arrival.
- Payment confirmation or proof of payment: issued by the payer's bank or payment service provider (PSP). It says 'this instruction was accepted, processed or settled'. It is evidence that the payment was executed.
- Remittance advice: issued by the payer. It says 'this payment is for these invoices, with these references'. It is evidence of what the money was for, not that it arrived.
In a dispute, each one does a different job. A proof of payment shows you instructed and executed the transfer. A remittance advice shows what you intended to settle. A confirmation receipt shows the other side saw the money. What none of them shows is that the account behind the IBAN belonged to the party you named - and that is the fact a fraud claim usually turns on.
What a confirmation receipt does not prove
A receipt confirms that funds left your account and arrived at an IBAN. It says nothing about who owns that IBAN. Three failure modes follow directly from that.
- 1 A wrong IBAN typed or pasted: the payment settles perfectly into an account that belongs to a stranger. The receipt is genuine, and the money is gone.
- 2 A tampered supplier invoice: a fraudster changes the bank details on a real invoice or sends a 'new account' email. The payment settles, the receipt arrives, and the supplier never sees the money.
- 3 A lookalike account: the name on the invoice is real, the IBAN belongs to someone else - often a mule account opened for exactly this purpose.
There is a timing problem on top of the identity problem. A confirmation receipt is issued after settlement. By the time it exists, the money has already moved, and for a SEPA instant credit transfer that is a matter of seconds. A document that arrives after the money cannot prevent the money going to the wrong place. It can only tell you that it did.
Too late by design
A receipt is a record of the past. Fraud prevention needs a control in the present - before the payer confirms. That is why a receipt can never be the only control over an outbound payment.
Where the payee name check fits before the receipt
The control that runs before the money moves is the payee name check. In the EU and SEPA it is called Verification of Payee (VoP): your PSP sends the payee name and IBAN to the PSP that holds the destination account, which compares the name with its own account holder record and answers before you confirm. If you want the background on the check itself, our explainer on what Verification of Payee is covers it.
The sequence is short, and the order is the point.
- 1 You enter or select the payee name and IBAN.
- 2 The name check runs and returns one of four outcomes: match, close match, no match or not available.
- 3 You act on the outcome: proceed on a match, accept or correct the verified name on a close match, stop and re-check on a no match, and confirm through a second channel when the answer is not available.
- 4 The payment is released and settles.
- 5 The confirmation receipt arrives - now the closing record of a payment that was checked, not the only evidence you have.
That reordering changes what the receipt means. On its own, a receipt is the first and only thing you learn about a payment, and it arrives too late to act on. After a name check, the receipt is the last step in a chain that already includes a bank-sourced answer about the account holder. The receipt closes the loop; it does not open it.
If you want the mechanics of each outcome in more depth, our guide to reading match, close match and no match goes through them one by one.
Writing a confirmation of receipt: what to include
If you issue a payment confirmation receipt - as a supplier, a landlord, a payroll provider or a finance team - make it useful rather than polite. A short checklist beats a long template.
- Amount and currency, written the same way on both sides: EUR 12,400.00, not 'around twelve thousand'.
- Value date: the date the credit appears on the account, not the date you wrote the email.
- Debtor and creditor name, spelled as they appear on the account records.
- The IBAN, masked where the receipt will be shared beyond the two parties - for example the last four characters only.
- The payment reference exactly as it appears on the statement, so the payer can match it to an invoice.
- The name-check outcome where the payer's bank returned one, and the date it was run.
- Who issued the receipt, and a signature or an authorised sender for a formal acknowledgement.
Two things to leave out: guesses and reassurance. If you cannot confirm the value date, say when you will. 'Received, thanks' is a courtesy; a receipt with an amount, a date and a reference is evidence.
Confirmation receipts in accounts payable and treasury workflows
For an accounts payable (AP) or treasury team, the confirmation receipt question usually arrives as an email: a supplier writes 'please confirm receipt of our updated bank details', or a new payee asks you to acknowledge their account. Treat that email as an unverified claim, not as a control.
The reason is simple. A receipt from a supplier confirms that a message or a payment reached them. It does not confirm that the bank details are correct, because the person writing the email may not be the person who owns the account - and in invoice redirection fraud, they are not. A receipt issued by the fraudster's mailbox is still a receipt.
- 1 Verify the name against the IBAN when the supplier or employee is first set up, and store the verified name that comes back.
- 2 Re-verify whenever an IBAN or a name changes, and confirm the change by phone on a number you already had - never one from the email announcing it.
- 3 Run the check across the whole payment file before release, so one mismatched account is flagged while you can still stop it.
- 4 Store the name-check outcome, the responding institution and the date alongside the receipt and the payment record, so an auditor can see what was checked and when.
That last step is what turns a pile of receipts into an audit trail. A receipt alone shows the money arrived. A receipt plus a stored name-check result shows the payment was verified before it was sent and confirmed after it landed. Our article on Verification of Payee in supplier onboarding covers the wider process, and the guide to VoP for businesses and corporates sets out how supplier, payroll and payout checks fit together.
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.