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
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.
0 of 7 marked
Edge cases
Sources and references
Follow each source to check the underlying claim. Access checks and professional review are different steps.