Discover everything you need to know about AASB 16 and how it impacts your business. Take action today to stay compliant and avoid penalties. Learn more now.
Choosing lease accounting software is a decision most businesses make once and then live with for years, usually without a clear view of what separates one option from another. The products all claim compliance with AASB 16, and compliance with the calculation is the easy part.
What actually differentiates them is how they handle everything after the initial measurement, how they connect to your ledger, and how much work they leave with you.
This article covers what to evaluate, in what order, and how to decide whether you need dedicated software at all.
Not every business needs a dedicated lease application, and buying one you do not need is a real cost.
Lease count is the obvious factor. A handful of straightforward leases is manageable in a spreadsheet by a competent person with good discipline.
Change frequency matters more than count. Ten leases that never change are easier than five that are constantly modified, because modifications are where spreadsheets break.
Entity and currency complexity multiplies everything, since consolidation and translation add layers a workbook handles poorly.
And audit scrutiny is a factor, since businesses with a statutory audit, external investors or lender covenants carry a higher evidentiary standard than those without.
Understanding the requirement properly is what allows you to evaluate a product rather than accept a claim.
At commencement you recognise a right of use asset and a lease liability, both measured at the present value of the lease payments, discounted at the rate implicit in the lease where determinable and the incremental borrowing rate otherwise.
The asset depreciates, typically straight line, over the shorter of the lease term and the useful life.
The liability unwinds using the effective interest method, so each payment splits between interest and principal in a proportion that changes every period.
And a defined set of disclosures is required, including a maturity analysis on an undiscounted basis and a reconciliation of movements in the right of use asset by class.
The initial calculation is trivial and every product does it. Remeasurement is where the real capability sits.
A change in consideration arising from something already in the original terms, such as a CPI escalation or a rent review, is a remeasurement of the liability using the original discount rate where interest rates are not the driver.
A change in the assessment of an option is a remeasurement using a revised rate.
A change that adds a right of use not in the original contract, priced at standalone terms, is a separate lease.
And a change to scope or consideration in any other way is a modification, remeasured at a revised rate, with any decrease in scope also recognising a gain or loss on partial derecognition.
Ask a vendor to demonstrate each of those, with the working visible, rather than accepting that modifications are supported.
The most consequential structural choice is whether the application runs inside your accounting platform or alongside it.
A standalone application maintains the register and the schedules and produces a journal that somebody posts. That means a recurring manual step, a reconciliation between the application and the ledger, and two records that agree because somebody checked.
An application built natively for your platform posts directly. There is no journal to enter and no reconciliation between two systems, because there is one system.
The native option also inherits the platform's dimensional coding, so lease cost by subsidiary, department or location is available in standard reporting rather than requiring an export.
And it inherits the permissions, the audit trail and the approval workflow rather than maintaining a second set. Our piece on NetLease in NetSuite covers what that looks like in practice.
Businesses evaluating lease software focus on the calculation and underestimate the disclosure requirement, which is where a substantial part of the annual effort sits.
The maturity analysis needs to be produced on an undiscounted basis, banded by period, across the whole portfolio.
The movement reconciliation needs to show additions, depreciation, remeasurements and disposals by class of underlying asset.
Interest expense, short term and low value lease expense, and total cash outflow for leases all need to be separately available.
Ask to see the actual disclosure outputs against a realistic dataset, and ideally show them to your auditor before committing, because a product that produces the numbers in a format nobody can use has solved half the problem.
The short term and low value exemptions materially reduce the workload where they apply, and products handle them with varying degrees of usefulness.
The system should support the election by class of underlying asset for short term leases, applied consistently.
It should support the low value election lease by lease, assessed on the value of the asset when new.
And it should keep the exempted leases visible in the register rather than outside it, because you still have to disclose the associated expense and you still need to know the leases exist.
A product that treats exempted leases as out of scope entirely leaves you maintaining a second list, which defeats the purpose.
The discount rate drives measurement more than any other input, and how a product handles it matters.
It should support different rates by lease, since a two year lease and a fifteen year lease should not carry the same rate.
It should record the basis for each rate, because auditors ask how the rate was derived and a documented answer is worth a great deal.
It should apply the correct rate on remeasurement, which for some categories is the original rate and for others a revised one, and getting this wrong is a common error.
And it should let you see the effect of a rate change, since that is a useful commercial question as well as an accounting one.
Getting your current position into the new system is the bulk of the implementation effort, and it is worth understanding before you commit.
Expect to locate every lease agreement, which is harder than it sounds because they sit with property, fleet, operations and finance separately.
Expect to abstract the key terms from each one, meaning commencement, term, options, payments, escalation mechanism and any unusual provisions. This needs somebody who can read a lease and it is the effort intensive step.
Expect to reconcile the opening position to whatever you currently have, which frequently surfaces differences that need explaining.
Ask the vendor what they provide here, what template they need, and how they handle leases already partway through their term.
For groups, a few capabilities matter that a single entity business can ignore.
Leases need to be recorded in the correct entity, and the paying entity is not always the entity using the asset.
Intercompany leases need to eliminate on consolidation rather than being double counted.
Foreign currency leases need correct translation, with the liability treated as monetary and the right of use asset generally not, which is a distinction some products handle poorly.
And discount rates should be settable at entity level, since the relevant incremental borrowing rate is that of the lessee entity rather than of the group.
Lease software is usually evaluated by finance for finance, and the population who benefit from it is wider than that.
Whoever negotiates leases needs the expiry and option calendar, well in advance, because negotiating position depends on lead time more than on anything else.
Operations needs the cost by site alongside whatever operational measure matters, since they are the ones who can change what a site produces.
Auditors need a clean path from a disclosure figure back to an individual lease, and a product that makes that straightforward reduces audit effort every year.
Which means the access model matters. A product that only supports finance users, or that charges per user in a way that discourages wider access, quietly limits the value you get from the data you have paid to assemble.
The same data answers commercial questions, and whether the product makes that easy is worth evaluating.
An expiry and option timeline across the portfolio, which most businesses have never seen and which changes how renewals get negotiated.
Committed cost by year, which is the maturity analysis presented for management rather than for disclosure.
Lease cost by site alongside an operational measure, which is what allows sites to be compared.
And a diary of option decision dates, since an option that lapses because nobody tracked it is a decision made by inattention. Our piece on using lease data strategically covers this in more detail.
The product will be in use for years, so how it is maintained matters as much as what it does today.
Ask how the application is maintained against your platform's release cycle, particularly for natively built applications where the platform changes twice a year.
Ask how accounting standard changes are handled, since standards are amended and interpretations evolve.
Ask what support looks like, who provides it, and in what timezone.
And ask what happens to your data if you stop using the product, because a register you cannot extract is a form of lock in that nobody thinks about at selection.
Demonstrations are designed to look good, and a few specific requests make them informative.
The partial termination request is the most useful, because it is technically the most demanding and the one weaker products handle least convincingly.
Software removes the calculation work and does not remove the need for a process, which is where implementations most often fall short.
Somebody has to know when a lease changes, which means a route from whoever negotiates leases to whoever accounts for them. In most businesses that route does not exist.
Somebody has to review the additions and remeasurements each period, since a system applies the treatment you selected rather than the treatment that is correct.
And the register needs a periodic completeness check against contracts, property records, the fleet list and recurring payments in accounts payable.
The most common lease accounting error is not a miscalculation. It is a lease nobody told finance about, and no software prevents that.
The case rests on three things and only one of them is time saved.
Time saved is measurable. Count the hours currently spent on lease schedules each period and at year end, and be honest about the year end figure.
Error risk is harder to quantify and usually larger, since a material error is a restatement conversation and the probability rises with lease count and change frequency.
Audit efficiency is the third, since auditors testing a controlled system with a reliable trail do less work than auditors testing a spreadsheet, and fees respond over time.
And key person risk sits underneath all three, because a business whose lease accounting depends on one person's workbook has an exposure no amount of care removes.
The decision comes down to whether your lease population justifies dedicated software, and then to how the product handles remeasurement, disclosure and the connection to your ledger.
If your population is small and stable, a spreadsheet with proper controls and documentation is defensible, and the controls and documentation are usually the part that needs work.
If it is more than trivial or it changes frequently, the question is when rather than whether, and the answer is usually before the next audit rather than after it.
Our pieces on the hidden costs of lease accounting errors and implementing lease accounting software cover the surrounding ground, and AASB 16 explained covers the standard.
If you would like help assessing what your lease population needs, get in touch.
