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.
Top comments (0)