Loan restructuring and modification
Extending tenor or cutting rate is a NEW loan on the books. It just doesn't feel like one.
By Solomon Ajayi · Free to read, no signup
A user has a ₦100,000 loan, 6 months in, with 6 months left at 24% APR. They lost their job. You restructure: extend the tenor by 12 months and cut the rate to 12% APR for the remaining balance. Under IFRS 9, this is potentially a SUBSTANTIAL MODIFICATION, meaning you derecognise the original loan and book a new one at fair value. If it's only a MINOR modification, you adjust the carrying amount and book a modification gain/loss. The line between the two is a 10% NPV test. This lesson walks the minor-mod path: NPV of new cash flows came out at ₦92,000 vs the carrying amount of ₦95,000, a ₦3,000 modification loss flows to P&L.
When you extend a borrower's tenor or cut their rate, nothing visible moves. No cash changes hands, the user just sees a friendlier repayment schedule in the app. But accounting cares about the value of the promised cash flows, and you just made those flows worth less to you. The change has to land on your books even though the bank account did not budge.
IFRS 9 splits restructures into two paths using a 10% NPV test. If the present value of the new cash flows differs from the carrying amount by more than 10%, it is a substantial modification: you derecognise the old loan entirely and book a new one. Below that threshold it is a minor modification: you keep the loan but write its carrying amount down to the new NPV, and the difference flows to P&L as a modification loss. The subtle rule is which discount rate you use, and the answer is the original effective interest rate, not the new one.
Discounting at the original rate is deliberate. It keeps your reported yield comparable to what you expected before the restructure, so interest income going forward accrues on the written-down carrying amount at the original effective rate. That catch-up mechanism is what stops a wave of restructures from silently distorting your yield reporting. Bake the 10% test into the restructure engine so the major-versus-minor decision is automatic rather than a judgment call someone forgets to make.
Worked example, step by step
Current state: ₦95,000 net carrying amount
User's loan: ₦100,000 gross, ₦5,000 of fees / prior impairment netted out, ₦95,000 net carrying. Marker entry to set state in this sandbox.
| Account | Debit | Credit |
|---|---|---|
| Gross Loan Receivable (1500) | ₦95,000.00 | |
| Modification Loss (P&L) (5500) | ₦95,000.00 |
Gross Loan Receivable UP ₦95,000 (debit). Off-ledger: we mark this as the loan's current net carrying value. The next entry will write it DOWN to the new NPV.
Re-NPV the loan at the new rate: ₦92,000
Restructure: new rate 12%, new tenor 18 months. You discount the new cash flows at the ORIGINAL EIR (effective interest rate, 24%), IFRS 9 mandates the original EIR, not the new rate. The PV of the new cash flow stream at 24% comes out at ₦92,000. The difference (₦95,000 − ₦92,000 = ₦3,000) is your modification loss.
| Account | Debit | Credit |
|---|---|---|
| Modification Loss (P&L) (5500) | ₦3,000.00 | |
| Gross Loan Receivable (1500) | ₦3,000.00 |
Modification Loss UP ₦3,000 (expense, debit, hits P&L). Gross Loan Receivable DOWN ₦3,000 (credit). The loan now sits at ₦92,000 on your books. You'll accrue interest at the original EIR (24%) on this ₦92,000 carrying amount going forward, that's the IFRS 9 catch-up mechanism that keeps your reported yield comparable to the pre-restructure expectation.
Takeaway
Loan restructuring is mostly an accounting event, not a system-state change. The user's app shows them a new repayment schedule; your ledger shows a modification loss and a re-NPV'd carrying amount discounted at the ORIGINAL effective interest rate. Skip this discipline and your yield reporting drifts, your auditors flag the loan book, and your CFO can't explain the next quarter's interest income. Build the restructure engine with the 10% NPV test baked in so 'major' vs 'minor' modification is automatic.
Practice this on a real ledger
Reading is half of it. Open this lesson in the lab to post the entries yourself against a real Postgres-backed double-entry ledger, with the validation on. Free, your sandbox is yours.