Lease Accounting Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does the build get scoped as a calculator rather than as an event model?

Because the initial measurement is the part everyone can specify. Discount the payments at the right rate, recognise the liability and the right of use asset, amortise both. That is describable in a paragraph, it demonstrates convincingly, and any competent development team will quote against it happily.

The workload is everywhere else. A lease is modified and the term extends. A renewal option becomes reasonably certain of exercise, which changes the term and forces remeasurement at a current discount rate. 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. Under IFRS 16 an index linked rent change triggers a liability remeasurement when the cash flows change, whereas under ASC 842 payments varying with an index are treated differently, so the same contract produces different accounting in each framework and a dual reporting group runs both.

The fix is to specify the events before the calculation. List every event type your portfolio actually experiences, and for each require an approval, an effective date, a before and after, and an explanation. Then ask a developer to explain, without notes, how a partial termination affects the liability and the asset and where the difference lands. If they cannot, they will implement your accounting policy as described by whoever happened to be in the room, and the errors will surface at audit rather than in testing.

What goes wrong when you migrate existing schedules and opening balances?

The requirement is unforgiving and often stated too late: opening balances have to reconcile to your existing schedules line by line, agreed with your auditor before cutover rather than after. Migration is normally the longest single task in the project, longer than the engineering, and it is almost never budgeted that way.

The reasons are specific. Master workbooks are rarely one file. There is a group model and several regional files with different conventions, and the conventions are the problem: whether payments are treated as in advance or in arrears, whether the first period is a stub, how the discount rate was derived and whether the same rate was applied to leases commencing in different years. Where a lease was already remeasured, the current schedule reflects a rebuilt calculation whose original inputs may no longer exist in the file. Then there are the leases that were never in the workbook at all, which is a completeness problem surfacing during migration because someone finally lists every agreement.

The approach that works is to reconcile in stages and write down the conventions before loading anything. Take a sample of leases across each convention family, reproduce their current schedules exactly in the new system, and resolve every difference before bulk loading. Companies with several regional files and inconsistent conventions should budget several extra weeks purely for reconciliation, and should hear that in the estimate rather than in month four.

Why does the ERP (Enterprise Resource Planning) posting integration break after launch?

Because posting a journal is not one integration, it is a mapping that must stay correct as your entity and account structure changes. The failure pattern is consistent: a new legal entity is created, a ledger account is renumbered during a chart of accounts tidy, or a book is added for a statutory requirement, and the mapping posts to a suspense account for a month before anyone reconciles.

The second pattern is period control. The lease system generates a journal for a period the ledger has closed, or a late remeasurement produces an entry dated into a locked period. If the system does not understand your close calendar, someone posts manual corrections, reintroducing the control weakness the project existed to remove.

The third is on the input side. Where lease data originates in an operational system, a fleet platform or a site acquisition system, that feed changes shape when the operational team changes their process, and new leases stop arriving without anything failing.

The fixes are ordinary discipline. Reconcile posted journals back to generated schedules on every close and alert on any difference, rather than assuming a successful post means a correct post. Validate entity, currency, book and account mapping on every run against the current chart of accounts rather than a copy taken at go live. Respect the close calendar explicitly, with an out of period path that is deliberate and recorded.

What happens when completeness and the audit trail are not covered?

Completeness is the exposure that produces restatements. Most companies underestimate their lease population, sometimes badly. Property leases are known because someone in real estate manages them. The rest are scattered: vehicles inside fleet, equipment inside procurement, land agreements inside operations, and the difficult category, leases embedded inside service contracts.

Embedded leases are where it hurts. A logistics agreement dedicating specific trailers to you, a supply contract where the supplier built a line producing only your product, a data centre arrangement giving 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, a judgement your technical accounting team makes contract by contract. What software can do is enforce that every contract above a threshold gets screened, that the conclusion and its reasoning are recorded, and that screening repeats on renewal. Skip that and you discover an embedded lease during an audit.

The audit trail is the other half, and it is the actual deliverable. What gets tested is whether the population is complete, whether inputs agree to the underlying contract, whether judgements were approved by the right people, and whether posted journals match the schedules produced. The design requirement is that every number traces backwards: journal line to schedule, schedule to lease version, lease version to the change event, event to approver and source document, held append only.

Should you build custom or configure what you already own?

Buy, for most companies, and we will say so on a call. If you have a few hundred leases, report under one framework and hold conventional property and equipment agreements, license FinQuery or Visual Lease and stop there. Licensing means the vendor carries the burden of keeping the accounting engine current when a standard is amended, and a build hands you that obligation permanently. Nakisa suits large groups with complex enterprise landscapes and multi book requirements. CoStar Real Estate Manager fits portfolios where real estate administration and accounting must be one system. Visual Lease is stronger where critical dates, clauses and obligations matter as much as the schedules.

Build when at least two of these are true. Your lease data is generated inside an operational system you already own and the integration is unavoidable, in which case owning the calculation is a shorter step than it looks. You report under three or more frameworks in parallel. Your portfolio type sits outside what these products were designed around, such as telecom site leases, energy land agreements, or retail estates with thousands of short leases and constant churn. Or lease accounting is one component of a broader property and obligation platform you are building anyway. Being an occupier with 400 property leases is not a build case.

How do hidden costs get into the quote?

Four places. The number of reporting frameworks is the largest and it is routinely priced as a formatting option. Group reporting, statutory local accounts that may not recognise a right of use asset at all, and a tax treatment following a third path mean one contract with several parallel schedules and several sets of journals to different ledgers. Each framework is a separate measurement path with its own rules.

Enterprise system posting depth is the second, and it should be quoted per target system with the product named. Foreign currency and intercompany elimination is the third, because retranslation and elimination on consolidation are their own logic rather than a currency field.

The fourth is the discount rate. Groups treating the incremental borrowing rate as one number in a cell are producing a figure that will not survive scrutiny. The rate is entity and currency specific and changes over time, so what you need is rate policy, rate tables by entity, currency and tenor, and recorded evidence of how each rate was derived. That is a deliverable, not an input someone remembers, and it rarely appears in an estimate. What keeps the number down is a single framework, one enterprise system, and a clean cutover date agreed with your auditor in advance.

What separates a build that works from one that fails here?

The builds that work recalculate from an event date and preserve everything already reported. That is the design question worth interrogating hardest, because the naive implementation regenerates history from current inputs, quietly restating prior periods every time someone corrects a typo. Ask what happens when a modification is entered with an effective date three months in the past. The answer should involve a new lease version, a recalculation forward from that date, and prior reported figures untouched with the difference recognised in the current period according to your policy.

They also serve the people who are not accountants. Real estate and procurement need critical dates, break options, clauses and obligations from the same lease record, because the moment they keep their own copy you have two versions of the truth. A single record with different views is what keeps completeness working over time.

The builds that fail treat disclosure as reporting bolted on at the end. The maturity analysis, weighted average remaining term and discount rate, cash flow disclosures and expedient tracking all depend on how the underlying data was modelled, and retrofitting them exposes gaps in the model.

Get code ownership in writing before kickoff: 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 ask who controls the code that produces the numbers.