Repost Item Valuation is the ERPNext job that quietly recalculates your stock value whenever a backdated transaction disturbs the ledger. When it works you never notice it. When it jams — frozen in "Queued", stuck at "In Progress 0.5%", "Failed" with a cryptic log, or silently "Skipped" during year-end close — your inventory value and your General Ledger drift apart until someone spots the gap. This guide maps each symptom to its actual cause, estimates how heavy a repost will be before you run it, and gives you copy-paste recipes to unstick it safely.
First time seeing this DocType?
Repost Item Valuation is a background DocType, not something you normally open by hand. If your stock value looks wrong after a backdated entry and you want the underlying valuation concepts first, start with how ERPNext calculates finished-goods cost, then come back here for the reposting mechanics.
Reposting is the single most misunderstood background process in ERPNext — half the "my stock value is wrong" threads on the forum trace back to a repost that never finished. I am Manoj, ERPNext and Frappe implementation lead at Mith Tech in Bengaluru; we clear stuck reposts on client instances often enough to have turned it into a checklist.
What Repost Item Valuation actually does
When you submit a stock transaction in the past — a Purchase Receipt dated last month, a Stock Reconciliation setting opening stock, a cancelled and re-entered Stock Entry — every valuation calculated after that date is now potentially wrong. Moving-average and FIFO valuation both depend on the exact sequence of movements, so inserting one earlier movement shifts every rate that followed.
Rather than force you to recompute by hand, ERPNext enqueues a Repost Item Valuation document. Per the official documentation, it recalculates Stock Ledger Entries from the affected point forward, the running stock balance, each item's valuation rate and stock value, and the related General Ledger entries — so that inventory value and the GL stay consistent. It runs in the background on a worker, and ERPNext's scheduler retries entries that failed.
That design is sound. The trouble is entirely operational: the job is heavy, the queue is serial, and when a worker dies mid-run the status is not always cleaned up.
Which symptom are you seeing?
The status column on the Repost Item Valuation list tells you most of what you need. Pick yours below — each maps to a documented cause and the specific fix, with the real frappe/erpnext issue it traces to.
Select the repost status you're seeing to get its most likely cause, the GitHub issue that documents it, and the fix path.
Pick the status you’re seeing on the Repost Item Valuation list.
"Queued" that never starts
The most common report. A repost sits in Queued for days (discuss.frappe.io #86862, #106870). Two causes dominate: the background worker isn't running to pick it up, or an earlier repost errored and the serial queue is blocked behind it. ERPNext has to process reposts in order — it cannot skip a broken one and carry on, because the later valuations depend on the earlier recomputation. Backdated cancellations are a frequent trigger for this jam (#25192).
"In Progress" frozen at a low percentage
A repost shows In Progress 0.5% and never advances (#45948). This is a zombie: the job died — a worker restart, a timeout, or a data error on one Stock Ledger Entry — but its status was never reset, so ERPNext believes it is still running and won't start the next one. There is a merged fix for the historical version of this, "the status of repost item valuation showing In Progress since long time", but instances still land in the state after ungraceful worker restarts. The cure is to reset the status, not delete the record.
"Failed"
A Failed repost has a linked Error Log, and it is usually a genuine data problem: a missing or zero valuation rate, a negative-stock point the recomputation can't reconcile, or — after a v14→v15 migration — a broken Serial/Batch bundle (#38796). Reposting simply cannot complete until the offending entry is corrected (#36634). Re-queuing before fixing the cause just fails again.
Runs forever
Not stuck — genuinely huge. Reposting recomputes every Stock Ledger Entry from the posting date forward for the affected item-warehouse pairs. A low posting date, many backdated transactions, or batched items with many bundles can turn one repost into hundreds of thousands of row rewrites, which drags the whole instance (#26625, #36634). The answer is to narrow it, not wait it out.
Estimate the load before you run it
Before you unstick and re-run a big repost, get a sense of its size. A repost that reaches back six months across dozens of items is a very different animal from one scoped to a single item since last week. Nudge the inputs to your situation — if the band comes back "High", narrow the repost before starting it.
Order-of-magnitude estimate of how many Stock Ledger Entries a repost will recompute, with a risk band and recommendation.
Safe to run interactively. This is an order-of-magnitude estimate, not a row count — reposting recomputes every Stock Ledger Entry from the posting date forward for the affected item-warehouse pairs.
Never run a wholesale repost on a live instance during business hours
A "Repost All" from a low date recomputes the entire stock ledger and will lock tables other users are trying to write to. If the estimator shows Medium or High, schedule it off-hours, and prefer narrowing to the one Item and Warehouse that actually changed over a blanket repost.
Unstick it safely
You have diagnosed the symptom and sized the load. Now clear it — in this order. The recipes below are copy-paste; each tab is one step of the sequence.
Diagnose the queue, reset an In-Progress zombie, and prevent future runaway reposts — copy-paste bench and console recipes.
Always look before you touch. Confirm the workers are alive and see what is actually queued.
# Are the background workers running at all?
bench doctor
# List Repost Item Valuation docs that are not Completed,
# newest first (run in: bench --site <site> console)
frappe.get_all(
"Repost Item Valuation",
filters={"status": ["!=", "Completed"]},
fields=["name", "status", "modified", "voucher_type", "voucher_no"],
order_by="modified desc",
)Diagnose — confirm workers and see the queue
Run bench doctor to confirm the background workers are alive. Then, in the site console, list every Repost Item Valuation that is not Completed, newest first. You are looking for the oldest non-completed entry — that is the one blocking the serial queue.
Back up before you change anything
Run bench backup (or bench backup --with-files if you prefer). You are about to change document state directly; a backup is the difference between a five-minute fix and a very bad afternoon.
Clear the blocker
If the head entry is Failed, open its Error Log, fix the underlying Stock Ledger Entry — most often a zero/negative valuation rate — then re-run it. If it is a frozen In Progress zombie, reset its status to Queued and re-enqueue it (recipe tab: "Reset an In-Progress zombie"). Do not delete it; deleting loses the audit trail of what the repost was correcting.
Let the queue drain, then verify
Once the blocker clears, the entries behind it process in order. Verify by re-checking a corrected item's Stock Balance and its valuation rate against the Stock Ledger report. Confirm the Bin quantity matches the ledger.
Prevention — stop spawning the problem
Most stuck-repost tickets are self-inflicted through how stock gets entered. Three habits remove the majority:
- Set opening stock with one Stock Reconciliation, not a pile of backdated Stock Entries. Each backdated entry can spawn its own repost; a single reconciliation is one clean recomputation.
- Post in the current period. Backdating into old months is the root trigger. When you must correct history, expect — and schedule — the repost it will cause.
- Gate fiscal-year close on "no pending reposts". This is the lesson of discuss.frappe.io #163451: a repost that would touch a period you are closing gets skipped so it can't alter closed balances, but if you close with reposts still queued, the skipped recomputation leaves Bin and valuation inconsistent. Treat an empty non-completed repost list as a hard precondition for closing the year.
Fix now, or narrow and defer?
FAQ
+Why is my Repost Item Valuation stuck in Queued?
Either the background worker isn't running to pick it up, or an earlier repost failed and the serial queue is blocked behind it. Reposts process strictly in order because later valuations depend on the earlier recomputation, so one broken entry stalls everything queued after it. Run bench doctor to confirm the workers, then find and fix the oldest non-completed entry.
+How do I fix a repost that's stuck In Progress at a low percentage in ERPNext?
Reset it, don't delete it. The job died mid-run and left its status frozen, so ERPNext won't start the next repost. Take a backup, set the stuck document's status back to Queued, reset its progress index, and re-enqueue it. The "Reset an In-Progress zombie" recipe tab above has the exact console commands.
+Is it safe to delete a stuck Repost Item Valuation document?
No. Deleting loses the record of what the repost was correcting and can leave the stock ledger half-recomputed. Always reset the status and re-run instead. If a repost is genuinely obsolete, cancel it through the proper flow after confirming the ledger is consistent — don't hard-delete.
+What triggers a Repost Item Valuation in the first place?
Any backdated stock movement: a Purchase Receipt, Stock Entry, or Stock Reconciliation posted before existing entries; a cancelled backdated transaction; a bulk stock import; or a Landed Cost Voucher revaluing an earlier receipt. ERPNext enqueues a repost so every valuation after that point is recomputed in sequence.
+Why did my repost get Skipped during year-end closing?
Reposting is skipped for closed accounting periods by design, so it cannot change balances you've already closed. The risk is closing the year while reposts are still pending — the skipped recomputation then leaves Bin quantity and valuation inconsistent. Drain all pending reposts before you close the fiscal year.
+Will reposting change my closed financial year's numbers?
Not for genuinely closed periods — it skips them. That protection is also the trap: it means a repost you needed won't run against a closed period, so the correction is simply lost unless you sequence it before closing. If you must correct a closed period, book a Journal Entry in the current period instead of reopening the year.
+Does this apply to ERPNext v14, v15 and v16?
Yes. Repost Item Valuation and its Queued / In Progress / Failed states exist across v14, v15 and v16, and the stuck-status reports span all three (issues #25192 through #45948). The reset-don't-delete fix and the prevention habits are the same on each; only cosmetic UI details differ.
+How long should a repost take?
There is no fixed number — it scales with how many Stock Ledger Entries it recomputes from the posting date forward. A narrow, recent repost finishes in seconds; a wholesale repost from a low date across many items can run for hours and lock the instance. Use the load estimator above to judge before you start.
Closing
Repost Item Valuation is not fragile so much as unforgiving: a serial queue, a heavy per-job cost, and a status field that doesn't always clean up after a dead worker. Diagnose the head of the queue before you touch anything, reset zombies rather than deleting them, and stop backdating stock into old periods, and the whole class of "my valuation is wrong" tickets largely disappears.
Stock value and GL drifting apart after a botched repost?
We audit the repost queue, fix the blocking entries, reconcile Bin against the ledger, and put a year-end close checklist in place so it doesn't recur.