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:

1. Confirm the opening ROU balance for the failing period.
2. Check whether an event adjustment should have been applied at that period boundary.
3. Confirm the remaining depreciation horizon after that boundary.
4. Recompute the expected depreciation from the current balance and the remaining weighted periods.
5. Compare the schedule result to the journal result.
6. 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.