Skip to main content

Payment proof

Payment proof is supporting evidence associated with a transaction or expected transaction. Examples may include a bank-transfer screenshot, manual receipt photo, signed payment note, deposit slip, or another approved document.

Proof helps Finance investigate and verify a payment. It does not automatically reconcile bank records, create a payment entry, generate a receipt, or change a customer balance.

Before uploading proof​

Confirm:

  • the correct buyer/customer;
  • the related reservation, contract, or payment;
  • amount and date visible in the evidence;
  • sender or reference information needed for verification;
  • that the file does not contain unrelated account information;
  • that a matching proof has not already been uploaded; and
  • the approved storage and access method.

Safe file handling​

Use a clear fictional or approved filename, such as:

TRAINING-nadia-transfer-2026-07-14.webp

For live records, follow the approved naming policy. Do not include passwords, full account numbers, or unnecessary personal information in filenames or notes.

Proof submitted before payment exists​

When proof arrives before Finance has recorded the transaction:

  1. Record receipt of proof in the relevant operational record.
  2. Assign Finance review.
  3. Verify the transaction through the approved source.
  4. Search for an existing payment.
  5. Record the payment only after verification.
  6. Link or attach the proof to the correct payment where supported.
  7. Update reservation/deposit-readiness status separately.

Proof linked to the wrong record​

If proof is attached to the wrong customer or payment:

  • stop further communication based on the file;
  • confirm the correct identity and transaction;
  • use the approved correction process;
  • preserve accountability for the original upload;
  • check whether another customer was exposed; and
  • escalate a privacy incident when appropriate.

Reviewing proof​

A reviewer should compare:

  • customer/sender;
  • amount;
  • date;
  • payment method;
  • transaction or bank reference;
  • intended contract/account;
  • existing payment entries; and
  • company-bank or authorized verification information.

Do not confirm the payment when a screenshot is cropped, unclear, duplicated, editable, or inconsistent with the approved source.

Example: duplicate proof​

A fictional buyer sends the same transfer screenshot twice through different staff members.

  1. Both staff record the communication in the appropriate activity history.
  2. Finance searches by amount, date, and reference.
  3. One existing payment is found.
  4. The second proof is not used to create another payment.
  5. The duplicate submission is noted and the buyer receives one confirmation.

Common mistakes​

  • Uploading proof to the lead but never completing Finance review.
  • Attaching a document to the wrong customer.
  • Treating the screenshot date as the verified transaction date without checking.
  • Creating duplicate payments from duplicate proof.
  • Publishing proof in training documentation.
  • Storing full banking details in notes.

Suggested training media​

Screenshot space: Add a fictional proof-upload interface showing customer, payment/contract link, file, reference, notes, and verification status. Use a fully fictional image with a Training Data watermark.
Screenshot space: Add a proof-review comparison showing the uploaded document, matching payment search, and authorized verification source with sensitive areas mocked or redacted.
Diagram space: Add a proof flow: Receive → Protect/store → Verify identity/amount/reference → Search payment → Record/link once → Update operational status.
Video space: Record a 5-minute walkthrough handling one valid proof and one duplicate submission. Do not use any real banking interface or document.