Ask a property team where the numbers live and you will usually get three answers.
The books are in an accounting system. The underwriting model is in a spreadsheet, often the very one used to close the deal. Investor reporting is a set of documents assembled each quarter from both. Each is maintained by different people, on different schedules, and none of them is authoritative for the others.
This is not carelessness. It is what happens when the tools available were each designed for one of the three jobs.
The reconciliation tax
Every boundary between those systems has to be crossed by hand, and each crossing costs something:
- Month-end stretches. Close waits on figures exported from one system and re-entered in another, then checked because they were re-entered.
- Variance goes unwatched. Comparing actuals to the underwriting is a project rather than a report, so it happens annually — long after the divergence started.
- Investor reporting is rebuilt. Capital accounts are recalculated from prior statements and current cash, under deadline, by whoever knows the spreadsheet.
- Questions get expensive. “Why did that number move?” requires two exports and three people.
None of these is dramatic on its own. Together they consume a meaningful share of a finance team’s month, and they consume it on work that produces nothing new.
Integration is not the same as unification
The usual answer is to connect the systems: a sync between the accounting platform and the reporting tool, an import from the model into the dashboard. This helps, and it does not solve the underlying problem.
A sync means one system holds a copy of another system’s data. Copies drift. They drift when a correcting entry is posted after the sync ran, when a mapping is incomplete, when a field means something slightly different on each side. So you reconcile the copies — which is the work you were trying to eliminate.
What changes with one ledger
The alternative is architectural: keep a single double-entry ledger designed for real estate, and treat accounting, analytics, and investor reporting as three views of it rather than three systems that exchange files.
The practical consequences are specific.
A correcting journal entry posted this afternoon changes the financial statements, the variance report, and the affected capital accounts at the same moment — because none of them is a copy. There is no window during which two screens disagree.
Underwriting assumptions stay attached to the property after closing, so actuals post against them continuously. Variance is a standing report rather than an annual reconstruction.
Capital accounts derive from the same records that produce the property’s financials. An investor statement cannot drift from the entity’s books, because neither is downstream of the other.
And every figure traces back through one history. When an owner, a lender, an auditor, or a limited partner asks how a number was produced, the answer is the same set of transactions regardless of who is asking.
The honest trade-off
A unified ledger is harder to build than a set of connected tools, and it demands more at implementation — your chart of accounts, entity structure, and ownership have to be modelled properly before the benefits appear. That is real work, and we would rather say so than pretend otherwise.
What you get for it is that the work stops recurring. Setup is finite. Reconciliation between systems is not.