The problem

Every property manager knows this shape: your property management software is where the leases, rent rolls, work orders, and tenant contacts live. But it’s not where the work actually happens.

Leasing calls come in on the phone.
Maintenance requests trickle in over text.
Rent questions land in a shared email inbox nobody has time to fully triage.
Tasks and follow-ups live on a board that doesn’t know anything about the ledger.
When your partner asks “how did we do this week?” — you’re opening four tools, cross-referencing PDFs, and half-guessing.

The software has the record. The team is flying blind between one weekly export and the next.

There’s a deeper version of this problem, though, and it’s the one that actually matters. Each of those tools only shows you your own data the way that software decided to show it. You can run the reports the vendor built. You cannot ask a question the vendor didn’t anticipate. Want to know which units generate the most after-hours calls per dollar of rent? That report doesn’t exist, and it never will, because no vendor is going to build it for you.

You don’t have a reporting problem. You have an ownership problem.

The approach

Copy everything, continuously, into one store you control.

Not another dashboard bolted on top of the PM software — a live, independent copy of the operational data, pulled from every system that holds a piece of it. Once the data lives somewhere you own, the ceiling comes off: you can ask anything, cross-check anything, and automate anything.

Nine sources feed it. The property management software (ledger, rent roll, leasing, work orders), the phone system with call transcripts, text messages in both directions, the shared rent inbox, the task board, mailed letters, and a set of signals the system computes for itself — risk flags, rankings, delinquency movement.

Each source keeps its own timer and refreshes on its own rhythm. The task board syncs roughly hourly because it changes constantly. Conversations land a few times a day. Heavy financial pulls run about daily. Mailed letters sync when there are letters. Nobody presses a button.

What we built

A 57-table warehouse covering properties and units, tenants and leases, the leasing pipeline, the general ledger and monthly financials, maintenance, every communication, and a computed intelligence layer on top.
A unified event timeline. Every call, text, email, work order, ledger movement, and task comment becomes one searchable row tied to its property and tenant. Roughly 5,000 events a month flow in.
A dashboard shaped like the team’s actual questions — today, leasing, financials, activity, insights — one real question per tab, not one data source per tab.
A plain-English query layer. Ask “which properties are most delinquent right now?” and get a ranked list built from the ledger and tenant balances, with the underlying rows shown so the answer can be checked. The same brain is reachable from inside the task board: tag it on a task, get the answer in the thread, nobody leaves the tool they’re already in.
Guardrails that assume the pipeline will fail. More on this below, because it turned out to be the most important part.

The numbers

These are measured from the live system, not estimated.


Sources feeding the warehouse	9
Tables	57
Events captured per month	~5,000
Ledger entries written in a single recent nightly run	3,026
Bank accounts refreshed per run	82
Monthly API budget against the PM software	15,000 calls, self-enforced

And the recovery, which is the number that actually matters:

	Before	After
Bookkeeping	$3,800/mo outside firm	$0 — automated bank-to-book reconciliation
Getting an answer to “who called yesterday?”	~6 hours	~8 seconds
Weekly partner-meeting report prep	~4 hours	~0
Onboarding “where does this live?“	8–12 weeks	Same day

That first row is $45,600 a year, and it’s the honest headline. The dashboard is nice. Not paying a bookkeeper because the numbers tie out on their own is the thing that paid for the build.

The part nobody puts in a case study

A data pipeline that quietly does the wrong thing is worse than one that visibly breaks. So the interesting engineering here isn’t the syncing — it’s what happens when a sync goes wrong.

Three examples from real runs:

It refuses bad data instead of writing it. The ledger sync came back with 2,652 rows against an expected floor of 3,997. Rather than write a short month into the financials and let someone make a decision on it, the job failed itself and logged why. Nobody found out later.

It flags its own partial failures. A recent run refreshed bank balances across 20 targets. One errored. The run recorded “1 of 20 targets errored” rather than reporting success on the 19 — because a sync that silently drops one account is how a reconciliation quietly goes wrong three weeks later.

It protects its own budget. The PM software’s API is capped monthly. When the system approaches the cap it pauses its own fetches instead of overrunning, and rations the heaviest financial pulls down to roughly daily. That constraint is why the ledger refreshes daily rather than hourly — a deliberate trade, not a limitation we backed into.

None of that is glamorous. All of it is the difference between a system the team trusts and a dashboard nobody checks twice.

The lesson

The individual features aren’t the interesting part. Any competent developer can build a dashboard.

The interesting part is that the data is yours. Every future thing you bolt on — renewal reminders, delinquency alerts, “which unit costs us the most to maintain,” automated reconciliation — plugs into the same store. You don’t rebuild the plumbing each time. The reconciliation that replaced the bookkeeper isn’t part of this system; it’s a separate thing that reads from it. It couldn’t exist without it.

If you’re a property manager who feels like your team is flying blind between exports, the highest-leverage move isn’t a prettier report. It’s owning the place where every tool’s data lands, so the next question you think of is one you can actually answer.

That’s the receipt. The rest is just what you choose to bolt on next.