Not every document that references a transaction counts as valid proof of payment. And the ones that do often contain sensitive information, like full account numbers or routing numbers, that can put you at risk if you share them without preparation. This page covers which document types are generally accepted, what information needs to be visible for a submission to be valid, and which fields you should redact before sharing. By the end, you’ll know which document to use and how to prepare it safely.
What Qualifies as Proof of Payment
Proof of payment is documentation that confirms a specific transfer has already been completed, not that a payment is pending or on its way. The key word is “completed”: the document must reflect a settled transaction, not an anticipated one. Accepted formats come from a specific set of document categories, each issued by a financial institution or payment processor, not by the payer themselves. Which category a requester will accept depends on the document type, not on the payment method used to fund the transaction.
Accepted Document Categories
Valid proof-of-payment documents share one defining characteristic: they are issued by a financial institution or payment processor and reflect a transaction that has cleared or settled. A document produced by the payer alone, such as a self-prepared summary or a screenshot of a pending transfer, does not meet this standard no matter how it’s formatted.
- Bank transfer receipt: A receipt issued by a bank when a transfer is processed, confirming the details of a completed domestic or international transfer.
- Bank statement showing the specific transaction: A periodic account statement from a financial institution that includes the line item for the relevant payment, used when a standalone receipt isn’t available.
- Bank payment confirmation: A confirmation document or message generated by the sending bank after a payment instruction has been executed and accepted.
- Photocopy of a cancelled check (front and back): A copy of a check that has been processed and returned by the bank, with both sides reproduced to show the endorsement and clearing marks.
- Credit card sales slip: A point-of-sale or transaction slip issued at the time of a card payment, showing the amount charged and the approval code.
- Wire transfer confirmation: A document confirming that a wire transfer has been sent and accepted. For international transfers, this may be an MT103 SWIFT message containing the transfer date, amount, sender, and recipient details.
- ACH transfer confirmation: A confirmation issued by a bank or payment processor verifying that an automated clearinghouse transfer has been submitted and processed.
- Monthly credit card statement with sensitive fields redacted: A full billing statement from a card issuer, with personal and unrelated financial data removed, used to show a specific charge within the billing period.
- Online banking screenshot of a completed transaction: A captured image from an authenticated online banking session showing a transaction with a completed or posted status, accepted in contexts where institutions don’t generate separate confirmation documents.
Institutional and Reimbursement Context vs. Financial-Verification Context
The same document category can be requested for two different purposes. In an expense reimbursement context, such as a claim submitted to an employer, university, or government agency, the requester is confirming that a specific expense occurred and that the claimant paid for it. In a financial-verification context, such as a bank dispute, counterparty confirmation, or compliance review, the requester is confirming that a transfer reached its destination or that a transaction can be traced through the financial system.
The document requirements overlap quite a bit between these two contexts, but how much redaction is acceptable and how much transactional detail is expected can differ. A reimbursement processor may accept a bank statement with most account details obscured, as long as the relevant transaction line is legible. A bank conducting a dispute investigation may require the full transaction reference number and recipient details to be visible and unaltered. Knowing which context applies tells you how much detail needs to stay visible before you submit.
Required Information Fields on a Valid Proof-of-Payment Document
The document category alone doesn’t determine whether a submission is accepted. A bank transfer receipt, wire confirmation, or account statement is only valid when it shows a specific set of identifying and transactional fields that let the requester match the document to a completed payment. Requesters check documents at the field level, not just the format level. A document from an accepted category that’s missing one or more required fields will typically be rejected, regardless of where it came from or how it looks.
Fields the Document Must Clearly Show
Each required field answers a specific verification question the requester needs to resolve. A document missing any of these fields can’t substantiate the transfer and will be rejected, regardless of which document category it belongs to.
- Sender’s name: Identifies the individual or entity that initiated the payment, confirming the payer’s identity matches the transaction record.
- Sender’s bank name: Identifies the financial institution that processed the outgoing transfer, establishing where the funds came from.
- Sender’s account number: Ties the payment to a specific account held by the sender. See the redaction guidance below for how to handle this field.
- Recipient’s name: Confirms the intended payee, so the requester can verify that funds went to the right party.
- Recipient’s account or destination details: Identifies the specific account or destination the funds were sent to, separating this transfer from others to the same recipient.
- Transfer date: Establishes when the payment was made, which the requester uses to match the document to a specific transaction or reimbursement period.
- Amount: States the value transferred, which must match the payment being verified.
- Currency: Specifies the denomination of the transfer. For international payments, CFPB guidance requires that the exact amount the recipient will receive be stated in the currency in which those funds are received.
- Transaction or payment reference number: A unique identifier, such as a wire confirmation number or ACH trace number, that lets the requester and the sending institution locate and audit the specific transaction.
Sensitive Fields to Redact Before Sharing
A raw bank statement or credit card statement usually contains far more information than any requester needs to confirm a single transaction. It’s your responsibility to remove that extra information before submitting, not the requester’s responsibility to overlook it. Financial document management guidance consistently treats redacting specific non-transactional fields as standard practice, and a document with those fields removed is still valid for proof-of-payment purposes. Redaction doesn’t touch the fields the requester actually needs. It only removes fields that serve no verification purpose and create unnecessary risk.
Specific Fields to Redact or Obliterate
The following fields appear on bank and credit card documents but aren’t needed to confirm a completed payment. Remove each one before sharing any statement or receipt as proof of payment.
- Cardholder or account holder address. A physical address isn’t needed to verify a transaction, and it exposes you to identity-based risk if the document is intercepted or misused.
- Full account number. A complete account number provides enough information to attempt unauthorized account access. Where the requester’s process allows it, leave only the last four digits visible so basic account identification is possible without exposing the full number.
- Routing number. A routing number combined with an account number is enough to initiate an ACH debit, which makes it a high-risk field to share outside a verified channel.
- Credit card summary fields. Fields like payment due date, current balance, and minimum payment due describe the account’s overall financial position, not the specific transaction being reviewed. Remove these entirely.
- Unrelated transaction lines. Any transaction on the statement other than the one being verified reveals spending or payment behavior that’s irrelevant to the request. Obliterate these before sharing the document.
Documents That Are Not Accepted as Proof of Payment
Some documents reference a transaction, look official, and come from recognizable institutions, but they don’t confirm that funds have actually moved and settled. Requesters, whether employers processing reimbursements, platforms resolving disputes, or counterparties verifying a transfer, draw a firm line between documents that show a completed transfer and those that only anticipate or request one. Submitting a document from the non-qualifying category will typically result in an outright rejection, and you’ll need to find and resubmit the correct document before the process can move forward.
Non-Qualifying Document Types
Each of the following document types fails because it doesn’t come from a financial institution confirming that a transfer has cleared. That’s the core test requesters apply. A document that predates settlement, or that’s issued by the payee rather than a financial institution, can’t satisfy that test no matter how detailed or official it looks.
- Remittance advice or payment advice notifications. These documents notify a payee that a payment has been initiated or is on its way, not that it has been completed or cleared. Multiple institutional sources, including Stripe, BILL, OFX, and SoftCo, confirm that remittance advice is not accepted as proof of payment because it carries no confirmation that the recipient actually received the funds.
- Invoices issued by the requesting party. An invoice is a request for payment directed at the payer. It records an amount owed, not an amount transferred. Because the document comes from the payee and predates any settlement, it can’t serve as evidence that payment has occurred.
- Order confirmations and purchase receipts without financial-institution settlement data. These documents confirm that an order was placed or acknowledged by a merchant, but they don’t show that a financial institution processed and completed the corresponding transfer. Without settlement confirmation from a bank or payment processor, they don’t meet the completed-transfer standard.
Proof of Payment vs. Proof of Funds
These two terms get used interchangeably in a lot of search results, but they refer to different things. Proof of payment confirms that a specific transfer has already been completed. Proof of funds confirms that sufficient liquid assets exist to complete a future transaction. Submitting one in place of the other won’t work because the document doesn’t answer the question being asked.
Each document type is requested at a different point in a transaction and by a different type of requester. Proof of payment is typically requested after a transfer has occurred, by a counterparty, employer, or platform looking to confirm settlement. Proof of funds is typically requested before a transaction closes, by a seller, lender, or immigration authority looking to confirm that the applicant can meet a future financial obligation. Because the two documents answer different questions, a completed bank receipt can’t stand in for a certified asset statement, and vice versa.
| Dimension | Proof of Payment | Proof of Funds |
|---|---|---|
| What it confirms | A specific transfer has already been completed and settled | Sufficient liquid assets exist to complete a future transaction |
| Typical request context | Expense reimbursement, dispute resolution, counterparty transaction verification | Property purchase, visa application, investment transaction |
| Accepted document types | Bank transfer receipts, bank statements showing the specific transaction, wire transfer confirmations, ACH confirmations, cancelled check copies, credit card statements, online banking screenshots of a completed transaction | Bank statements, certified financial statements from an accountant or auditor, investment or brokerage account statements from a licensed broker, escrow letters from an escrow company or attorney |
| Recency requirement | The document must reflect the specific completed transaction. No universal recency window applies across all request contexts. | Approximately 30 to 90 days in property and investment contexts, though this window is policy-specific and may vary by requester |
| Authentication requirement | Document must originate from a financial institution or payment processor, not from the payer alone | In property and investment transactions, typically requires a signature from an authorized bank employee and an official bank stamp |
Evaluating the Legitimacy of a Proof-of-Payment Request
Requests for financial documents after a transaction can be legitimate, such as for chargeback resolution, reimbursement verification, or regulatory compliance, or they can be fraudulent, including impersonation schemes and credential harvesting. The FTC’s Consumer Sentinel Network Data Book 2024 reports that bank transfers and payments accounted for the highest aggregate fraud losses of any payment method in 2024, reaching $2.09 billion, out of $12.5 billion in total reported fraud losses that year. Checking the request itself, and controlling how you send any document, are the two things that determine whether a submission is safe.
Signals That a Request Is Legitimate vs. Suspicious
Before submitting any financial document, check the request against these observable signals. If a request fails on more than one of these points, verify it directly through a known, independent contact before sharing anything.
- Verified requester identity: The request comes from an institutional email domain, a known counterparty, or a portal you’ve used before, not from an unsolicited message or an unfamiliar address.
- Specific, traceable reason: The requester names a particular transaction, process, or case reference that you can independently confirm exists.
- Narrow scope of information: The request covers only the specific transaction in question, not a full account history or multiple unrelated periods.
- Authenticated submission channel: The requester directs you to an established, authenticated portal rather than asking for an email attachment, a screenshot sent through a messaging app, or a photo upload to an unverified site.
- Absence of pressure tactics: The request doesn’t impose an artificial deadline, claim that failure to respond immediately will result in account suspension, or use urgency to discourage you from verifying.
Safe Transmission Practices
The channel you use to send a document carries the same risk as the document’s content. A correctly redacted proof-of-payment document sent through an unsecured channel can expose the same sensitive data as an unredacted one. Controlling the transmission method is a separate, necessary step from preparing the document itself.
- Use verified, encrypted portals: Submit documents only through authenticated platforms, such as a bank’s secure message center, an employer’s expense system, or a dispute resolution portal, rather than attaching files to email or sending screenshots through consumer messaging apps.
- Retain a copy of the exact document submitted: Keep a record of the precise version of the document you shared, including any redactions, to support an audit trail if the submission is later disputed or misused.
- Confirm the recipient’s identity through a separate channel: Before sending, verify the requester’s identity by contacting the institution or counterparty through a phone number or address you found independently, not one provided in the request itself.
- Decline requests that exceed the transaction scope: Refuse any request that arrives through an unsolicited channel or asks for documents covering more than the specific transaction at issue. Both signals suggest the request falls outside normal verification practice.
Handling Your Next Proof-of-Payment Request
A valid proof-of-payment submission meets two conditions at once: the document category confirms a completed transfer, and the fields visible on it are exactly what the requester needs to verify that transfer, nothing more. When both conditions are met, the document is both sufficient and safe to share. That two-part standard applies across request contexts, so it’s the right framework to use when deciding which document to submit and how to prepare it.