DEV Community: Adam Benn

Why ROU Asset Depreciation Checks Fail When Schedule And Journal Logic Drift

Adam Benn — Sun, 31 May 2026 23:38:25 +0000

The depreciation problem usually gets reported as a journal problem.

Someone sees a depreciation expense that looks off. The export no longer ties cleanly. The journal layer gets blamed first. In practice, the bug is usually upstream by the time anyone opens the journal tab.

Most IFRS 16 depreciation failures are drift failures. The schedule still looks plausible. The closing ROU asset is still in the right ballpark. What broke was one of the connections underneath it:

the liability was remeasured and the ROU asset changed, but the depreciation profile stayed on the old run
the period boundaries changed, but the model still spread depreciation as though every future slice were identical
the schedule and the journals were no longer sourcing the same values
someone edited history and the downstream outputs stopped agreeing

If you want a quick live reference point, start with the IFRS 16 calculator. The supported workflow exposes the ROU schedule and journal outputs separately, which makes this class of drift easier to spot.

The formula is rarely the real failure

At a whiteboard, ROU depreciation looks uncomplicated.

The asset is recognised at commencement. Then it is depreciated through time. In the common straight-line case, the carrying amount is spread across the remaining depreciation horizon.

That description is true, but it skips the parts that usually fail in code.

The implementation problem is not "can we divide by the number of periods?" It is "what exactly is the carrying amount at this boundary, what periods are still left, and what event has already changed the asset before we calculate the next charge?"

That is why the public IFRS 16 calculation guide separates the ROU asset side from the liability side. The lease liability unwinds through interest and payment logic. The ROU asset follows carrying amount and depreciation logic. They interact at remeasurement events, but they are not the same pipeline.

If a model treats depreciation as a leftover of the liability schedule, drift becomes likely.

Drift path 1: the liability changes but depreciation stays on the old profile

This is the classic failure mode.

The lease is remeasured. Future payments change. The liability is rebuilt correctly. The ROU asset is adjusted. Then the depreciation logic keeps running on the original schedule.

From a technical point of view, that means the model applied the event to the asset balance but did not reset the future depreciation horizon from the event date.

That is not a cosmetic issue. It produces the wrong carrying amount in every later period.

The supported site wording is clear on the intended behavior: when CPI, modification, or reassessment events are applied in the supported workflow, the ROU asset is adjusted and depreciation is recalculated prospectively over the remaining periods.

The word that matters is prospectively.

You do not rewrite historical depreciation rows. You do not run a catch-up patch across prior months. You take the revised carrying amount at the event boundary and recompute the forward depreciation profile from there.

If a model misses that reset, the schedule and journals can both keep looking tidy for a while. They just stop being right.

Drift path 2: the model flattens periods that are not actually flat

Another common mistake is assuming straight-line means identical future rows regardless of period geometry.

That is only safe when the future slices are actually uniform.

The current calculator implementation is more careful than that. It builds remaining period weights first, then applies the current opening ROU balance across those remaining weighted periods. In other words, it does not blindly assume every future slice has the same size. It allocates the current balance across the remaining period fractions.

That matters because a schedule with irregular edges, partial periods, or event-driven resets can still be straight-line in concept while needing an explicit weighting rule in implementation.

If one layer assumes simple equal periods and another layer uses actual remaining period fractions, your depreciation checks will drift even though both developers believe they built straight-line logic.

This is one of the reasons a technical team should document the depreciation rule more precisely than "ROU divided by remaining months."

Drift path 3: the schedule and journals stop sharing one source

This is where a lot of review pain begins.

The schedule might be right. The journal might be right. But if they are not generated from the same canonical values, tie-out becomes fragile.

The export layer in this repo makes the control expectation explicit. It normalizes checks into named laws such as:

Commencement law for the opening ROU asset
ROU law for schedule movement versus journals
Depreciation law for schedule depreciation versus journal depreciation

The plain-English rule for the depreciation law is blunt: compare schedule depreciation to journal depreciation, and pass only when the canonical cent values match exactly.

That is the correct posture.

If one output uses rounded values, another uses a different source column, and a third uses a manual adjustment path, you do not have one depreciation result. You have three approximations of it.

Drift path 4: history gets reopened

Some depreciation bugs are not event bugs. They are edit bugs.

Someone changes an old opening balance. Someone patches an accumulated depreciation figure directly. Someone inserts a manual correction row but does not propagate the same change through the journals.

That kind of change can make a file look repaired while actually making it less reviewable.

A depreciation schedule should behave like a forward chain. Once a boundary is passed, later values should follow from preserved history plus explicit new events. If a model allows quiet edits to old rows, the later schedule may still total correctly while the review trail is gone.

That is why deterministic outputs matter. The useful question is not whether the latest closing balance looks plausible. It is whether you can still explain every period jump from preserved inputs, visible event rules, and the related journal entries.

The minimum checks a model needs

