You cancel an asset's depreciation schedule to correct something — a wrong useful life, a mis-dated entry, an amended purchase value. Some depreciation has already been booked. You rebuild the schedule, and the number of periods and the amounts come back wrong, covering the asset's whole life again rather than what is left of it. Nothing errors and the document submits happily. This guide gives you the check that catches it before it reaches the ledger, a sweep that finds every affected asset in your register, and the sequence for unwinding one that already posted.
This is the same failure shape as stock reposting
An event in the past triggers a recomputation, and the recomputation loses track of what was already recorded. If you have met it on the inventory side, the perpetual inventory gap between stock ledger and general ledger is the same problem wearing different clothes.
Depreciation errors are the most expensive category of ERPNext fault, because nothing blocks and nobody notices until the auditor reconciles accumulated depreciation. I am Manoj, ERPNext and Frappe implementation lead at Mith Tech in Bengaluru, and this is the asset fault I see most often on instances migrated from another system.
What goes wrong
An Asset Depreciation Schedule in ERPNext is a generated set of rows, one per depreciation period, each carrying an amount and a date. Cancelling it and creating a new one is a legitimate and reasonably common operation — you do it when the useful life was set wrong, when the purchase value is amended, or when a depreciation entry needs re-dating.
The rebuild has to answer one question: how many periods remain, and against what value. Issue #50701 reports that the routine deriving the final number of depreciations does not subtract the depreciations already booked, so the rebuilt schedule is generated as though the asset were new. The reporter's proposed correction — subtracting the opening number of booked depreciations from the final count — describes the shape of the gap precisely.
The output is a schedule that will depreciate value already written down. Because each individual row looks plausible, and because ERPNext raises no error, the entries post normally and the asset quietly over-depreciates for the rest of its life.
Enter your asset's gross value, salvage, total periods and periods already booked to see what a correct rebuilt schedule should total, and what ignoring booked periods would charge instead.
A rebuilt schedule covering 60 periods instead of the remaining 51 charges depreciation on value that has already been written down. Left unchecked it drives net book value below salvage and, in the worst case, negative — the shape reported in #34920.
Straight-line arithmetic using your own inputs, modelling the behaviour described in frappe/erpnext #50701 (open). Reconcile against your fixed-asset register and confirm the treatment with your auditor before adjusting anything.
The end state, if nobody catches it, is the one described in #34920: a schedule extending past the gross purchase amount with a final row carrying a negative value. That is the fault at its most visible. The dangerous phase is everything before it, when the numbers are merely wrong rather than absurd.
Check the opening booked-depreciation count on every migrated asset
If assets were brought in from another system carrying accumulated depreciation, the opening number of booked depreciations is the field every later recalculation depends on. Get it wrong at migration and schedules will be wrong on rebuild regardless of any patch. Verify it across the register before your first period close — this is the single most common root cause on newly migrated instances, and it is also the cheapest to fix while nothing has posted.
What the standards require
Depreciation is one of the areas where the major frameworks genuinely converge, which makes this straightforward to assess: there is no reporting basis under which an over-depreciating rebuilt schedule is acceptable.
Treatment under each framework
IAS 16 (IFRS Foundation) requires the depreciable amount — cost less residual value — to be allocated systematically over the asset's useful life, and the charge to be recognised each period. A schedule that re-depreciates written-down value allocates more than the depreciable amount, which the standard does not permit.
Ind AS 16 (MCA), India's carve-in of IAS 16, carries the same requirement. For companies still on the pre-Ind-AS legacy standard, AS 10 reaches the same outcome by the same logic.
US GAAP — ASC 360 (FASB) requires cost less salvage to be allocated over the useful life in a systematic and rational manner. Depreciating beyond that base is neither systematic nor rational, and the resulting carrying amount misstates the asset.
UK GAAP — FRS 102 §17 (FRC) requires the depreciable amount to be allocated on a systematic basis over the useful life, with the residual value and useful life reviewed if expectations change. A rebuild after a life change is exactly the review the standard contemplates — but it must run from the remaining amount.
The convergence matters practically: whichever basis you report on, the auditor's test is the same. Accumulated depreciation reconciles to the register, and carrying amount never falls below residual value. Confirm the treatment for your entity with your own auditor before relying on any of this.
Five asset faults that look alike
Asset depreciation has several distinct issues, and they get conflated because they all present as "the depreciation number is wrong". They have different causes and different fixes.
Select the asset symptom you are seeing to identify the underlying cause, the tracking issue, and the right response.
Pick the asset symptom you are seeing.
The one to rule out early is the inability to cancel a depreciation journal entry (#35934), because it blocks the remediation rather than causing the error. If you cannot cancel, work out the reference order before doing anything forceful — deleting at database level leaves the asset's booked count and the general ledger permanently inconsistent, which is a materially worse position than the one you started in.
Detect, verify, remediate
A register-wide sweep to find affected assets, the pre-posting verification, the unwind sequence for posted errors, and the habits that prevent recurrence.
A whole-register sweep that finds every asset whose schedule cannot be right, without opening them one at a time.
Report Builder → Asset Depreciation Schedule
Add columns:
asset, status, total_number_of_depreciations,
opening_number_of_booked_depreciations
The two arithmetic checks that catch this class:
1. Sum of schedule rows > (gross_purchase_amount
- salvage_value)
→ schedule exceeds the depreciable base (#34920)
2. Rows in an ACTIVE rebuilt schedule
!= total_number_of_depreciations
- opening_number_of_booked_depreciations
→ rebuild ignored booked periods (#50701)
Run both across the whole register, not just the asset
that prompted the question. Where one asset drifted,
others usually did too.Sweep the whole register, not one asset
Build a Report Builder view on Asset Depreciation Schedule with the asset, status, total number of depreciations and opening booked count. Two arithmetic tests find this class: any schedule summing to more than gross less salvage, and any active rebuilt schedule whose row count is not total periods less booked periods. Where one asset has drifted, others usually have.
Verify before every post
Expected remaining rows are total depreciations less those already booked. Expected total is current net book value less salvage — not the original depreciable base. Count the rows and sum the amounts on the rebuilt schedule. If either disagrees, stop. This takes ten seconds and it is the difference between a schedule problem and a ledger problem.
Establish the truth outside ERPNext first
Before touching a posted error, build the correct schedule in a spreadsheet from gross value, salvage, life and periods genuinely elapsed. You need a target to reconcile to. Attempting the correction without one turns into successive approximations against a live ledger, which is how one wrong asset becomes twelve.
Cancel newest first
List every depreciation journal entry posted from the bad schedule by date, and cancel in reverse chronological order. Out-of-order cancellation is where the circular reference in #35934 bites. If a closed period blocks a cancellation, do not reopen it unilaterally — post a correcting entry in the current open period and document the reasoning.
Rebuild, re-verify, reconcile
Rebuild the schedule, run the verification checks again, and only then re-post. Finish by reconciling accumulated depreciation to the fixed asset register before the period closes. The same discipline that applies to bank reconciliation applies here: the reconciliation is the control, and it only works if it runs every period rather than annually.
When finance owns the ledger and IT owns the instance
The person who cancels a depreciation schedule is usually in finance. The person who could tell them the rebuild is unreliable on this version is in IT, and is not consulted, because cancelling a schedule does not feel like a technical operation.
That gap is why this fault survives to year-end. Nothing in the interface signals that a rebuild carries risk, and the finance user has no reason to suspect the arithmetic. By the time the auditor's accumulated-depreciation reconciliation surfaces it, eleven months of entries have posted and the correction is a restatement conversation rather than a journal entry.
The control that works is a saved report and a period-close step, not a permission. Add "accumulated depreciation reconciles to the fixed asset register" to your monthly close checklist, owned by whoever signs the close. Pair it with a standing Report Builder view of schedules cancelled in the period, so a rebuild is visible to finance leadership in the month it happens. Neither prevents the fault; both cap the blast radius at one period.
Draft policy for your finance lead and auditor to ratify. Cancelling an Asset Depreciation Schedule on an asset with booked depreciation is a reviewed action: the expected remaining row count and total are computed and recorded before the rebuilt schedule is submitted, and no depreciation entry is posted from a schedule that fails either check. Accumulated depreciation is reconciled to the fixed asset register at every period close, not annually. Any variance above 1% of the accumulated depreciation balance, or above your posting materiality threshold — whichever is lower — is escalated before the period is closed. Assets migrated from another system have their opening booked-depreciation count verified before the first close. These thresholds are a starting point; set them against your own materiality and have your auditor confirm them before adoption.
Correct in place, or restate
FAQ
+Why is my ERPNext depreciation schedule wrong after cancelling it?
On affected versions, the rebuild derives the final number of depreciations without subtracting the periods already booked, so the new schedule covers the asset's whole life again instead of what remains. It is tracked as #50701 and reported on the v16 development line.
+How do I check whether my depreciation schedule is correct?
Count the rows in the rebuilt schedule — they should equal total depreciations less depreciations already booked. Then sum the depreciation amounts, which should equal current net book value less salvage rather than the original depreciable base. If either check fails, do not post.
+Which ERPNext version does this affect?
+Can I delete the depreciation journal entries and start again?
Cancel them, in reverse chronological order — newest first. Do not force a delete at database level: circular referencing between the asset, the schedule and the journal entry (#35934) means a forced removal leaves the asset's booked count and the general ledger permanently inconsistent.
+What happens if we don't fix an over-depreciating schedule?
Depreciation expense is overstated every period, net book value falls below residual value and can go negative, and accumulated depreciation stops reconciling to the fixed asset register. It surfaces at audit as a carrying-amount misstatement, by which point the correction spans a full year of entries rather than one.
+Does this apply to assets migrated from another system?
Those are the highest-risk population. A migrated asset's opening number of booked depreciations drives every later recalculation, and getting it wrong at migration produces bad rebuilds regardless of version (#27431, #48117). Verify the opening count across the register before the first period close.
+Is a wrong depreciation schedule a compliance problem or just a reporting one?
Both. IAS 16 and Ind AS 16, ASC 360 and FRS 102 §17 all require the depreciable amount to be allocated over the useful life, so a schedule charging more than that base misstates the asset under every one of them. Whether it rises to a reportable misstatement depends on materiality — that judgement belongs with your auditor, not with the ERP.
Related issues you may also hit
- Asset scrapping triggering depreciation against already-completed periods (#45777).
- The long-running asset depreciation refactor and its behaviour changes (#28231).
- ERPNext stock ledger vs general ledger: fixing the perpetual inventory gap — the same recompute-loses-history shape on the stock side.
- ERPNext bank reconciliation — the period-close discipline that catches this class early.
- Standard costing in ERPNext — where depreciation feeds overhead absorption.
Closing
The fault itself is arithmetic and will be fixed upstream eventually. What will not be fixed upstream is a close process that reconciles accumulated depreciation once a year. Add the reconciliation to every period close, verify the row count and total before posting from any rebuilt schedule, and check the opening booked count on every migrated asset. Those three habits turn this from an audit finding into a ten-second check.
Accumulated depreciation not reconciling and year-end approaching?
We sweep the register for schedules that cannot be right, rebuild them against the correct remaining life, and set the period-close controls that keep the ledger and the asset register together.