Finance & Accounting Automation

AI for Lease Accounting and ASC 842 Compliance (2026)

ASC 842 brought leases onto the balance sheet, and with them a new ongoing accounting burden most companies underestimated. Lease accounting engines automate the core calculation well — but most errors come from the lease data and the modifications, not the math. Here is how AI automates lease accounting, and where accuracy is actually decided.

Kognitos June 24, 2026 14 min read

AI for lease accounting and ASC 842 compliance in 2026: the right-of-use asset and lease liability model, the split between lease accounting engines (LeaseQuery, Visual Lease, Nakisa) and the lease-data-and-event layer that feeds them where most errors originate (Kognitos), and lease modifications as the hardest area. By Kognitos.

TL;DR

Lease accounting under ASC 842 (and IFRS 16 internationally) requires companies to recognize most leases on the balance sheet as a right-of-use (ROU) asset and a corresponding lease liability, then account for them over the lease term — through modifications, reassessments, renewals, and terminations. It is complex and ongoing, not a one-time setup, which is why specialized lease accounting software exists.

Lease accounting engines (LeaseQuery/FinQuery, Visual Lease, Nakisa, LeaseAccelerator, NetSuite Lease Accounting, SAP, Trullion, and others) automate the ASC 842 mechanics: classifying leases, measuring ROU assets and lease liabilities, generating amortization schedules and journal entries, and producing disclosures. AI has made these engines better, especially at lease abstraction — extracting lease terms from contract documents — and at modification handling.

The critical insight is that most lease accounting errors originate upstream, in the lease data and the events, not in the ASC 842 calculation. The engine calculates correctly on the data it has; if the lease population is incomplete, the data is scattered and outdated, or modifications and reassessments are not captured and processed correctly, the accounting is wrong regardless of how good the engine is. Modifications, reassessments, renewals, and terminations are the most error-prone area, because each is an event that changes the ROU asset and liability and must be captured, evaluated, and recalculated every reporting period.

This creates a two-layer view: the lease accounting engine owns the ASC 842 calculation and compliance; the lease-data-and-event layer beneath it assembles, reconciles, and maintains the complete, current lease data the engine depends on, and ensures modifications and events are captured and fed through — which is where errors originate and where much of the ongoing work concentrates. An agentic platform like Kognitos operates in that data layer: it is not a lease accounting engine, it is the layer that keeps the lease data complete, current, and reconciled across systems and feeds lease events into the engine, with an audit trail.

This post covers the ASC 842 model, how AI automates lease accounting, why errors originate upstream, the two-layer view, and how to think about the stack. For related technical-accounting corners, see AI for Revenue Recognition and ASC 606 Automation and AI for Corporate Tax and Provision Automation.

ASC 842 and what makes lease accounting hard

ASC 842 (Leases) is the US accounting standard, effective for public companies from 2019 and private companies from 2022, that brought most leases onto the balance sheet, with IFRS 16 as the international counterpart. Before it, operating leases were largely off-balance-sheet; under ASC 842, a lessee recognizes for most leases a right-of-use (ROU) asset (the right to use the leased item) and a lease liability (the obligation to make lease payments), then accounts for both over the lease term.

The mechanics, at a high level: identify the lease (including embedded leases hidden inside service or supply contracts), classify it (operating or finance), measure the initial ROU asset and lease liability (the present value of lease payments, using the appropriate discount rate), and then account for it over time — amortizing the asset, accreting and paying down the liability, and recognizing the expense — while generating the required disclosures.

What makes this hard — and harder than companies expected (around 58% of public companies found the implementation more complex than anticipated) — is not the one-time setup but the ongoing accounting, especially the events. Leases change constantly: they are modified (terms renegotiated), reassessed (when assumptions change), renewed, extended, terminated early, or partially impaired. Each of these events changes the ROU asset and the lease liability and requires recalculation, often with specific accounting treatment depending on the event type. A lease portfolio is not static; it is a living set of contracts generating accounting events every period, and keeping the accounting correct through all of them — across potentially thousands of leases spanning real estate, equipment, vehicles, and embedded leases — is the real ongoing challenge. This is why lease accounting is heavily software-automated, and why the data and the events, not the core calculation, are where the difficulty concentrates.

How AI automates lease accounting

Lease accounting engines automate the ASC 842 mechanics, and AI has made them better at the hardest parts. The capabilities AI brings:

Lease abstraction: AI reads lease contracts (often long, unstructured documents) and extracts the terms relevant to accounting — payment amounts and schedules, commencement and end dates, renewal and termination options, discount-rate inputs — automating what was painstaking manual contract review. AI-driven abstraction is one of the most valuable applications, because manually extracting terms from thousands of leases is enormously labor-intensive and error-prone, and the leading engines now include AI abstraction agents.
Classification and measurement: The engine classifies leases (operating vs finance) and measures the initial ROU asset and lease liability, applying the present-value calculations and the appropriate discount rates, automating the core ASC 842 math.
Amortization and journal entries: The engine generates the amortization schedules and the recurring journal entries over the lease term, automating the period-by-period accounting that would otherwise be manual spreadsheet work.
Modification and event handling: AI helps process the lease events — modifications, reassessments, renewals, terminations — applying the correct accounting treatment and recalculating the ROU asset and liability, which is the most error-prone area.
Disclosure generation: The engine produces the ASC 842 disclosures (maturity analyses, weighted-average lease term and discount rate, ROU asset and liability rollforwards) from the lease data, automating disclosure preparation.

The reported benefits are real: automating lease abstraction, calculation, and disclosure dramatically reduces the manual effort and the close-cycle time lease accounting consumes, and AI abstraction in particular cuts the labor of getting leases into the system. But as with tax and revenue recognition, the benefits depend on something upstream of the engine.

Why most lease accounting errors originate upstream

Here is the insight that should shape how a finance team thinks about lease accounting automation: most lease accounting errors do not originate in the ASC 842 calculation — they originate upstream, in the lease data and the events feeding the engine.

The lease accounting engine calculates correctly on the data it has. Its ASC 842 math is reliable. But the accounting is only as correct as the inputs: the completeness of the lease population, the accuracy and currency of the lease data, and the capture and correct treatment of lease events. Errors concentrate in three upstream places.

The lease population is incomplete. Leases get missed, especially embedded leases buried inside service, supply, or IT contracts that are not obviously “leases,” and leases scattered across departments and regions that never make it into the system. A lease that is not in the engine is not accounted for, which is a completeness error the engine cannot catch because it does not know the lease exists.

The lease data is scattered and outdated. Lease data lives across systems and documents — the contracts themselves, the ERP, real estate systems, spreadsheets — and across regions and entities, and it goes stale as terms change. When the data feeding the engine is fragmented, incomplete, or outdated, the accounting built on it is wrong, and assembling complete, current lease data from these scattered sources is a major ongoing burden.

Modifications and events are not captured or processed correctly. This is the sharpest error source. Lease modifications, reassessments, renewals, and terminations each change the ROU asset and liability and require specific treatment and recalculation, and they happen continuously. If a modification is missed, captured late, or treated incorrectly — the wrong event type, the wrong remeasurement — the accounting goes wrong and stays wrong until caught, often surfacing in an audit or a restatement. Because events are frequent and each requires judgment and accurate data, they are where ongoing lease accounting most often breaks.

The common thread is that these are data-and-event problems upstream of the engine, not calculation problems. A finance team that implements a capable lease accounting engine but does not solve the completeness of the lease population, the currency and consistency of the lease data, and the reliable capture and processing of events has automated the calculation while leaving the actual sources of error unaddressed.

The two layers of lease accounting automation

This produces a two-layer view of lease accounting automation — parallel to the pattern across technical accounting — and clarifying where the work and the risk sit.

The lease accounting engine

Platforms like LeaseQuery/FinQuery, Visual Lease, Nakisa, LeaseAccelerator, NetSuite Lease Accounting, SAP Lease Administration, and Trullion are the engines: they classify leases, measure ROU assets and lease liabilities, generate amortization schedules and journal entries, process the accounting for events, and produce ASC 842 and IFRS 16 disclosures. These are mature, capable platforms, increasingly with AI abstraction built in, and they are the right tools for the lease accounting calculation and compliance. For the engine layer, companies choose among them based on portfolio size and type (real estate, equipment, fleet), multi-standard needs (ASC 842 plus IFRS 16), and ERP environment.

The lease-data-and-event layer

Beneath the engine sits the layer that keeps the lease data complete, current, and consistent, and that captures and feeds events into the engine: ensuring the full lease population is identified (including embedded leases), assembling and reconciling lease data across the systems and documents it lives in, keeping it current as terms change, and capturing modifications, reassessments, renewals, and terminations and routing them into the engine for recalculation. This is where lease accounting errors originate, where the audit-sensitive completeness and event treatment are grounded, and where much of the ongoing lease accounting effort actually goes.

