In this article
Keep the return reason, affected record, and business consequence separate so the next review starts with facts.
A return-related message can trigger a rush to explain what happened. That rush is understandable, especially when someone is waiting for payment, but it can bury the most useful information beneath speculation. A small evidence packet should preserve the actual reason supplied, identify the affected record, and state the business question still open. This article describes an independent documentation method, not a determination of liability, a dispute process, or permission to retry a payment.
Preserve the reason as received
Dwolla’s Transfer Failures guide describes a failure resource containing an ACH return code and explanation. Its examples distinguish insufficient funds, account-location problems, and an unauthorized-payment report. Those categories should not be collapsed into a generic “bank issue,” because they pose different questions.
Keep the original code and accompanying description together if they are available in an authorized record. Do not supply a code from memory to fill a blank. If a message merely says “returned,” record that wording and ask for the applicable reason through the provider’s normal process. A precise unknown is better than an incorrect classification.
Identify the affected movement
An invoice reference and a transfer reference serve different purposes. Include both when they are available and relevant, but label them clearly. A business obligation can remain open even when one attempt to satisfy it has a recorded outcome. Conversely, a return-related record should not automatically be attached to the most recent invoice simply because it arrived at the same time.
In a fictional example, a music school receives a return notice while preparing another payment to the same teacher. The evidence packet links the notice to its own reference and date. It does not merge the two payments into one story. That separation allows the school to ask a specific question instead of accidentally changing the wrong payment plan.
Create a neutral chronology
List the original observed status, the return-related notice, and any later provider clarification in order. Include both the event time supplied by the source and the time the team received it when those differ. Do not assume a notification’s arrival time is the moment the underlying event occurred.
Keep interpretation out of the chronology itself. “Provider notice received Wednesday” is an observation. “Recipient caused the problem Wednesday” is a causal claim that the notice may not support. Neutral chronology reduces the chance that an internal note becomes an unsupported accusation when copied into a customer message.
State the consequence you actually know
A return can raise several business questions: whether an obligation is still open, whether an existing record needs adjustment, and whether another authorized payment route should be considered. These questions should be listed separately from the technical reason. Do not jump from a code to a conclusion about someone’s intentions, general financial condition, or contractual rights.
For example, an insufficient-funds description concerns the reported outcome of a particular entry. It is not a complete financial profile of the person or organization involved. Keeping the wording narrow protects both accuracy and privacy. The packet should contain what the reviewer needs to resolve the payment question, not a narrative about the payer.
Limit attachments to the useful evidence
A large bundle of unfiltered screenshots can expose more information while making the case harder to understand. Prefer a small set of relevant records with clear captions. Mask unrelated transactions and personal details when creating a discussion copy, while preserving any originals according to the organization’s own recordkeeping requirements.
Never include passwords, authentication codes, or complete bank credentials in an ordinary evidence packet. If the provider needs sensitive material, use its appropriate verified process rather than placing it in a general email thread. An independent educational site cannot receive or adjudicate a return and should not ask readers to upload their payment records.
End with a decision-ready question
The packet should conclude with the question that needs an authorized answer: “What does this return reason require before any further attempt?” or “Which record should our team use to reconcile this outcome?” Avoid phrasing that already assumes the answer, such as “Please confirm we can resend now.” A neutral question leaves room for a constraint you have not yet identified.
Use the failed-transfer decision guide to separate diagnosis from a new action. Use the reconciliation guide when multiple records must be matched. The evidence packet is successful when another reviewer can identify the affected payment, understand the supplied reason, and see the unresolved decision without reconstructing a sprawling conversation.