If you are building or reviewing an IFRS 16 depreciation flow, the minimum validation layer should do more than check that depreciation is non-negative.

I would want at least these checks:

1. Opening ROU - depreciation = closing ROU for each period unless a visible period-boundary adjustment is applied first.
2. If a CPI, modification, or reassessment delta hits the period, the opening ROU for that period includes the delta before depreciation is computed.
3. Total schedule depreciation = total depreciation journal debits.
4. ROU movement in the schedule = ROU and accumulated-depreciation journal movement.
5. If opening ROU is driven to zero or below, future depreciation is zero and the asset does not go negative.

Those checks are not academic. They are what stop a schedule from drifting quietly after a valid event.

The audit side of the site says the same thing in reviewer language: verify the initial ROU amount, trace depreciation through the period, confirm supported changes adjusted the asset and reset depreciation over the remaining term, then agree journals to schedules.

That is just a human-readable version of the same control problem.

A fast debug sequence when the depreciation check fails

When a depreciation tie-out fails, avoid debugging from the journal first. Start higher up.

Use this order:

Confirm the opening ROU balance for the failing period.
Check whether an event adjustment should have been applied at that period boundary.
Confirm the remaining depreciation horizon after that boundary.
Recompute the expected depreciation from the current balance and the remaining weighted periods.
Compare the schedule result to the journal result.
If they differ, find the first place where schedule and journal sourcing diverged.

That sequence is faster because it follows the dependency chain. If the opening balance is wrong, the journal comparison is just downstream noise.

If the issue turns out to be evidence rather than calculation, remember that Excel export is available on Pro. That helps when the debugging session needs a reviewable workbook rather than a browser screenshot.

Reviewability is more useful than neatness

Teams often want depreciation outputs to look simple. That is understandable. But a neat file is not always a reviewable one.

The stronger goal is a file where a reviewer can answer four questions without rebuilding the whole model:

where did opening ROU come from?
what event changed it, if any?
how was the current depreciation charge derived?
does the journal agree to that same charge?

If the model can answer those four questions cleanly, the depreciation layer is probably healthy.

If it cannot, the problem is not that the reviewer is being difficult. The problem is that the schedule, event logic, and journals are no longer proving each other.

If you want to test the supported behavior against a live run, use the IFRS 16 calculator, then compare the output shape to the methodology and the broader IFRS 16 calculation guide. The point is not to admire the depreciation formula. It is to catch the moment when that formula stopped living in one deterministic pipeline.

Which depreciation check usually fails first in your review process: the closing balance movement, the event reset, or the journal tie-out?

This is general IFRS 16 education, not accounting advice. Review unusual facts, policy judgments, and unsupported workflows with your adviser or auditor.

Why IFRS 16 Modification Schedules Show Split Rows After a Payment Change

Adam Benn — Sun, 31 May 2026 05:40:59 +0000

Finance teams often have the same reaction the first time a modified schedule starts showing extra rows: it looks as though the model has duplicated the payment.

You change the payment date. You rerun the lease. Suddenly the lease liability schedule shows one row with no cash payment, then another row with the cash payment. If that pattern keeps showing up in later cycles, the immediate assumption is usually that the calculation has gone wrong.

In the calculator's supported non-CPI modification workflow, that is often not an error. It is the schedule preserving two different timing boundaries at once: the accounting cut-off and the revised payment date. If you want to test that behavior against a live model, start with the IFRS 16 calculator, then compare the revised rows against the schedule logic below.

This article explains why the rows split, why the first bridge period is not the same thing as an endless stub, and why you can still end up seeing paired rows in later periods even though there is only one cash payment on each revised due date.

The symptom looks like a duplicate payment

The visible symptom is easy to describe.

Before the modification, the schedule may have shown one clean monthly line per cycle. After the modification, the same part of the schedule may show:

a no-payment row where interest accrues
then a payment row on the revised due date

That feels wrong at first glance because the reader expected a single combined line.

The important point is that the extra row does not automatically mean there is an extra cash flow. In the supported workflow, it usually means the calculator is separating the interest-accrual slice from the cash-payment slice because the revised payment date no longer lands neatly on the original accounting cut-off.

If you are used to a spreadsheet that compresses everything into one row per month, that distinction can be hard to see. A structured IFRS 16 calculator makes the split more visible, which is useful for review but can surprise the first-time reader.

Two dates control the result

The easiest way to understand the row pattern is to separate the two dates that matter in a supported non-CPI modification.

The first is the modification effective date. That is the accounting boundary. It is the hard cut line where the old accounting stops and the revised measurement starts.

The second is the first revised payment date. That is the payment boundary. It tells the schedule where the revised cash pattern begins.

Those dates do not always land on the same day.

That is why a modified schedule can behave differently from the original lease. The schedule is not only answering, "When is the next cash payment?" It is also answering, "From which date does the revised accounting start?"

