Rent ledger and bank deposits differ: match payments to payouts first

The charge, the payment and the payout answer different questions

Before trying to make the totals agree, ask what each report is counting. A charge is the amount entered against a tenancy. A tenant payment is money recorded against that tenant. A payout is the processor moving collected funds to your bank. The bank statement records the arrival there, not a fresh payment from the tenant.

A rent ledger keeps the tenant-level history, including partial payments, as described in Stessa's rent-ledger guide. Keep the individual receipts even when they cover one charge. Replacing them with a single monthly total would lose the dates and references you need to trace the money.

Stessa's rent-payment transaction help describes two entries for a submitted payment. “Rent Payment” belongs to the tenant ledger and is categorized as Rent. The corresponding “Stessa Payout” is categorized as a Transfer. The rent entry intentionally has no account in the Account column because it isn't a direct bank movement. Check the payment's status before treating a submitted payment as confirmed.

That describes Stessa, not every property system. If you use something else, check its payout documentation before changing categories. Don't delete a record just because another record has the same amount: you may be looking at two stages of the same money.

Get the payout detail between the ledger and the bank

When all you have is a rent ledger and a bank total, the missing piece is often the payout breakdown. Gather the tenant ledger with charges, payment references and any adjustments; the processor's itemized payout detail; and the bank statement or native transaction export. Keep an untouched copy of each so your matching notes don't replace the source. If the tenant paid straight into your bank account, there's no processor payout to find: match the payment record directly to the bank receipt instead.

Use one receiving bank account and one currency for the comparison. Record the period each file covers, and fetch the following bank period if you're tracing money across month-end. That later statement helps explain the timing; it doesn't move an October bank receipt back into September.

For an eligible Stripe account, the Payout reconciliation report provides an Itemized CSV of the payments, refunds, disputes, fees and other balance transactions in each payout. Stripe documents it for automatic payouts, including platforms on manual payouts whose connected accounts use automatic payouts. Other manual-payout users are directed to the Balance report. Stripe says it cannot identify the transactions included in an instant payout.

You may not have a Stripe dashboard just because your property software uses a processor. Ask the property-software provider for its own payout breakdown instead. Keep the receipt ID, payout ID and bank reference together; names and similar-looking dates alone aren't a reliable matching key.

The tenant paid $1,000, not $2,000

This fictional USD example has one September charge of $1,000 for Tenant A. Assume the charge is agreed and there's no opening balance or adjustment. Confirmed payments of $600 and $400 are both allocated to that charge. The processor records payout P001 on September 30, and the bank receives its $1,000 two days later. No fee is withheld. These dates aren't a promise about processing times.

Tenant A's applied payments are $600 + $400 = $1,000. Subtracting them from this charge gives $1,000 - $1,000 = $0. Adding the payout to the receipts would show $2,000 paid, but there was no second payment. The bank row records the payout arriving, not another amount to credit to Tenant A.

There's also a separate $100 bank receipt from Tenant B. The payer is known, but the charge or purpose it belongs to hasn't been established, so it stays unallocated. Knowing who sent money doesn't tell you which charge to apply it against, and it doesn't make it Tenant A's payment.

At September 30, P001 has $1,000 not yet matched to a bank receipt. At October 2, its bank difference is zero, while the $100 allocation question remains open. The two October bank receipts total $1,100. That is a bank-receipts total, not a reason to increase Tenant A's rent payment or to describe all $1,100 as allocated rent.

Copy the example without adding the same money twice

Save this block as a CSV and import it into a blank sheet starting at A1, using commas as the delimiter. The header occupies row 1 and the six records occupy rows 2 through 7. Keep Amount numeric. These are comparison rows from different sources, not journal entries and not a file to upload into your accounting system.

Date,Event,Tenant,Applies_to,Batch,Amount,Source,Review
2026-09-01,Charge,Tenant-A,SEP-A,,1000.00,ledger-C1,Agreed
2026-09-28,Payment,Tenant-A,SEP-A,P001,600.00,receipt-R1,Confirmed
2026-09-30,Payment,Tenant-A,SEP-A,P001,400.00,receipt-R2,Confirmed
2026-09-30,Payout,,,P001,1000.00,payout-P001,Confirmed
2026-10-02,Bank,,,P001,1000.00,bank-line-12,Matched
2026-10-02,Bank,Tenant-B,,,100.00,bank-line-13,Unallocated

Applies_to is the charge reference, not merely the tenant's name. Batch connects a payment to its payout and that payout to the bank. The blank allocation on the $100 row is deliberate. Review is a conclusion you enter after checking the source, not a label the formula can verify for you.

Paste the following tab-separated block at J1 on the same sheet. It puts labels in J and formulas in K. These formulas use English function names and comma argument separators. The Microsoft SUMIFS reference documents adding only rows that meet all supplied criteria. Here the event type prevents payout and bank rows from entering the tenant-payment total.

