ERPNext Asset Scrap Triggers Depreciation on a Closed Period (2026)

A disposal that can't be recorded because of a depreciation entry that shouldn't exist is the kind of fault that makes people force it at the database and regret it at audit. I am Manoj, ERPNext and Frappe implementation lead at Mith Tech in Bengaluru, and this one turns up whenever a business finally clears out assets that fully depreciated a year or two ago.

What actually breaks

Scrapping an asset in ERPNext is a disposal event: it removes the asset from service, posts the loss or gain on disposal, and marks the asset "Scrapped". The flow expects the asset to be depreciated up to its disposal date first, because you cannot dispose of something whose books are not current.

The defect in #45777 is that the scrap attempts a depreciation posting even when the schedule is already complete — when there is, by definition, nothing left to depreciate. On its own that would merely produce a spurious entry. The failure becomes visible when the disposal date falls in a closed period: the depreciation journal entry the scrap tries to post is rejected by the period lock, and because the scrap depends on that posting, the entire operation rolls back. You are left unable to record a disposal that is accounting-complete, blocked by an entry the asset does not owe.

PR #45895 fixes it by skipping the depreciation posting when the schedule is already fully booked, so the scrap of a fully-depreciated asset stops trying to depreciate it.

Five symptoms, and which is yours

Asset disposal and depreciation faults present in similar ways — "it won't let me scrap", "an entry appeared I didn't expect", "I'm getting error emails". They have different causes.

The one that traps people is the inability to cancel the spurious entry once it has posted (#35934): the asset says a journal entry references it, the journal entry says an asset references it, and neither releases the other. That is a reason to resolve the reference order carefully, never to delete at the database — a forced removal is how a one-entry problem becomes a permanent register-to-ledger mismatch, the same failure mode covered in our depreciation-schedule guide.

Fix it

1. Open the Asset. Confirm:
     • Depreciation schedule is fully booked
       (no remaining rows with a future date)
     • The disposal / scrap date falls in a period
       your accounts team has closed

2. Read the error trace on the failed scrap. The
   signature is a Journal Entry posting rejected
   because its date is in a closed period.

3. Version check: Help > About. Below the release
   carrying PR #45895 (v15.51.0 was the reported
   affected version)? Then you are exposed.

4. If the schedule is NOT complete, this is not the
   bug — book depreciation to the scrap date first.

What the standard says about disposal

This is not only a code question — the accounting standards are explicit that a scrap should not be posting more depreciation.

When the disposal owner isn't the ledger owner

The person scrapping the asset is usually in operations or facilities — the machine is gone, they want it off the books. The person who closed the period is in accounts. Neither expects an asset disposal to collide with a period lock, so when it does, the operations user often escalates it as "the system is broken" and the accounts user, reasonably, does not want to reopen a closed period for what looks like a routine scrap.

The resolution is a small standing agreement rather than a permission change. Disposals dated into a closed period route to accounts, who decide whether to reopen briefly or hold the scrap for the next open period. Most disposals do not need to be recorded in a prior period at all — the asset can be scrapped effective the current date, which sidesteps the lock entirely. Reserve reopening for the cases where the disposal genuinely belongs to the closed period for reporting reasons.

Draft policy for your accounts and operations leads to ratify. Fully-depreciated assets are scrapped effective the current open period wherever the disposal date is not materially required to fall earlier. A scrap that must post into a closed period is authorised by the accounts owner, who reopens the specific period with a logged reason and re-closes it the same day; any depreciation entry the scrap posts against a completed schedule is cancelled and accumulated depreciation is reconciled to the fixed asset register before re-closing. Assets are never scrapped by deleting journal entries at the database. Ratify the reopening authority and the materiality test with your auditor before this enters an SOP.

Upgrade now, or work around once

FAQ

Related issues you may also hit

• The depreciation schedule miscalculating after a cancel-and-rebuild (our guide, tracking #50701).
• Daily "error while posting depreciation entries" emails from a scheduled job (#34045, #38202).
• ERPNext stock ledger vs general ledger — the same register-to-ledger reconciliation discipline on the stock side.
• Standard costing in ERPNext — where depreciation feeds overhead absorption.

Closing

The bug is small and already fixed; the damage comes from how people route around it. Scrap fully-depreciated assets into the current open period, keep disposals that must fall earlier under the accounts owner's control, and reconcile accumulated depreciation every close. Do that and an old machine leaves your books in a couple of clicks instead of a database edit you explain to the auditor.