ERPNext Repost Item Valuation Stuck? Causes & the Fix (2026)

Reposting is one of the most misunderstood background processes in ERPNext; many "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 MithTech, a team of Frappe specialists in Bengaluru. We clear stuck reposts on client sites often enough to have turned it into a checklist.

What does Repost Item Valuation actually do?

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, 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 fix, with the frappe/erpnext issue it traces to.

"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 to 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 for hours

Not stuck, just 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.

How do you 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 very different from one scoped to a single item since last week. Set the inputs to your situation; if the band comes back "High", narrow the repost before starting it.

How do you 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.

# 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",
)

How do you stop it recurring?

Most stuck-repost tickets come from how stock gets entered. Three habits remove most of them:

• 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.

Should you fix now, or narrow and defer?

At a glance

FAQ: what do people ask most?

What is the bottom line?

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 delete them, and stop backdating stock into old periods, and most "my valuation is wrong" tickets go away. If the workers themselves are down, start with ERPNext background jobs not running.