Check	Amount
SEP-A charge	=SUMIFS($F$2:$F$7,$B$2:$B$7,"Charge",$D$2:$D$7,"SEP-A",$H$2:$H$7,"Agreed")
SEP-A applied payments	=SUMIFS($F$2:$F$7,$B$2:$B$7,"Payment",$D$2:$D$7,"SEP-A",$H$2:$H$7,"Confirmed")
SEP-A charge less applied payments	=K2-K3
P001 payout	=SUMIFS($F$2:$F$7,$B$2:$B$7,"Payout",$E$2:$E$7,"P001",$H$2:$H$7,"Confirmed")
P001 bank receipt	=SUMIFS($F$2:$F$7,$B$2:$B$7,"Bank",$E$2:$E$7,"P001",$H$2:$H$7,"Matched")
P001 bank difference	=K5-K6
Unallocated bank receipts	=SUMIFS($F$2:$F$7,$B$2:$B$7,"Bank",$H$2:$H$7,"Unallocated")
All bank receipts	=SUMIFS($F$2:$F$7,$B$2:$B$7,"Bank")

K2 through K9 should read 1,000; 1,000; 0; 1,000; 1,000; 0; 100; 1,100. There is intentionally no grand total of column F. Summing charges, payments, payouts and bank arrivals together would combine different things and count the same money repeatedly.

These eight checks don't test whether R1 and R2 really belong in P001. Confirm that link against the itemized payout report first. In this no-fee example, their $600 + $400 must account for its whole $1,000. A wrong Batch value on a Payment row won't change any of the eight results, so matching totals alone won't catch it.

A zero difference also isn't a completeness check. If both the payout and bank rows are missing or have the wrong Review labels, K7 can show zero because it subtracts zero from zero. Check each source row and Review label, including blanks, before relying on the totals. Only rows you mark Unallocated enter K8; the formula won't discover every unresolved receipt for you.

When adapting this sheet, use unique charge and payout references and extend every formula range beyond row 7 to include your added rows. For a September cutoff, make a separate working copy containing only records dated through September 30. Simply hiding October rows doesn't exclude them from these formulas: there's no date or visibility test. Keep the full source file unchanged.

K4 is charge less applied payments, not an arrears verdict. A negative number means the included allocations exceed the included charge; it doesn't tell you where the excess belongs. An opening balance, credit, returned payment or reversal needs separate review before this simple comparison can become a tenant account balance.

A later date or a smaller deposit needs an explanation

A month-end mismatch can be a timing difference, but write down the evidence rather than calling every missing deposit “pending.” Keep the payment date, payout date and bank posting date in their own records. In its payout timing documentation, Stripe says the report groups payouts by estimated arrival date, not bank posting date. It also says weekends, holidays and bank processing can affect arrival. The two-day gap above is only the fictional example.

If one payout covers several tenants, retain each payment's tenant and charge reference, then group those payments under the payout ID shown in the processor detail. Match that group to one payout and its bank arrival. Don't assign the whole bank deposit to whichever tenant happens to have a similar rent amount. If a payment is split across payouts, keep separate linked allocations that add back to that payment rather than repeating its full amount in each batch.

Fees need the same care. Stripe's itemized report documents gross, fee and net fields and includes other balance activity, so the bank deposit needn't equal gross tenant collections. Compare the report's net payout to the bank and retain its fee and adjustment detail separately. Don't reduce a tenant's recorded payment merely to make it equal the deposit, and don't call an unexplained shortfall a fee. The bookkeeper needs the actual report to decide the entries.

Hand over the exceptions, not just a balanced total

A useful handoff says what you matched and what is still unknown. Attach the source references to each exception, with a named person responsible for the next check. For the fictional example, the handoff is short:

• At September 30: P001, $1,000, recorded as sent but no bank arrival in the period. Check the following statement. Retain this cutoff note even after matching bank line 12 on October 2.
• At October 2: bank line 13, $100 from Tenant B, remains unallocated. Ask the property manager to confirm the intended charge or purpose from the remittance information; don't apply it to SEP-A.
• SEP-A: receipts R1 and R2 total $1,000 against the $1,000 illustrative charge. P001 and bank line 12 are linked records, not additional tenant payments.

In your own file, add any payout with no bank match, bank deposit with no payout breakdown, unexplained net difference or payment whose allocation is disputed. State what is missing: “need P001 itemized report” is much more useful than “reconciliation issue.” Our statement review-log guide shows how to leave source references and unfinished checks for the next person.

For the narrower job of allocating known bank receipts to charges, try the rent-payment matcher. You choose the allocations; it doesn't reconstruct processor payouts. Keep the payout breakdown alongside it rather than treating a bank receipt as the tenant's gross payment.

Stop at record comparison if the next question is about arrears, notices or eviction. For US properties, USA.gov's guide to landlord disputes points tenants to state agencies and legal help. Use the official rules and qualified advice for the property's location. This worksheet supplies no legal conclusion.

Keep the bank rows traceable too

Try your bank's own CSV export first. If the older bank side exists only as PDFs, AnyStatement can convert those statements into rows for comparison, but it can't supply the missing tenant allocations or processor payout breakdown. Check the extracted rows against the original statement before using them in this worksheet.

We reopened the linked Stessa, Stripe, Microsoft and USA.gov pages on October 17, 2026. Stessa's ledger guide shows November 14, 2025; USA.gov shows April 15, 2026. The other opened pages have no displayed update date. We parsed the CSV and checked all eight formulas' equivalent arithmetic with Python Decimal, including the two cutoffs, partial payments, mismatched references and missing Review labels. We didn't run Excel or test a live property-software account or payout. No legal, tax or trust-accounting treatment was inferred from the vendor pages.