How should a furnisher report a payment reversal, such as a returned payment or reversed transaction, when that reversal affects the Date of Last Payment, the Date of First Delinquency, the Payment History Profile, and the actual payment amount?
Payment reversals are one of those ugly edge cases that expose sloppy credit reporting fast. If a payment posts, then gets reversed because of NSF, a chargeback, or another failed transaction, you cannot just leave the tradeline as-is and hope nobody notices. Under Metro 2, the reversal has to flow through the account’s core performance fields so the file reflects what actually happened, not what briefly appeared to happen in your servicing system.
Definitions and context
A payment reversal happens when a previously posted payment is backed out. Common examples include:
- A check returned for insufficient funds
- An ACH payment that fails after provisional credit
- A payment reversal tied to fraud or authorization failure
- A chargeback that removes a previously credited payment
From a Metro 2 standpoint, this matters because several fields may now be wrong:
- Date of Last Payment
- Actual Payment Amount
- Account Status
- Payment History Profile (PHP)
- FCRA Compliance/Date of First Delinquency (DOFD)
The fix is not cosmetic. These fields have to be corrected so they line up logically with the consumer’s true payment performance.
Step-by-step reporting standards
1) Correct the Date of Last Payment
If the reversed payment is no longer valid, then it cannot remain as the most recent payment.
Report Date of Last Payment as the date of the most recent valid, unreversed payment.
That means if a payment posted on June 10, got reversed on June 14, and the last valid payment before that was May 8, then the Date of Last Payment needs to go back to May 8.
2) Correct the Actual Payment Amount
Metro 2 expects Actual Payment Amount to reflect what was actually received for the reporting period.
If the payment was reversed and no valid payment remains for that period, report zero for Actual Payment Amount.
If part of the payment remains valid, report only the amount that truly stuck.
3) Re-evaluate Account Status based on the real delinquency
Once the reversed payment is removed, the account may no longer be current. You need to recalculate delinquency from the due date and report the correct Account Status.
That can mean the account moves from:
- 11 to 71
- 11 to 78
- 71 to 80
Whatever the recalculation supports, that is what gets reported. Not the prettier version.
4) Update the Payment History Profile
The PHP must reflect the real prior month performance, not the temporary system posting.
If the reversal means the prior month should have shown delinquency, then the first position in PHP needs to reflect that delinquency code.
Example:
- If the returned payment means the account was actually 30 to 59 days past due, the PHP position should show 1
- If it means 60 to 89 days past due, use 2
If you leave the old “current” code in place, you are reporting false history. That is exactly how disputes get born.
5) Recalculate the Date of First Delinquency when necessary
This is the part people screw up most.
The DOFD must reflect the first 30-day delinquency that led to the status now being reported.
If the reversed payment is what causes the account to become delinquent for the first time, then the DOFD may need to move to that new delinquency point.
If the account was already delinquent before the reversed payment, then the DOFD may stay the same.
In plain English:
- New delinquency caused by reversal: reset DOFD to the new first 30-day delinquency date
- Ongoing delinquency already existed: preserve the original DOFD
You are not picking whichever date feels safer. You are following the delinquency chain.
Compliance requirements
Under the FCRA, furnishers are responsible for reporting information that is accurate and complete. A reversed payment that stays reported like a successful payment creates false account performance and can distort:
- delinquency progression
- DOFD
- payment history
- last payment date
- collection and charge-off timing
That is not a formatting issue. That is an accuracy issue.
A few practical rules:
- Do not leave a reversed payment in Date of Last Payment
- Do not leave a nonzero Actual Payment Amount if the payment failed
- Do not preserve a “current” PHP month that is no longer true
- Do not reset DOFD unless the delinquency chain truly changed
Impact on consumers
Payment reversals can hit hard because they often trigger the first real derogatory reporting after a borrower thought they had made a payment. If reported wrong, the consumer can end up with either:
- a falsely favorable tradeline, which later gets corrected and causes confusion, or
- a falsely severe derogatory record, especially if DOFD is mishandled
Either way, bad reporting here creates disputes, escalations, and trust problems.
Conclusion
When a payment reverses, Metro 2 reporting has to snap back to reality. That means correcting Date of Last Payment, Actual Payment Amount, Account Status, PHP, and sometimes DOFD. The standard is simple: report what actually happened, not what briefly posted in your system.