Why the split matters

The split matters because lease accounting accuracy is decided substantially at the data-and-event layer, not only at the engine. A capable engine fed an incomplete lease population, scattered or outdated data, or uncaptured modifications produces incorrect accounting — and the restatements that follow — regardless of how good the engine is. Most of the lease accounting pain and audit risk, especially around completeness and event handling, is in maintaining the data and processing the events, which is upstream of the engine’s calculation. The strongest lease accounting operations treat the data-and-event layer as seriously as the engine, because that is where the errors they are trying to prevent actually originate.

A note on the engines moving into this layer: the leading lease engines increasingly include AI lease abstraction (extracting terms from contracts), which addresses part of the data problem — getting lease terms into the system. This is genuine progress. But abstraction is the entry of lease data; the ongoing challenge is keeping the full population complete, the data current and reconciled across systems, and the events captured and processed over the life of the portfolio, which is broader than initial abstraction and is where the cross-system data and event work continues to live.

Where agentic AI fits in lease accounting

Within that split, agentic AI like Kognitos fits at the lease-data-and-event layer, and this is the honest scope. Kognitos is not a lease accounting engine. It does not perform the ASC 842 classification and measurement, generate amortization schedules, or produce the lease accounting treatment and disclosures, and it does not replace LeaseQuery/FinQuery, Visual Lease, Nakisa, or the other lease engines. Those are the right tools for the lease accounting calculation and compliance.

Where Kognitos is relevant is the cross-system lease-data assembly, reconciliation, and event handling that feeds the lease accounting engine — the layer where errors originate. As a deterministic, agentic platform, it can assemble lease data from the systems and sources it lives in, reconcile it so it is consistent and current across those systems, help ensure the lease population is complete by surfacing lease data from across the organization, and reason about the events — capturing modifications, reassessments, renewals, and terminations and routing them with the right information into the engine for recalculation. Because it executes deterministically with every step logged, the data and event handling is auditable, which matters directly for the audit-sensitive completeness and event treatment ASC 842 requires.

The honest distinction from the engines’ own AI abstraction: the engines increasingly extract lease terms from contracts at entry, which is valuable. Kognitos’s relevance is the broader, ongoing cross-system data and event work — keeping the data complete and reconciled across the systems it lives in over the life of the portfolio, and reliably capturing and feeding the continuous stream of events — which is the part that persists after initial abstraction and is where ongoing errors arise. In other words, Kognitos addresses the upstream lease-data-quality and event-capture problem that is where most lease accounting errors originate, while the engine does the ASC 842 calculation — similar to the data layer beneath the engine rather than the engine itself. For a finance team whose lease accounting errors trace to incomplete or scattered lease data and missed or mishandled modifications rather than to the calculation, that data-and-event layer is where the risk and the manual effort concentrate. The point is not to add another lease tool; it is that lease accounting accuracy depends on the data and events feeding the engine, and that layer is where it is won or lost. This is the same data-quality wedge that runs through finance, applied to lease accounting. See AI Audit Trail Requirements: A 2026 Checklist for Finance, Healthcare, and Banking for how auditability connects to this work.

Book a working session with a Kognitos solutions engineer • Try Kognitos free

How to think about the lease accounting stack

For a finance or accounting leader building the lease accounting stack in 2026, a few principles follow.

Choose the lease engine for the calculation and compliance. For the ASC 842 classification, measurement, amortization, journal entries, and disclosures, a dedicated lease accounting engine (LeaseQuery/FinQuery, Visual Lease, Nakisa, or your ERP’s lease module) is the right layer, selected for fit with your portfolio size and type, multi-standard needs, and ERP environment. This is not where to economize — the lease accounting calculation needs a real engine.

Invest in the data-and-event layer, because that is where errors originate. The most common lease accounting mistake is implementing the engine while leaving the lease-population completeness, the cross-system data currency, and the event capture manual and unreliable — when that is where the restatements actually come from. Treat the data-and-event layer as a first-class part of the stack.

Pay special attention to completeness and events. Ensuring the full lease population is captured (including embedded leases) and that modifications, reassessments, renewals, and terminations are reliably captured and correctly processed are the two highest-risk areas. Errors here — a missed lease, a mishandled modification — are exactly what surface in audits and restatements.

Demand auditability throughout. Because lease balances feed the balance sheet and the completeness and event treatment are audit-sensitive, the lease-data preparation and the event handling must be reconstructable and defensible. Weight auditability in both the engine and the data layer.

