The short answer
Reconcile rent payments by matching one stable payment identity across the processor, payout or deposit, bank account, and tenant ledger. Separate gross receipts, fees, net settlement, returns, refunds, and ledger allocation. A provider success state alone does not prove bank receipt or correct tenant posting.
Key takeaways
- Match identities before matching totals.
- Reconcile gross activity to net deposits with explicit fees and adjustments.
- Keep settlement and tenant-ledger allocation as separate proofs.
Build an identity chain before totaling the batch
Capture the tenant or payer reference, tenancy, processor payment ID, amount, initiation date, current provider state, payout ID, bank deposit reference, and ledger receipt ID. Dates may differ; do not use same-day proximity as the only match rule.
Limit sensitive bank data in the workpaper. Stable provider and ledger references usually support reconciliation without copying full account numbers.
Prove the batch in three layers
First, account for every provider payment state. Second, bridge gross settled receipts to the provider payout and bank deposit. Third, prove that eligible receipts reached the intended tenant ledgers.
| Layer | Equation or match | Typical exception |
|---|---|---|
| Provider population | Opening unsettled + initiated − failed/returned/refunded = ending states | Missing or duplicate event |
| Payout to bank | Gross settled receipts − fees ± adjustments = net deposit | Deposit split or fee omitted |
| Payment to ledger | Eligible payment IDs map once to intended tenancy and receipt | Unposted, duplicated, or misallocated receipt |
| Closeout | Every difference has owner, evidence, and next check | Aged “temporary” difference |
Treat delayed finality as a state, not a surprise
Stripe documents ACH Direct Debit as delayed-notification and notes that failures can occur after initiation and, rarely, after a payment has transitioned to succeeded. That provider-specific behavior demonstrates why a workflow needs explicit pending and later-returned states.
Do not generalize Stripe’s timing to every provider. Store the provider state and checked-at time, and define when the team will recheck items that are not final.
Check whether event delivery changed the population
When provider totals and local records disagree, determine whether the issue is a money outcome, a missed or duplicate webhook, or both. Preserve event identities and retrieve current provider state before replaying an event or correcting a ledger.
The replay record owns inbound event recovery; this reconciliation remains responsible for proving the resulting provider, bank, and tenant-ledger outcomes.
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.
☐
Provider population frozen at a timestamp
☐
Payment identities retained
☐
Gross-to-net payout bridge completed
☐
Bank deposit matched
☐
Every eligible payment mapped once to a tenant ledger
☐
Returns and refunds separately identified
☐
Open items have next check and owner
0 of 7 marked
Edge cases
- A payout combines multiple properties: retain property allocation beneath the deposit total.
- A processor fee is posted separately: link it without forcing the bank deposit to equal gross receipts.
- A return arrives after the original close: reopen the payment outcome and link the reversing ledger process.
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
Review a rent payment allocationhandling a failed or returned paymentRecover from an uncertain integration outcomeWebhook replay reconciliation for property workflowsRevision 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.