Every month-end, a finance controller at an Australian infrastructure company opened the spreadsheet, ran the AASB 16 model, and posted the journals. The numbers tied. Depreciation looked right, interest looked right, and the liability balance moved in the direction it should. She was, by any reasonable measure, on top of it. Then the auditor asked for the reconciliation between the lease subledger and the GL balance. There wasn't one. The journals had been posted correctly for two years, but nothing proves they were posted correctly. That is the gap between "we ran the numbers" and "we can prove the numbers are right." Under AASB 16 and NZ IFRS 16, the audit test is the second question, not the first.
Updated August 2026.
This guide covers what weak GL control actually looks like, what auditors are testing for, and how a properly controlled process eliminates the reconciliation problem before it becomes an audit issue. For a broader look at the six areas Australian and New Zealand auditors focus on, see our post on IFRS 16 and AASB 16 compliance audit focus areas.
The scenario above isn't unusual. It's the normal state for organisations managing AASB 16 and NZ IFRS 16 on spreadsheets. The model produced a number. Someone formatted it into a journal template. Someone else posted that journal. At no point did the system confirm that what landed in the GL matches what the calculation engine produced. That is not a process problem you'd notice month to month. Until an auditor asks for the document that confirms it.
The most common failure modes are consistent across organisations of all sizes:
Each of these issues is common. Together, they mean an organisation's AASB 16 position is accurate in the model but uncontrolled in the GL. That is not a compliance position that holds up to audit scrutiny.
An auditor checking AASB 16 and NZ IFRS 16 GL compliance isn't primarily asking "is this number correct?" They're asking "can you show me how you know this number is correct?" Those are two different questions, and only one of them can be answered by pointing at a spreadsheet model.
In practice the audit test runs like this: the auditor picks up the lease liability balance on the balance sheet and asks for the supporting subledger: a document listing every active lease with its closing liability, the whole of which should foot to the GL balance. If there's a difference, they want a documented explanation for every cent. If there's no subledger document at all, the audit pivots to manual reconstruction, and your finance team spends the next several days building the evidence that should have existed all along.
The ROU asset gets the same treatment. The balance on the balance sheet must trace to a subledger showing cost and accumulated depreciation for each lease. Consider what that looks like with real figures: at 31 August 2026, a $335,574 AUD equipment lease sits on the balance sheet as a net ROU asset of $307,609.82 (cost $335,574.35 less $27,964.53 in accumulated depreciation) with a closing lease liability of $309,447.48. That's what the auditor is tracing back through. The question isn't whether those numbers are correct; it's whether you can hand the auditor a document they can trace them from.
Manual reconciliation in spreadsheets across periods is one of the primary causes of close overruns. When the subledger and the GL have been maintained separately, the first time they're compared is often when the auditor asks for it. The gap between what the model shows and what the GL carries is the problem that then has to be explained under audit pressure.
A controlled lease GL process has three characteristics that distinguish it from a spreadsheet-based one: a lease subledger maintained by the same system that produces the journals; an automated reconciliation that confirms the subledger agrees to the GL at the point of posting; and a locked period that prevents retroactive changes without generating an audit trail.
The key difference from a data-export workflow is systemic. In a controlled process, the journal and the reconciliation report are produced by the same calculation engine. There's no separate step where someone reads a figure and types it into a different template. The journal entries flow from the calculation. The reconciliation report confirms those entries were received by the GL correctly. Both artefacts are system-generated, locked, and dated.
Compare the two approaches in practice:
| Data-export workflow | Controlled GL process |
|---|---|
| Calculation lives in the spreadsheet model | Calculation runs in the lease accounting system |
| Journals built manually from model outputs | Journals generated automatically from the same engine |
| Reconciliation built retrospectively if requested | Reconciliation report produced at posting time, locked |
| No system-level control confirming GL agreement | System confirms subledger-to-GL agreement automatically |
| Prior periods editable without constraint | Periods locked; modifications generate an audit trail |
| Auditor evidence requires manual reconstruction | Auditor evidence is the system-generated report, available on demand |
The data-export approach still requires manual control at every step; the controlled process is auditable at the system level. Under AASB 16 and NZ IFRS 16, that's the difference between a clean audit evidence file and a month of reconstruction work.
Software with proper GL integration can produce a locked-down periodic report that agrees the lease subledger to the GL balances automatically, and thus avoiding a detailed reconciliation process.
Most finance teams don't have that. Here is what each word in that description actually means in practice.
"Locked-down" means the report is generated at a specific point in time and cannot be altered retroactively. It records what the subledger showed and what the GL showed at the moment it was run. If a discrepancy existed, the locked report captures it. If the period closes cleanly, the locked report proves it. Neither the subledger figures nor the GL comparison can be changed after the report is generated without producing a new record.
"Agrees the lease subledger to the GL balances" means the report performs the reconciliation rather than presenting raw figures for you to compare manually. It shows: the closing balance of every lease in the subledger, the GL codes those balances correspond to, the GL balance at those codes, and the variance (which, in a controlled process, is zero). If the variance is not zero, the report surfaces the difference explicitly, so it can be investigated at posting time rather than at audit time.
"Automatically" means this report is standard output from the system, produced every period as part of the normal close cycle, not a custom query you run when an auditor asks for it. When the auditor does ask for the GL reconciliation, the answer is: here are 24 locked reports, one per close cycle, all showing zero variance.
That is the control position. It's not exotic; it's what system-level GL integration looks like when it's working correctly, and it's what enterprise ERP modules and mid-market accounting systems can't provide for AASB 16 specifically, because they don't maintain the lease-level calculation engine that the subledger depends on.
Transitioning from a spreadsheet-based GL process to a controlled one doesn't require a full finance systems overhaul. It requires a lease accounting platform with genuine GL integration: one that generates journals from the same calculation engine that maintains the subledger, posts those journals via a mapped GL code structure, and produces a locked reconciliation report each period.
The transition has three practical stages:
Map your GL codes into the lease accounting system
Every journal line the system produces needs a corresponding GL code in your chart of accounts: ROU asset cost, accumulated depreciation, lease liability (current), lease liability (non-current), interest expense, and depreciation charge. Mapping these once, at setup, means every subsequent period's journals carry the right codes without manual intervention. LOIS uses the LOIS system output GL codes (00-005, 05-005, 10-005, etc.) mapped to your actual account structure.
Establish the opening balance reconciliation
Before the first system-generated period closes, confirm that the opening subledger balances in the lease accounting system agree to the balances currently sitting in the GL. This is the baseline reconciliation. It's the point from which every subsequent locked report will be measured, and it's the document that proves the transition from the old process to the new one was clean.
Lock periods and file the reconciliation report each month-end
Once the journals are posted, the period is locked in the lease accounting system and the reconciliation report is filed. From this point, any modification to a prior period generates a new journal entry with a full audit trail, not a change to historical figures. The reconciliation report for each period is the evidence the auditor asks for, and it exists as standard output, not as something built in response to the request.
Organisations running LOIS's autonomous GL integration do this as standard. Every journal traces to its source in the LOIS calculation engine. Every period's reconciliation report is locked and available on demand. Every lease modification carries its own immutable audit trail showing the values before and after. When an auditor asks for the GL reconciliation, there's no reconstruction: there's a folder of locked system-generated reports, one per close cycle, going back as far as the auditor wants to look.
For a broader view of what AASB 16 audit-readiness requires, our AASB 16 and NZ IFRS 16 compliance self-assessment guide covers the full ten-point framework. For detail on the specific reports a lease accounting system should produce each period, see what reports IFRS 16 lease accounting software produces.
What does GL reconciliation mean in the context of AASB 16 and NZ IFRS 16?
GL reconciliation under AASB 16 and NZ IFRS 16 means confirming that the total lease liability and right-of-use asset balances held in the lease subledger agree to the corresponding balances in the general ledger. A clean reconciliation shows that every journal posted from the lease calculation engine was received correctly by the GL, with no unexplained differences. Under audit scrutiny, this reconciliation must exist as a dated, retrievable document, not as something that would need to be rebuilt if requested.
Why can't an enterprise ERP handle AASB 16 GL control on its own?
Enterprise ERP and mid-market accounting systems are built for general ledger management, not for the lease-specific calculation engine that AASB 16 and NZ IFRS 16 require. The ERP holds the GL balances, but it can't generate the amortisation schedules, remeasure the lease liability at modification, process CPI adjustments at the correct payment date, or produce the lease-level subledger that reconciliation depends on. The calculation work still needs to happen somewhere. When that work happens in a spreadsheet, the GL and the subledger become two separate records that can drift apart without any system-level control to catch the gap.
How does LOIS produce a locked-down periodic reconciliation report?
LOIS has a fully autonomous general ledger integration. At each month-end, the LOIS calculation engine generates the journals for every active lease, maps them to the configured GL codes, and produces a locked periodic report confirming that the lease subledger agrees to the GL balances. The report is system-generated, dated, and stored against that period's close cycle. It can't be altered after generation. If a discrepancy exists, it's visible in the report at posting time, not discovered under audit pressure months later. Each journal line is traceable back to its source lease event in the calculation engine.
What happens when a lease is modified? Does the GL reconciliation still hold?
Yes, when modifications are processed through the lease accounting system. When a lease is modified under AASB 16 or NZ IFRS 16, the system recalculates the lease liability and right-of-use asset from the modification date, generates the remeasurement journals, and updates the subledger. The reconciliation report for the period in which the modification falls reflects the updated figures. In a spreadsheet-based process, the same modification requires manual recalculation, manual journal preparation, and manual updating of the subledger: three separate steps where the two records can diverge. LOIS handles this as a single system event, with an immutable audit trail showing the values before and after the modification.
How does GL control relate to the broader AASB 16 audit preparation checklist?
GL reconciliation is one of six areas that Australian and New Zealand auditors focus on when examining AASB 16 and NZ IFRS 16 compliance. The others are lease completeness, modification remeasurements, disclosure quality, CPI adjustment timing, and IBR documentation. A breakdown in GL control can mask problems in any of these other areas, because the GL balance becomes unreliable as a check on the underlying subledger. Our detailed post on the six compliance areas auditors focus on covers how each area interacts and what the audit evidence requirement is for each.
GL control that holds up to audit scrutiny
LOIS's autonomous GL handles the reconciliation automatically, including the locked-down periodic report your auditor will ask for. Talk to the team about how it works for your portfolio.
See LOIS lease accounting Talk to an expert