A returned or bounced customer payment should reverse the earlier cash conclusion and reopen the affected receivable in the current invoice-level forecast. Do not erase the original receipt or pretend the reversal never happened. Preserve both events: the payment was recorded at one point, and the bank later returned it. The current forecast should show the invoice as open again only after the accounting source reflects that reversal.

Intuit's returned-payment workflow explains that recording the returned amount to Accounts Receivable and relinking the original payment reopens the invoice. Its open-transaction troubleshooting guidance likewise distinguishes reversing a failed payment from deleting the original transaction.

Keep four states separate

| Observed state | Receivable treatment | Cash treatment | Forecast treatment | | --- | --- | --- | --- | | Payment recorded and applied | Invoice may appear closed | Receipt is recorded | Remove the invoice from future expected collections | | Bank return observed | Source needs a reversal entry | Cash is reversed | Do not keep the receipt as collected cash | | Original invoice reopened | Invoice is open again | No replacement cash exists yet | Return the balance to the action queue | | Replacement payment recorded | Apply to the supported invoice | Count the new receipt once | Remove only the amount actually settled |

The key control is lineage. A reviewer should be able to trace the original invoice to the failed payment, the bank return, the reopening entry, and any replacement payment. The payment-versus-deposit guide helps prevent the same cash event from appearing twice at different processing stages.

Rebuild timing instead of restoring the old assumption

Reopening the invoice restores an amount due; it does not prove a new payment date. The prior collection week was based on evidence that is no longer valid. Move the reopened item to unassigned timing unless there is separate current support such as a dated replacement commitment, a new payment record, or another documented event.

Add a named owner and next action. Record the return date, current open amount, reason supplied by the payment source, whether the customer has provided replacement-payment evidence, and the next review date. Keep a factual status such as `returned payment—invoice reopened` separate from a judgment such as `possible week two`.

Keep fees outside the original invoice amount

A bank fee charged to the company is not automatically part of the customer's original receivable. If the company chooses to invoice the customer for a returned-payment fee and the authorized accounting owner records a separate invoice, that new posted amount can enter the AR population on its own terms. Until then, do not add a fee to the open invoice merely to make the forecast equal the bank outflow.

Review the next export

On the next dated export, confirm that the original invoice is open, the failed payment is not still settling it, and the total AR control balance reflects the reversal. Use the weekly snapshot change log to show why the invoice re-entered the population. If the replacement receipt cannot be matched cleanly, route it through the unmatched-payment checklist.

Decision rule

Treat a returned payment as a reversal event first and a new collection opportunity second. Restore the supported invoice balance after the source reopens it, reverse the failed cash conclusion, and assign a new collection week only from fresh evidence.

AR Pulse analyzes an authorized QuickBooks receivables export and keeps source facts separate from timing judgments. It does not change the books or guarantee that a reopened invoice will be collected. View the example report to see the evidence-first structure.