Article

Why Buildium and QuickBooks don't match

It's the end of the month. You pull the general ledger out of Buildium, you pull the same period out of QuickBooks, and the two don't agree. Not by a little. There are transactions on one side that aren't on the other, amounts that differ by a few dollars, entries sitting on dates that don't line up.

The first question isn't how do I fix this. It's is this even broken?

The short answer

Most of the time, no.

Two systems that were never designed to be copies of each other will not look alike, and they aren't supposed to. Your property software records what happened to a property. Your accounting system records what happened to the company. They overlap, and the overlap is where the confusion lives.

The useful question isn't whether the two ledgers look the same. It's whether every real difference between them can be explained. Most differences have perfectly good explanations. A few don't, and those are the ones worth your afternoon.

What actually causes the gaps

In practice the disagreements fall into a small number of shapes.

Something is in one system and not the other. A transaction exists in the property software with no counterpart in the books, or the reverse. Both directions happen and they mean different things. Missing from the books usually means something didn't get carried across. Missing from the property software often means it was entered straight into accounting.

The same transaction appears twice. Usually because it arrived by two routes — imported once, and keyed in once by someone who didn't know it had already come across.

The amounts disagree. Same transaction, same date, two different numbers. Often a transposition; sometimes a partial payment recorded in full on one side.

The dates disagree. The property software records the date the charge occurred. The books record the date it was posted. Around a month boundary those land in different months, and both systems are right. This is the one that most often looks like a missing transaction when it's really a timing difference.

A credit exists on one side only. A refund, a concession, or a write-off applied in one system and never mirrored in the other.

None of these are exotic. What makes them hard isn't naming the shapes — it's that a month holds hundreds or thousands of rows, and finding which ones are affected is a manual comparison nobody has time to do properly.

The one that fools almost everybody

Here's the part that matters most, and the part a comparison tool is most likely to get wrong.

Plenty of bookkeepers don't carry every transaction from the property software into QuickBooks. They post one monthly summary journal entry instead. Twelve maintenance charges become one line. Buildium even ships a tool for exactly this — "Export Management Income" produces a journal entry file meant to be imported whole.

A bookkeeper who works that way has done nothing wrong. It's a normal, defensible way to connect two systems, and it keeps the accounting ledger readable instead of drowning it in property-level detail.

Now look at what it does to a naive comparison. If you match row against row, those twelve transactions in the property software have no partner in the books. A tool that only knows how to compare rows reports twelve missing transactions. Do that across a whole chart of accounts and it doesn't report one wrong finding — it reports that your entire ledger is broken, confidently, while your books are perfectly fine.

That's the most expensive mistake this kind of tool can make. It isn't one bad row. It's all of them.

I found this before a customer did, because I went looking for how I could be wrong before I let anyone upload anything. It turned up in research — first in how practitioners describe their own month-end, then in Buildium's own documentation for that export. Since then I've seen a working bookkeeping firm name summary entries as the number one reason these two systems disagree. It is not an edge case. It is the normal arrangement.

So the comparison has to recognise it: if the unmatched transactions in one account, in one month, add up exactly to a single journal entry on the other side, that isn't twelve missing transactions. It's one summary entry doing its job, and it should be reported as a match — with the detail behind it kept visible, so you can still see what it summarises.

Three details matter for doing that honestly:

• It has to be the whole remainder, not a convenient subset. Hunting for some combination of transactions that happens to add up to the right number will always find something eventually. That isn't reconciliation, it's numerology. Either everything left over in that account and month sums to the entry, or it doesn't.
• A partial roll-up stays a finding. If the summary entry covers most of the transactions but not all of them, the leftovers are a real discrepancy and should be reported as one.
• When it can't tell, it should say so. Two candidate entries that could each be the summary. An account and month that balances but names no single entry doing the summarising. A transaction that two summary entries both want. In every one of those cases the honest answer is "I couldn't determine this" — not the reading that makes the most findings disappear.

That last one is on purpose. In bookkeeping there is no compromise on the data — if something is inaccurate, the job isn't done, however good it looks. So I would rather Berean say "I don't know" than tell you what you want to hear. But I don't treat that message as a feature. Every time Berean can't determine something, that's on me: it means I haven't done my part yet, and the list of things it can't determine is a list I intend to keep making shorter.

Check this before you compare anything

Make sure both exports are on the same accounting basis. Cash and accrual don't disagree by accident — they disagree by definition, and comparing across the two produces differences that mean nothing at all.

Buildium marks cash postings. A QuickBooks general ledger report carries a basis footer. If either file doesn't say, you need to know which it is before the comparison means anything — and any tool that assumes without telling you has quietly made a decision that becomes a wrong number you can't trace.

Berean checks this before it compares anything. When the two files disagree on basis it still runs — it sorts both sides into cash and non-cash first, and cash is cash under either basis — and it tells you which file is which and names what it set aside.

Doing it by hand

If you're working through this yourself:

1. Confirm both exports cover the same period and the same basis.
2. Start with the accounts where the two systems disagree by the largest dollar amount, not the largest number of rows. A hundred timing differences of nine dollars matter less than one missing four-thousand-dollar entry.
3. Before treating anything as missing, check whether it was rolled into a summary entry for that account and month.
4. Check dates around the month boundary before concluding anything is absent.
5. Write down what you concluded and why. Next month you'll be looking at the same accounts, and past-you is the only person who can save present-you any time.

That's the work. It's completely doable — it just costs hours you'd rather spend elsewhere, every single month. And when it gets away from you, the usual next step is paying someone outside to come in and sort it out.

Where Berean fits

That's what I built Berean to do, and that's the part I care about most: the hours.

You upload the general ledger export from your property software and the general ledger export from QuickBooks. Berean compares them transaction by transaction and reports where they disagree — transactions one ledger has and the other does not, and amounts that disagree where both ledgers have the transaction. It understands summary entries, so it won't accuse books that are kept correctly. And it is deterministic: no model, no network, no clock in the comparison, so the same two files always produce the same result.

The free audit tells you the size of the problem. It reports how many findings each check produced and what they add up to in dollars, the exact window it compared, what fell outside that window, and what it could not check. It does not show you the rows — no account names, no counterparties, no memos. That is a deliberate line: the free audit never stores a prospect's ledger. Not one row, not one finding, not one run. It is computed, shown, and forgotten, which is only a promise anyone should believe because there is nowhere for it to write in the first place.

A paid workspace is where you see the rows. The full report, every finding with the exact transactions behind it so you can judge it instead of taking its word — and a correction worksheet that works on causes rather than one finding at a time. You decide once what is behind a group of discrepancies, and that decision carries: to the related check, and to findings that didn't exist when you made it. It runs the same deterministic engine the free audit runs. The difference is what you're allowed to see and keep, not how it thinks.

What I want you to get out of it is simple: the work that has been eating an afternoon every month gets done in minutes, on your screen, with the receipts attached — and the outside cleanup engagement stops being the only way out.

The audit is free, nothing you upload is stored, and there's an example report built from invented figures if you'd like to see the shape of the output before uploading anything.

Run the free audit →