Practical guides 7 min read

Confirmation Receipt: What It Proves (and What It Doesn't)

Most pages about confirmation receipts are email templates. This one answers the payments question: what a confirmation of receipt actually evidences, how it differs from proof of payment and a remittance advice, and why a receipt issued after settlement cannot stop a misdirected payment.

By Tomaas Vento Starrantino · Reviewed by Donato Leone

A payer checking a payee's name against an IBAN before confirming a SEPA payment

Key takeaways

  • A confirmation receipt (or confirmation of receipt) is an acknowledgement that something arrived - money, a message or a document. All three meanings confirm arrival, not identity.
  • A confirmation receipt, a payment confirmation and a remittance advice are three different documents, issued by different parties, and none of them checks who owns the receiving account.
  • A receipt arrives after settlement. By then the money has already moved, so a receipt cannot prevent a wrong-IBAN payment or invoice redirection fraud.
  • The payee name check - Verification of Payee in the EU and SEPA - runs before the payment, and the receipt then becomes the closing record of a verified payment.
  • For accounts payable and treasury, a supplier's 'please confirm receipt' email is an unverified claim. Store the name-check outcome next to the receipt instead.

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. 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. 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. 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. 1 You enter or select the payee name and IBAN.
  2. 2 The name check runs and returns one of four outcomes: match, close match, no match or not available.
  3. 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. 4 The payment is released and settles.
  5. 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. 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. 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. 3 Run the check across the whole payment file before release, so one mismatched account is flagged while you can still stop it.
  4. 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.

FAQ

Frequently asked

A confirmation receipt - or confirmation of receipt - is an acknowledgement that something was received: a payment, a message or a document. In payments it confirms that a specific amount reached a specific account. It confirms arrival, not the identity of the account holder.

No. A receipt proves the money arrived at an IBAN. It says nothing about who owns that IBAN, so a payment to a wrong or fraudulently substituted account produces a perfectly genuine receipt. Only a name-to-IBAN check before the payment addresses that question.

A confirmation receipt is issued by the payee and says the money arrived. A payment confirmation or proof of payment is issued by the payer's bank and says the payment was executed. A remittance advice is issued by the payer and says what the payment is for. None of them verifies who owns the receiving account.

Include the amount and currency, the value date, the debtor and creditor names, the IBAN (masked where appropriate), the payment reference, the name-check outcome if the payer's bank returned one, and who issued the receipt with a signature or authorised sender.

Stop. A no match means the name does not belong to that account. Call the payee on a number you already had - never one from the message that supplied the details - and only proceed once the details are confirmed. A close match is different: accept the verified name the check returns, or correct your record to it.

No. A read receipt shows that a message was opened. It says nothing about whether money moved, whether an invoice was genuine or whether bank details were correct. Read receipts are also optional, so a missing one proves nothing either.

It is a request to acknowledge that something arrived safely - usually a payment, an invoice or a document. Reply with specifics rather than a bare 'received': the amount, the value date, the reference and the account it landed in. If you are the payer asking, ask for those same details back.

It can evidence that a credit arrived on an account, which is useful. It cannot evidence that the account belonged to the intended payee. For that you need the name-check outcome from before the payment, which is why storing it with the payment record matters.

Verify the payee before the receipt exists

Talk to RoxPay about Verification of Payee on the SEPA scheme, through one REST API and a dashboard.