How to Import Historical Bank Transactions Into Buildium Without Creating Duplicates

Every property manager who migrates into Buildium hits the same wall in the first week. The bank feed connects, three months of transactions appear, and everything before that is simply not there. If you took over a portfolio, migrated from spreadsheets, or need reconciled trust account history for a state exam, three months is not enough.

Here is the workflow for filling in the rest without ending up with duplicated transactions and a reconciliation that will not close.

How far back does the Buildium bank feed go?

A new bank feed connection typically imports around the last 90 days of transactions, and the exact window varies by financial institution. Feeds refresh several times a day, roughly every four to six hours on weekdays and less often at weekends, and recent items can take a day or two to appear while the bank releases pending transactions. None of that is a fault in the software. It is how aggregated bank connections work everywhere, which is why any historical period has to come in through a manual import.

Can you import bank transactions into Buildium manually?

Yes. Alongside the live feed, Buildium supports importing transactions from a CSV or OFX file taken from the bank's transaction history. That manual path is what covers everything the feed missed. What it will not do is read a PDF, and the monthly e-statement is a PDF, so a conversion step sits between the documents you have and the file Buildium wants.

The step by step backfill

1. Work one bank account at a time. Do not batch the operating account together with security deposit or owner trust accounts. Trust reconciliation depends on being able to show each account separately, and a mixed import file makes that impossible to prove later.

2. Gather every statement for the missing period. Most US banks keep PDF e-statements online for around seven years, well beyond the window their CSV download offers. If the account is closed, whatever you archived is the record.

3. Convert the statements into rows. Each line needs date, description, and amount as separate columns, with the running balance kept alongside. A Buildium bank statement converter takes the PDFs and returns exactly that, and several months can go through at once so you get one continuous sheet in date order.

4. Check every period ties. For each statement period, confirm the transactions sum from the opening balance to the closing balance printed on the statement. This is the single most valuable five minutes in the whole process. A period that does not tie now becomes a reconciliation you cannot close in three weeks, by which time nobody remembers which file it came from.

5. Disconnect the live bank feed. If the feed is already connected, disconnect it before importing history. This stops it pulling the same dates you are about to import.

6. Import the historical file and reconcile period by period. Do not import two years and then attempt one reconciliation. Reconcile each month against its statement, in order, so a discrepancy is isolated to one period instead of hiding somewhere in twenty four.

7. Check the boundary, then reconnect. Before reconnecting the feed, compare the last date in your imported file against the first date the feed will fetch. If they overlap, remove the duplicated days from the imported side rather than the feed side, because the feed is the version that keeps updating.

How do I stop duplicate transactions when importing?

Duplicates come from three places, and all three are avoidable. Overlapping date ranges between a manual import and a live feed, which the disconnect and boundary check above prevents. Importing the same file twice after an error, which is why it helps to name files by account and period and keep a short log of what was imported when. And transactions already entered manually in Buildium as bills or receipts that then arrive again from the bank, which is not really a duplicate so much as an unmatched pair, and gets resolved during reconciliation by matching them rather than deleting either side.

If duplicates do get in, fix them before reconciling, not after. Deleting transactions from a reconciled period reopens the reconciliation and, in a trust account, breaks the audit trail you may need to produce later.

Trust accounts need more care than operating accounts

Security deposit and owner trust accounts carry a legal obligation that the operating account does not. In most states the requirement is a three way reconciliation: the bank balance, the book balance, and the total of the individual tenant or owner ledger balances all have to agree at period end. If any historical period is imported approximately, the three way tie fails and you will not be able to tell whether the cause is a missing transaction, a misposted ledger, or a real shortage.

So for trust accounts specifically: one account per import file, every period tied to its statement before import, and the converted sheet kept as a working paper alongside the reconciliation. The three way trust account reconciliation guide covers how the three balances are built and what to do when they disagree.

What if the transactions are not categorized?

Bank descriptions are not property management categories. A row reading ACH DEBIT PROPERTYVENDORLLC tells you nothing about which unit the work was done on. Two habits make this manageable at volume. Set up the payee matching rules in Buildium before the import rather than after, so the incoming rows land against something. And do the bulk coding in the spreadsheet, where you can sort by description and code two hundred similar rows in one pass instead of clicking through them individually. Working from a converted sheet, you can categorize the transactions before they ever reach the ledger.

For maintenance and repair spend in particular, the bank line is only half the record. The other half is the receipt or invoice that proves what the payment was for, which owners ask about and auditors expect to see. Keeping those attached as you go, rather than reconstructing them at year end, is a lot easier if the receipts are captured and coded automatically as they come in.

Why does my Buildium reconciliation not match the bank statement?

Four causes account for nearly all of it. Transactions the feed never pulled because they predate the connection, which is the whole reason for the backfill. Items entered in Buildium that have not yet cleared the bank, which are legitimate reconciling items rather than errors. Bank fees, interest, and returned item charges that appear on the statement but were never entered. And duplicates from an import that overlapped the feed. Working through the statement line by line against the register finds all four, and the converted sheet makes that a sort and filter exercise rather than a page by page read.

Doing this once rather than every quarter

Backfilling is a project. Keeping the books reconciled is a habit. Once history is in and every period ties, reconcile monthly, within a week of the statement date, while you still remember what the odd transactions were. Property managers who let three months slide end up doing this whole exercise again, and the second time it usually happens under a deadline set by an owner or an examiner rather than by themselves. If several months have already slipped, working from the statements is still the fastest route back, and the catch up bookkeeping workflow covers how to sequence it.