The throughline: lease accounting AI succeeds or fails substantially on the lease data and events feeding the engine. The engines are capable at the ASC 842 calculation, but they account for the leases and events the organization captures and feeds them, and that capture — plus keeping the data complete and current across systems — is where the errors and audit risk concentrate. Building the stack around that reality — a strong engine plus a strong data-and-event layer feeding it — is what makes lease accounting automation actually reduce errors and restatements.

Last updated: June 2026. Information reflects publicly available sources as of mid-2026, including lease accounting software analysis and ASC 842 / IFRS 16 guidance. Statistics are as reported by their sources and should be validated. Specific platform capabilities should be confirmed with vendors. This article is informational and does not constitute accounting, audit, or legal advice; consult a qualified accounting professional for ASC 842 guidance specific to your situation.

Frequently asked questions

How is AI used in lease accounting?

AI is used in lease accounting to automate the ASC 842 (and IFRS 16) mechanics and, increasingly, the hardest parts. The most valuable AI application is lease abstraction, reading lease contracts (often long, unstructured documents) and extracting the accounting-relevant terms like payment amounts and schedules, commencement and end dates, and renewal and termination options, automating what was painstaking manual contract review. Lease accounting engines also use AI and automation to classify leases (operating vs finance), measure right-of-use assets and lease liabilities, generate amortization schedules and recurring journal entries, process lease events (modifications, reassessments, renewals, terminations), and produce ASC 842 disclosures. Beyond the engine’s calculation, AI is increasingly important for the upstream work: assembling and reconciling lease data across the systems and documents it lives in, ensuring the lease population is complete, and capturing and processing the continuous stream of lease events, which is where most lease accounting errors originate. The benefits — reduced manual effort and faster close — are real, but they depend heavily on the completeness and currency of the lease data feeding the engine.

What is ASC 842 and why is it complex?

ASC 842 is the US accounting standard for leases, effective for public companies from 2019 and private companies from 2022, that requires lessees to recognize most leases on the balance sheet as a right-of-use (ROU) asset and a corresponding lease liability, where previously operating leases were largely off-balance-sheet. IFRS 16 is the international counterpart. It is complex for several reasons. The initial implementation required identifying and measuring the entire lease population, including embedded leases hidden inside service and supply contracts, which around 58% of public companies found more complex than anticipated. But the ongoing accounting is the larger challenge: leases change constantly through modifications, reassessments, renewals, and terminations, and each event changes the ROU asset and lease liability and requires specific accounting treatment and recalculation, every reporting period. Managing this across potentially thousands of leases spanning real estate, equipment, vehicles, and embedded leases, while keeping the accounting correct through all the events, is the real ongoing complexity. This is why lease accounting is heavily software-automated and why the data and events, rather than the core calculation, are where the difficulty concentrates.

Why do lease accounting errors happen even with good software?

Because most lease accounting errors originate upstream in the lease data and events, not in the ASC 842 calculation that the software performs. A lease accounting engine calculates correctly on the data it has, but the accounting is only as accurate as the inputs: the completeness of the lease population, the currency and consistency of the lease data, and the capture and correct treatment of lease events. Errors concentrate in three upstream places. First, the lease population is incomplete — leases get missed, especially embedded leases buried in service or supply contracts, and a lease not in the system is not accounted for. Second, the lease data is scattered across systems and documents and goes outdated as terms change, so the engine calculates on fragmented or stale data. Third, and most commonly, modifications and events are missed, captured late, or processed incorrectly, and since each event changes the ROU asset and liability, getting them wrong propagates errors forward until caught. So a company can have excellent lease accounting software and still experience errors and restatements, because the root cause is the upstream lease-data completeness and event handling — which is why investing in the data-and-event layer feeding the engine matters as much as the engine itself.

Does Kognitos do lease accounting or ASC 842 calculations?

No. Kognitos is not a lease accounting engine and does not perform the ASC 842 classification and measurement, generate amortization schedules, or produce the lease accounting treatment and disclosures, and it does not replace engines like LeaseQuery/FinQuery, Visual Lease, Nakisa, or LeaseAccelerator, which are the right tools for the lease accounting calculation. Where Kognitos fits is the lease-data-and-event layer feeding the engine: as a deterministic, agentic platform, it assembles lease data from the systems and documents it lives in, reconciles it for consistency and currency across systems, helps ensure the lease population is complete by surfacing lease data from across the organization, and reasons about lease events — capturing modifications, reassessments, renewals, and terminations and routing them into the engine for recalculation — all with an audit trail. This addresses the upstream lease-data quality and event-capture problem where most lease accounting errors originate, and where the audit-sensitive completeness and event treatment are grounded. Kognitos works alongside the lease accounting engine, feeding it complete, current, reconciled lease data and reliable event information, rather than replacing it.

