ASC 842 and IFRS 16 Lease Accounting Software: Why Your Right of Use Schedules Get Flagged Every Single Year

Why lease accounting quietly became a controls problem

Before the current standards, an operating lease was a footnote and a rent expense line, and a spreadsheet was a perfectly reasonable place to keep the schedule. ASC 842 and IFRS 16 moved lease obligations onto the balance sheet, which changed the character of the work entirely. The number is now material, it is derived from judgement, it moves every time a lease is modified, and it sits inside the financial statements your auditor tests.

The pattern we see in occupiers with large footprints is consistent. There is a master workbook, usually built by a technical accounting manager who has since been promoted or left. It has a tab per lease or a tab per region. Formulas reference other tabs. Someone adds a lease by copying the previous tab and editing the inputs, and once a year somebody copies a tab and forgets to update the discount rate cell. The auditor issues the same management letter point about spreadsheet controls, the company acknowledges it, and nothing changes because rebuilding the workbook mid year is worse than living with it.

None of that is incompetence. It is what happens when a calculation that needs version control, approval and an audit trail lives in a tool that has none of those things. The question worth answering is not whether to get off the spreadsheet, it is whether the thing you move to should be licensed or built.

Problem one: the lease population is a discovery exercise, not a list

Most companies underestimate their lease population, sometimes badly. The property leases are known because someone in real estate manages them. The rest are scattered: vehicle and forklift leases inside fleet, IT equipment inside procurement, land and easement agreements inside operations, and the difficult category, embedded leases sitting inside service contracts.

Embedded leases are the ones that cause restatements. A logistics agreement that dedicates specific trailers to you, a manufacturing supply contract where the supplier built a line that only produces your product, a data centre arrangement that gives you a defined cage rather than capacity. Whether those contain a lease depends on whether there is an identified asset and whether you control its use, which is a judgement your technical accounting team makes, contract by contract. The software job is not to make that judgement. It is to make sure every contract above a threshold gets screened, that the conclusion and its reasoning are recorded against the contract, and that the screening is repeated when contracts renew. Companies that skip this end up discovering an embedded lease during an audit, which is the most expensive time to find one.

Problem two: remeasurement is where spreadsheets actually die

The initial calculation is not hard. Present value the payments at the right discount rate, book the liability, book the right of use asset, amortise. A competent accountant builds that in a morning.

The difficulty is everything that happens afterwards. A lease is modified and the term extends. A renewal option becomes reasonably certain of exercise, which changes the term and forces a remeasurement at a current discount rate. A rent review lands. Space is partially surrendered, so the liability and the asset both reduce, and the difference goes through profit or loss. An impairment indicator appears on a right of use asset in a location you are exiting. A sublease starts and the head lease continues. Under IFRS 16 an index linked rent change triggers a remeasurement of the liability when the cash flows change, whereas under ASC 842 payments varying with an index are handled differently and do not by themselves force a remeasurement, so the same contract produces different accounting in each framework. Groups reporting under both have to run both.

Each of those events is a schedule rebuild with a before and after, and each one has to be evidenced. In a workbook, the evidence is a copy of the file with a date in the name. That is precisely the control weakness auditors keep flagging, and it is also how a modification gets applied to the wrong lease.

Problem three: one lease, several ledgers

A multinational group rarely has one answer per lease. The group reports under one framework, statutory entities report under local GAAP that may not recognise a right of use asset at all, and tax often follows a third treatment. That means one contract, several parallel schedules, several sets of journals, each posting to a different ledger or book, with intercompany leases eliminated on consolidation and foreign currency leases retranslated.

The incremental borrowing rate is entity specific and currency specific, and it changes over time, so the rate applied depends on when the lease commenced or was remeasured and which entity holds it. Groups that treat the discount rate as one number in a cell are producing a figure that will not survive scrutiny. Rate policy, rate tables by entity, currency and tenor, and evidence of how each rate was derived are part of the deliverable, not an input somebody remembers.

Problem four: the audit trail is the actual deliverable

The schedules are worth less than the ability to explain them. What the auditor tests is whether the population is complete, whether inputs agree to the underlying contract, whether judgements were made and approved by the right people, and whether the journals posted match the schedules produced.

So the design requirement is that every number can be traced backwards: from a journal line to a schedule, from a schedule to a lease version, from a lease version to the change event that created it, from that event to the approver and the source document. That chain, append only so that history cannot be quietly rewritten, is what turns lease accounting from an annual argument into a routine close task. It is also the thing a spreadsheet fundamentally cannot provide, no matter how well built.

