What to do now
A payment settlement exception register gives every unresolved payment one identity, observed provider state, cash impact, ledger impact, next safe action, owner, review time, and closure evidence. It prevents “pending” from becoming a permanent bucket and prevents an operator from retrying or reversing money based on a timeout alone.
Key takeaways
- Record what is known separately in provider, bank, and ledger systems.
- Assign the next safe observation before an external money action.
- Close only when the cash and ledger outcomes are both explained.
Use states that describe uncertainty
Useful states include awaiting provider result, awaiting payout, unmatched bank deposit, ledger posting missing, returned after posting, refund pending, possible duplicate, and evidence conflict. “Payment issue” is too broad to drive a safe next action.
Preserve the first-seen and last-checked timestamps. Aging begins when the exception is observed, not when someone finally opens the queue.
Keep one operational register
The register should point to restricted source records rather than copying bank credentials or unnecessary resident data.
| Field | What to record | Control question |
|---|---|---|
| Identity | Provider ID, ledger ID, tenancy/property reference | Is this the same payment? |
| Observed states | Provider, payout, bank, ledger, each with checked time | What is known in each system? |
| Exposure | Cash amount and ledger balance affected | What could another action duplicate? |
| Next safe action | Observe, reconcile, contact, approved correction, or hold | What can occur without assuming the outcome? |
| Ownership | Named operator, reviewer, next check, escalation | Who prevents silent aging? |
| Closure evidence | Final provider/bank outcome and ledger disposition | Can another reviewer reproduce closure? |
Separate observation from external action
Refreshing a provider status is different from initiating another debit, refund, reversal, or ledger correction. Mark which steps only gather evidence and which require approval. If the first attempt has an unknown outcome, reconcile it before another money movement.
Nacha distinguishes an ACH reversal that corrects certain sender errors from a return sent back because the receiving institution could not accept the payment. Operators should not use those words interchangeably or infer that either action is appropriate without the provider and responsible reviewer.
Operational checklist
Mark your progress, then save a working copy. Selections reset when you leave this page. A checked box is not an approval or evidence of completion.
☐
Stable payment identity or search evidence retained
☐
Provider, bank, and ledger states recorded separately
☐
Cash and balance exposure stated
☐
Observation step distinguished from money action
☐
Named owner and next check assigned
☐
Aging and escalation visible
☐
Closure includes both cash and ledger disposition
0 of 7 marked
Edge cases
- No provider ID exists: retain request identity and query evidence rather than inventing a reference.
- A resident supplies a screenshot: treat it as reported evidence, not provider settlement proof.
- Two staff members open records for the same payment: link and deduplicate operational ownership without deleting history.
Sources and references
Follow each source to check the underlying claim. Access checks and professional review are different steps.
1. Primary source · Stripe
ACH Direct Debit paymentsACH Direct Debit has delayed confirmation, can fail after initiation, and in rare cases can fail after a succeeded state. Provider-specific timing is illustrative, not a universal bank rule.
Source checked 2026-09-18
Automated source-access check: 2026-09-18.
2. Primary source · Nacha
A Second Chance: Understanding ACH ReversalsA reversal corrects a sender error, while a return is sent back because the receiving institution could not accept the entry. This does not supply property-accounting advice.
Source checked 2026-09-18
Automated source-access check: 2026-09-18.
Continue the workflow
Recover from an uncertain integration outcomehandling a failed or returned paymentexception queueRevision history
2026-09-18
Initial Phase 2 operational article with an original decision artifact, explicit failure states, primary-source scope notes, and AI-assisted technical review.