What is the hardest part of ASC 842 compliance?

The hardest part of ongoing ASC 842 compliance is handling lease events — modifications, reassessments, renewals, and terminations — and keeping the lease population complete and the data current. Each lease event changes the right-of-use asset and the lease liability and requires specific accounting treatment and recalculation, and these events happen continuously across a lease portfolio, so maintaining correct accounting through all of them is a persistent challenge. Modifications are particularly error-prone because they must be evaluated for the correct treatment (for example, whether a modification is accounted for as a separate new lease or as a remeasurement of the existing one) and recalculated accurately. Alongside events, completeness is a major difficulty: identifying the entire lease population, including embedded leases hidden in service, supply, or IT contracts, is hard, and a missed lease is a completeness error that goes unaccounted for. Both of these — events and completeness — are upstream data-and-event problems rather than core calculation problems, which is why the ongoing accuracy of lease accounting depends heavily on the lease-data-and-event layer feeding the accounting engine, not just on the engine’s calculation.

What is the difference between a lease accounting engine and the data layer feeding it?

A lease accounting engine performs the ASC 842 calculation: it classifies leases (operating vs finance), measures right-of-use assets and lease liabilities, generates amortization schedules and journal entries, processes the accounting for lease events, and produces the required disclosures. LeaseQuery/FinQuery, Visual Lease, Nakisa, and LeaseAccelerator are engines. The data layer feeding the engine keeps the lease data complete, current, and consistent and captures the events the engine needs: ensuring the full lease population is identified (including embedded leases), assembling and reconciling lease data across the systems and documents it lives in, keeping it current as terms change, and capturing modifications, reassessments, renewals, and terminations to feed into the engine for recalculation. The distinction matters because lease accounting accuracy is decided substantially at the data-and-event layer, since most errors originate in incomplete lease populations, scattered or outdated data, and mishandled events rather than in the calculation. A capable engine fed incomplete or inaccurate lease data, or missing events, produces incorrect accounting, so the data layer is where many errors are actually prevented, and treating it as seriously as the engine is what reduces restatements.

How does AI help with lease abstraction?

Lease abstraction is the process of extracting accounting-relevant terms from lease contracts, which are often long, complex, unstructured documents, and AI helps significantly by reading the contracts and automatically extracting the key data: payment amounts and schedules, commencement and end dates, renewal and termination options, discount-rate-relevant terms, and other clauses affecting the accounting. This automates what was traditionally a painstaking, manual, error-prone process of reading each lease and keying the terms into the system, which was especially burdensome during the initial ASC 842 transition when companies had to abstract their entire lease populations. The leading lease accounting engines now include AI abstraction agents that handle this extraction. AI abstraction is valuable because it speeds getting leases into the system accurately and reduces the manual labor and errors of contract review. It is worth noting, though, that abstraction is the entry of lease data into the system; the ongoing challenge of keeping the full lease population complete, the data current and reconciled across systems, and the continuous stream of lease events captured and processed extends beyond initial abstraction — and is where ongoing lease accounting errors most often arise.

Should companies use a dedicated lease accounting tool or their ERP module?

It depends on lease portfolio complexity and existing systems. Companies with large, complex lease portfolios spanning multiple asset types (real estate, equipment, fleet), multiple entities and regions, and multi-standard requirements (ASC 842 plus IFRS 16 and local GAAP) often need a dedicated lease accounting engine (LeaseQuery/FinQuery, Visual Lease, Nakisa, LeaseAccelerator) built for that complexity and scale. Companies already on an ERP like NetSuite or SAP may find the native lease accounting module sufficient if their portfolio is less complex, avoiding a separate system, and these modules have matured. The decision turns on portfolio size and complexity, the asset types involved, multi-standard needs, and ERP integration requirements. Regardless of which engine is chosen, the completeness of the lease population, the currency and consistency of the lease data across systems, and the reliable capture and processing of lease events determine accuracy, so companies should also plan how they will maintain the lease data and handle events — which is where errors originate independent of the engine choice and which matters as much as the engine selection itself.

Kognitos