Troubleshooting
Nine mechanical causes, in the order you should check them — each with the exact fix.
Updated 2026-07-16 · TrustRecon research team
It's month-end. You've uploaded the bank statement, cleared every transaction you can find, and Buildium's reconciliation screen is still showing a difference. Whether it's $12.50 or $12,000, the cause is almost always mechanical. Work through the nine checks below in order and you will find it.
The list runs from most-structural (a wrong number baked in from the start) to most-recent. Rule out foundational problems first — skipping ahead wastes time.
What it looks like: The reconciliation is off by the same fixed amount every month, regardless of current-period activity.
Why it happens: At account setup you entered an opening balance. If that number didn't match the prior bank statement exactly, the error carries forward permanently — Buildium's Help Center states this directly. The problem compounds when migration balances are entered as journal entries rather than actual transactions: JEs update the GL but don't create clearable items on the reconciliation screen. For more on correct setup, see our guide to Buildium bookkeeping.
How to find it: Pull your last twelve monthly reconciliation differences. A constant figure points to a carry-forward opening balance error. Check for journal entries dated near your go-live date that touch the bank account.
How to fix it: You cannot change a posted opening balance. Create a correcting journal entry in the current period for the exact difference, document it, and reconcile cleanly from there.
What it looks like: The difference equals the amount of a specific rent payment or receipt. It appeared suddenly in one month and has not changed since.
Why it happens: A payment cleared in month M was voided in month M+1 — to re-enter it or reverse an NSF. Buildium dates the void in M+1. The original positive receipt is locked in M's closed reconciliation; the negative void is in M+1's open window. They live in different windows and never offset. The Adjusted Cash Balance (ACB) is permanently short by that amount. APM Help identifies this cross-period void as one of the most common single causes of a Buildium reconciliation that won't balance.
How to find it: Look at voided transactions in the current and recent periods. For each void, find the original receipt. If the original was cleared in a prior period, you have your cause.
How to fix it: Do not re-void or un-void. Create a manual offsetting transaction in the current period to neutralize the ACB mismatch. If the void was for an NSF, record the bank return as a separate reversal dated in the correct period.
What it looks like: The bank statement shows a debit — often a large round number — with no matching entry anywhere in Buildium's register.
Why it happens: A NARPM Buildium Google Group thread documented this directly: a manager made monthly bulk transfers from the Rental Escrow account to the General Operating Account at the bank level with nothing recorded in Buildium. The cumulative result was a $4,579.68 unexplained balance that couldn't be tied to any documented reserve or deposit. The correct workflow — "Collect Management Fees" then "Pay Out Management Income Accounts" — must run inside Buildium, not be replaced by a direct bank wire.
How to find it: Compare bank statement debits month by month against Buildium register disbursements. A persistent gap where bank debits exceed PMS outflows signals off-system transfers.
How to fix it: Record each unlogged transfer using the Buildium fee-payout workflow. Going forward, never initiate the bank transfer until Buildium has generated the register entry.
What it looks like: The Buildium register balance exceeds the bank balance by exactly the amount of one or more payments. You can see what appears to be the same transaction twice in the register.
Why it happens: A staff member manually records a tenant payment; the bank feed then imports the same deposit. APM Help documents this precisely: a tenant pays $1,200, it appears twice in Buildium, and the register exceeds the bank balance by exactly that amount.
How to find it: Sort the register by amount and look for same-day, same-amount, same-payee pairs. One entry should exist per real bank transaction, not two.
How to fix it: Delete or void the duplicate — not both. Pick one workflow (manual entry or bank feed) per transaction type and stick to it.
What it looks like: The bank statement shows debits with no Buildium match. The difference equals the total of those unmatched items.
Why it happens: Bank service charges, wire fees, and NSF fees don't self-post to Buildium — someone must record them manually. The NCREC identifies unrecorded bank fees as a specific audit finding: even a $25 monthly service charge left unrecorded creates a $25 unexplained difference. Until the fee is reimbursed from the operating account, client funds absorb the cost.
How to find it: During each reconciliation, scan every bank debit for a matching register entry. Bank-initiated charges are the most common source of small, persistent out-of-balance amounts.
How to fix it: Record bank fees in Buildium against the broker equity sub-ledger — not an owner or tenant ledger — and reimburse from the operating account.
What it looks like: You void checks older than 90 days to clean up the outstanding list. A new reconciliation difference appears, equal to the voided amounts.
Why it happens: Voiding a check removes it from the outstanding list and raises the ACB. But if the payee's sub-ledger isn't re-credited, the bank balance and ACB are now higher than the sum of all sub-ledger balances by exactly the voided amount — money parked in the pooled trust balance with no beneficiary. NCREC and Rentvine both cite this as a leading cause of three-way reconciliation failure.
How to find it: After voiding any check, confirm the same amount was re-credited to the original payee's sub-ledger. The sub-ledger trial balance total must equal the reconciled bank balance.
How to fix it: Re-credit the appropriate sub-ledger, then decide whether to reissue the payment or file an unclaimed property (escheatment) report. See our three-way reconciliation guide for how this fits the full three-leg test.
What it looks like: The bank balance and GL balance match, but the sum of all owner sub-ledger balances is short. A suspense or clearing account is carrying a positive balance.
Why it happens: When a payment arrives without a clear tenant or property identifier — an ACH wire missing a unit number, a check with an unclear memo — Buildium parks it in suspense. The trust control account is credited but no owner sub-ledger receives the funds. The deposit is in the bank and the GL is credited, but no client account holds the balance.
How to find it: Check the suspense or clearing account balance at every reconciliation. Trust GL credits for the period must equal owner sub-ledger credits for the same period.
How to fix it: Match each suspense item to the correct tenant and property and post it to the sub-ledger. Set a 24-hour rule for unidentified receipts.
What it looks like: The Prepayments account shows a negative balance. The rent income account reflects collected rent that has no cleared funds behind it.
Why it happens: A tenant pays September rent by EFT on August 31. Buildium routes it to Prepayments. On September 1 the system moves it to Rent Income. On September 6 the bank returns the EFT. The reversal hits Prepayments — now empty — instead of Rent Income, which already received the credit. Prepayments goes to -$1,200; Rent Income still shows $1,200 collected with no cash behind it. This exact sequence was documented in the NARPM Buildium Google Group.
How to find it: After any EFT return window, check the Prepayments account for a negative balance and cross-reference returned items on the bank statement against recent prepaid tenant entries.
How to fix it: Reverse the Rent Income entry for the returned amount and post a correcting entry to clear the Prepayments negative back to zero.
What it looks like: The reconciliation has been off since shortly after going live on Buildium. The difference isn't a fixed constant — it shifts as multiple underlying data problems interact.
Why it happens: At migration, owner ledger balances, tenant ledger balances, and the trust bank account balance must all be entered as of the cutover date. If any number is wrong, or if balances were entered as journal entries instead of clearable transactions, the error propagates indefinitely. Balanced Asset Solutions documented a case where inaccurate opening balances and improper journal entries distorted the Adjusted Cash Balance so badly the firm had to draw on company funds to cover negative property-level balances (AppFolio setup, but the mechanics are identical in Buildium).
How to find it: Go back to your first reconciliation. A non-zero difference there is your migration error. Also look for journal entries dated near your go-live date that touch trust bank accounts — they will never clear.
How to fix it: Reconstruct correct opening balances from your prior system's final reports and the bank statement at cutover. Enter correcting transactions — not journal entries — to align the Buildium register with the bank. If the error is more than a few months old, a TrustRecon audit traces each discrepancy to its origin and delivers a documented correction path for every open item.
| # | Cause | Signature Symptom | First Place to Look |
|---|---|---|---|
| 1 | Wrong opening balance | Same fixed difference every month | First reconciliation; migration JEs on bank account |
| 2 | Cross-period void of cleared receipt | Difference appeared in one specific month and stayed | Voided receipts: original period vs. void period |
| 3 | Bulk transfer bypassing Buildium | Large round-number bank debit with no register entry | Bank debits vs. PMS disbursements by month |
| 4 | Duplicate entry (manual + bank feed) | Register > bank by one payment amount | Same-day, same-amount, same-payee pairs in register |
| 5 | Unrecorded bank fees or NSF charges | Small persistent difference, no matching entry | Every bank debit vs. Buildium register |
| 6 | Stale check voided without sub-ledger re-credit | New difference after voiding old outstanding checks | Sub-ledger trial balance vs. reconciled bank balance |
| 7 | Unallocated receipts in suspense | Bank and GL match; sub-ledger sum is short | Suspense or clearing account balance |
| 8 | Prepaid EFT reversal orphan | Prepayments account shows a negative balance | EFT returns on bank statement vs. Prepayments account |
| 9 | Migration balance errors | Off since go-live; multiple sub-ledgers wrong | First reconciliation difference; JEs on migration date |
If you've worked through all nine and the out-of-balance persists, the problem is almost certainly multiple causes layered across months. A California DRE audit found one PMC whose internal reconciliation showed no discrepancy while the actual shortage was $46,729.72 — small errors that individually passed a visual check. The three-way reconciliation is the only test that catches them all: bank statement balance, Buildium GL balance, and the sum of every owner and tenant sub-ledger must all agree. A free trust account audit delivers a transaction-level explanation for every open item.
Upload three exports. Within 48 hours you get a discrepancy report with every finding tied to a record ID. Built from the same failure patterns state auditors look for.
For property management companies on Buildium or AppFolio. No call required.