The public methodology page now describes that split directly. In the supported workflow, the calculator checks whether the entered first revised payment date already lands on a valid revised boundary, whether it falls inside the current seven-day snap window, or whether it needs a stub bridge instead of guessing an unsupported off-pattern payment date.

That is the key design choice: preserve historical rows, preserve the accounting cut line, and avoid inventing a payment boundary that the user did not actually confirm.

Why the first stub can turn into a repeating split pattern

This is the part that usually creates confusion.

The bridge stub itself is one-time. It is the period from the modification effective date to the resolved first revised payment date when those dates do not align.

But that does not mean the visible row split ends immediately after the bridge.

If the revised payment date keeps falling on a different day from the unchanged accounting cut-off, later cycles can still show paired rows. In practice, that means you may see a no-payment accrual row followed by the actual payment row in more than one later cycle.

So the right mental model is this:

the bridge stub is one-time
the revised payment cadence continues prospectively from the new payment boundary
the displayed schedule can keep splitting rows if that new payment boundary stays out of line with the accounting cut-off

That is not the same thing as duplicated payments. It is the schedule preserving timing boundaries.

The recent FAQ and methodology updates on the site were made specifically to explain this point more clearly because it is easy for a reviewer to question the output if the row pattern is not spelled out in plain English.

What the split rows mean for the lease liability, ROU asset and journal entries

The split-row question is mainly a lease liability schedule presentation issue, but it matters for the rest of the file as well.

The lease liability still follows the same logic:

opening balance
interest unwind for the relevant slice
cash payment when due
closing balance

What changes is where those movements are shown. When the timing boundaries do not align, the interest can sit on one row while the cash payment sits on the next.

That also means the journal entries stay interpretable:

the no-payment row is an accrual-only slice
the payment row is where the actual cash movement lands
the liability roll-forward should still reconcile from opening to closing balance

The ROU asset is not being duplicated because of the row split either. In a supported modification, the remeasurement and any resulting ROU asset adjustment still follow the calculator's scoped methodology. The visual split is about timing presentation in the liability schedule, not about double-counting the ROU asset.

If you want a broader walkthrough of how the engine builds schedules and journal entries, the calculation guide on the main site is the best companion reference for this article.

Why Excel models often make this harder to review

This is one of the places where spreadsheet workflows can create false confidence.

Many Excel models are designed around a simple expectation: one row per month, one payment date pattern, one tidy roll-forward. That works until the lease stops being tidy.

Once you introduce a payment-date change, a modification boundary, or a supported stub bridge, the workbook author has to decide how to represent that timing difference. Some models hide the split. Some compress it. Some accidentally overwrite it.

That is exactly why reviewers can become suspicious when a structured schedule shows more rows than the workbook they expected.

The problem is not that the structured schedule is more complicated. The problem is that the spreadsheet may have trained the reviewer to expect a simplified visual pattern rather than the underlying timing logic.

This is also where audit trail matters. A deterministic tool that shows the split and records the modification trace can be easier to defend than a workbook that silently flattens the same behavior. If the output is going into a review file, IFRS 16 working papers matter just as much as the raw calculation itself.

A quick review checklist for split rows

If a reviewer questions the result, the fastest way to test the schedule is not to stare at the row count. It is to check the timing logic.

Use this checklist:

Confirm the modification effective date.
Confirm the first revised payment date.
Check whether the first revised payment date aligned, snapped inside the supported window, or required a stub bridge.
Check whether later revised due dates still fall on a different day from the unchanged accounting cut-off.
Confirm that only one cash payment appears on each revised due date.
Reconcile the lease liability from opening to closing balance across the split rows.
Check that the related journal entries follow the same timing pattern.

If you need a workbook for review, sign-off or audit evidence, remember that Excel export is available on Pro. That matters because the split-row question usually becomes an evidence question, not just a calculation question.

Also remember the scope boundary. This explanation is about the calculator's supported non-CPI modification workflow. Separate-lease scope increases, broader bespoke packages and other out-of-scope fact patterns can still require separate modelling and policy review.

Use the calculator when you need a faster answer

If you are trying to work out whether a modified schedule is genuinely wrong or simply showing preserved timing boundaries, it is faster to test the dates directly than to argue from a screenshot.

The free IFRS 16 calculator is useful for exactly that kind of check. You can compare the effective date, the revised payment date and the resulting schedule shape, then inspect the methodology and supporting pages when the row pattern needs to be explained to someone else.

The key lesson is simple: repeated paired rows after a payment-date change do not automatically mean duplicated cash payments. In the supported workflow, they often mean the schedule is still separating the accrual slice from the payment slice because the accounting boundary and revised payment boundary remain different.

That is easier to defend once it is stated plainly, and much easier to review once the schedule, methodology, journal entries and export trail all point to the same explanation.

This is general IFRS 16 education, not accounting advice. Review unusual fact patterns, policy judgments and unsupported workflows with your adviser or auditor.