Where FinQuery, Visual Lease, Nakisa and CoStar Real Estate Manager stop

These products are good and we say so plainly. FinQuery is strong on the accounting engine and is a sensible default for a mid market occupier. Visual Lease is strong where lease administration matters as much as accounting, meaning critical dates, clauses and obligations. Nakisa suits large groups with complex ERP (Enterprise Resource Planning) landscapes and multi book requirements. CoStar Real Estate Manager fits portfolios where real estate management and accounting need to be the same system.

The limits show up in specific situations. Very large or unusual portfolios, such as telecom site leases, energy land agreements, or retail estates with thousands of short leases and constant churn, can hit performance and modelling edges. Groups needing several local GAAP treatments in parallel often find one or two frameworks supported well and the rest handled by adjustment. Companies whose lease data originates in an operational system, for example a fleet management platform or a site acquisition system, end up building and maintaining an integration anyway, and once you own that integration the argument for owning the calculation gets stronger. And organisations with a genuinely bespoke close process sometimes find that the product's workflow fights their controls rather than supporting them. Those are the build cases. Being an occupier with 400 property leases is not.

What a custom lease accounting build must include

The lease register first, with a versioned contract record: commencement, term, options and the assessment of whether they are reasonably certain, payment schedule including fixed, variable, index linked and in substance fixed components, incentives, initial direct costs, restoration obligations and the linked source documents.

Then classification and measurement per framework, with rate tables by entity, currency and tenor, and a recorded derivation for each rate. Then the schedule engine producing liability amortisation and right of use asset amortisation with the ability to recalculate from any event date without destroying prior periods. Then the event model, because modification, reassessment, partial termination, impairment, sublease and index change are the real workload and each one needs an approval and an effect that is explainable.

Then journal generation with mapped accounts per entity and ledger, posted into your ERP rather than exported to a workbook. Then the disclosure pack: maturity analysis, weighted average remaining term and discount rate, cash flow disclosures and short term and low value expedient tracking. Then the screening workflow for embedded leases, tied to your contract repository, so the population stays complete over time. Finally reporting for the people who are not accountants, since real estate and procurement need critical dates and obligations from the same record rather than a second copy of the truth.

What it costs and how long it takes

A first release covering the lease register, classification, schedules and journal output for one framework runs $70,000 to $150,000 and ships in 12 to 18 weeks. A full platform adding the event and remeasurement model, multi framework and multi ledger output, embedded lease screening and full disclosure reporting runs $180,000 to $450,000 over 6 to 12 months.

What drives price: the number of reporting frameworks, since each is a separate measurement path with its own rules rather than a formatting option. ERP posting depth, because writing journals into SAP or Oracle with correct entity, currency and book handling is real integration work. Foreign currency and intercompany elimination. Migration of existing schedules, which must reconcile to the prior period balance to the cent, and that reconciliation is often the longest task in the project. What keeps price down is a single framework, one ERP and a clean cut over date agreed with your auditor in advance.

Our honest position on build versus buy

Buy if you have a few hundred leases, report under one framework, and your leases are conventional property and equipment. The products in this category are mature, the accounting maintenance burden sits with the vendor when a standard is amended, and a build gives you an ongoing obligation to keep a technical accounting engine current. That is a real cost and most finance teams should not take it on.

Build when at least two of these are true: your lease data is generated by an operational system you already own and the integration is unavoidable, you report under three or more frameworks in parallel, your portfolio type is not what these products were designed around, your volume or churn breaks the product's model, or lease accounting is one component of a broader property and obligation platform you are building anyway. If none of those apply, we will tell you to license something, and we have told clients exactly that.

How to choose a developer for lease accounting software

Ask them to explain, without notes, how a partial termination affects the liability and the right of use asset and where the difference lands. If they cannot, they will implement your accounting policy as described by whoever was in the room, and errors will surface at audit rather than in testing. This category punishes developers without domain depth more than most.

Ask how recalculation works. The correct design recalculates from an event date and preserves everything already reported, rather than regenerating history. Ask to see how a locked prior period is protected.

Ask how they will prove the migration. The answer should be a reconciliation of opening balances to your existing schedules line by line, agreed with your auditor before cut over, not a bulk import and a hope.

Ask what they have posted into. Journal creation in SAP, Oracle, NetSuite and Dynamics are four different integrations with four different failure modes. Ask which they have done and what broke.

Get code ownership in writing before kickoff. You should own the repository, the infrastructure and the right to move to another firm at will. At Digital Heroes the client owns it from the first commit. For a system inside your financial reporting boundary this is not negotiable, because your auditor will eventually ask who controls the code that produces the numbers.