Centralising lease data means establishing a single, controlled register that finance and property teams both read from and write to, with defined workflows for each team, no duplicate systems, and automated synchronisation to your general ledger. The most common failure is choosing a system that solves for one team (usually finance) while leaving property in spreadsheets. This guide explains why that happens, what it costs, and how to fix it in six steps.
The divide between finance and property is not a communication problem. It is a structural one. Both teams are doing their jobs correctly, with fundamentally different tools, different definitions of urgency, and different timelines.
Finance teams are organised around compliance cycles: IFRS 16 calculations, month-end close, audit deliverables. They need accurate amortisation schedules, journal entries, and disclosure reports. Their system of record is shaped by when the audit happens, not when the lease event happens.
Property teams operate on the lease itself. A property manager tracks when the rent review window opens, whether the option notice period has been triggered, what the make-good obligations look like at a site coming up for expiry. These events are urgent right now, not at the end of the quarter.
The result: two teams managing the same asset from different systems, syncing via email, spreadsheet exports, and manual handoffs at month-end. Data diverges from the moment it enters two separate systems. By the time both teams realise it, a rent review has been missed, a modification has been processed in finance but not updated in property, or an auditor is asking why the numbers do not reconcile.
| What property sees | What finance sees |
|---|---|
| Upcoming rent review dates and negotiation windows | Current rental payment amounts in the amortisation schedule |
| Lease expiry and option exercise deadlines | Remaining lease term used for ROU asset depreciation |
| Negotiated rent changes and commercial terms | Remeasurement triggers requiring a new IFRS 16 calculation |
| Site cost comparisons and portfolio timelines | Right-of-use asset balances and lease liabilities on the balance sheet |
| Spreadsheet or property management system | Dedicated IFRS 16 tool or ERP module |
When these views live in separate systems, the data does not automatically reconcile. Someone, usually in finance, has to bridge the gap manually each month.
The cost of siloed lease data is not abstract. It shows up in three specific places: the time lost to reconciliation, the errors that compound across manual handoffs, and the milestone misses that carry real financial consequences.
Sources: LOIS independent Kantar market survey of finance professionals; LOIS client portfolio data
Data duplication is the first cost. When property enters a new lease into their system and finance enters the same lease into an IFRS 16 tool, you have two versions of truth from day one. Every modification, every extension, every rent review outcome has to travel between two systems, usually via email or a shared spreadsheet. Errors do not cancel out; they accumulate.
Missed milestones are the second cost, and the more dangerous one. Rent review windows, option exercise deadlines, and lease expiry dates are time-sensitive commercial decisions. A missed rent review at market could mean paying above-market rent for years. A missed option exercise could mean losing a critical site. A system that does not connect property's operational calendar to finance's compliance calendar is a system that will eventually miss something material.
Reconciliation overhead is the third cost. Finance managers who spend their month-end chasing property for aligned data are not doing strategic work. Property managers who manually re-key data from an IFRS 16 system into their tracking sheet are not managing the portfolio. Both teams are doing administration that a well-architected single system would eliminate.
A centralised lease platform is not a spreadsheet that both teams can access, and it is not a finance tool with a read-only portal bolted on for property. It is a single register with clearly defined roles for each team, automated workflows connecting their actions, and a general ledger integration so finance's calculations are always working from current data.
Architecturally, it works like this. There is one lease record per lease, with a single point of data entry. Property inputs operational data: the lease terms, commercial events, rent review outcomes, and key dates. Finance works from that same record to run IFRS 16 calculations, generate journal entries, and produce audit-ready disclosures. When property updates a record, finance sees it immediately. When a rent review concludes and the new rate is entered, the IFRS 16 remeasurement triggers automatically, not after a manual handoff.
"One source of truth means property can't act without finance knowing, and finance can't calculate without property's data. That is not a process change. That is an architectural one."
The workflow layer is what makes this real. A unified platform connects property milestone notifications to finance approval workflows: a lease extension initiated in property triggers a review in finance before it is finalised. A modification cannot be applied without crossing the workflow boundary between both teams. This structure enforces collaboration by design, rather than relying on teams to remember to tell each other.
The GL integration is the last piece. Automated synchronisation between the lease register and your general ledger means finance does not spend month-end manually reconciling what changed during the period. The journals are prepared from the current data, and the audit trail shows every change and who made it.
Centralisation is a data management project as much as a system selection project. Most organisations that fail at it select a platform before they have resolved the underlying data and workflow questions. These six steps address that in the right order.
Most centralisation projects that fail do so for one of three reasons, and all three are avoidable.
LOIS is built as a unified platform for both teams. The architecture described above is not aspirational in LOIS; it is how the system works.
On the property side, the LOIS property management module gives property teams automatic milestone reminders for rent reviews, expiries, and options; portfolio timelines showing the full calendar of upcoming events; cost comparisons by square metre; and workflow approvals that connect property actions to finance review before they are finalised.
On the finance side, those same property events trigger the accounting workflows: remeasurements are notified when payment amounts change, journal entries are generated from current data, and the full audit trail captures every modification with a timestamp and user record.
For organisations managing a high volume of leases, the LOIS managed service adds a layer of CA-qualified accountants who validate data, run the calculations, and deliver fully reconciled, audit-ready outputs each month. The system and the expertise operate from the same record, so there is no handoff between the managed service team and the platform.
LOIS handles portfolios from 30 leases to over 10,000, covering property assets valued at over AUD 50 billion. The platform scales with the portfolio, and the audit trail holds up under scrutiny because every change is captured with a timestamp and user record.
Updated April 2026