Hi everyone,
I’m encountering a persistent issue with the Stock Ledger and Repost Item Valuation logic when dealing with backdated transactions. It seems the system is not correctly recalculating the adjustments needed for future Stock Reconciliation entries.
The Scenario:
-
I have a Stock Reconciliation posted on 11th November 2025 to set an item’s quantity to 1.
-
I later realized I missed an opening balance, so I made a backdated Stock Entry (Material Receipt) on 1st July 2025 for 56 qty.
-
After various intervening transactions (Delivery Notes/Purchase Receipts) between July and November, the running balance reaches 42 just before the November Reconciliation.
The Issue:
Even though the Nov 11th Reconciliation is supposed to force the stock to 1, the Stock Ledger is ignoring it. The reconciliation entry shows 0 In/Out Qty and maintains the balance at 42.
It appears the Reposting engine is not calculating the necessary delta (in this case, an Out Qty of 41) to bridge the gap between the new backdated balance and the Reconciliation’s target quantity.
Evidence:
As you can see in the screenshot below, Line 7 is the Stock Reconciliation. The balance remains at 42.000 despite the document itself specifying a target of 1.
What I’ve tried:
Has anyone else faced this “hard wall” behavior with Stock Reconciliations during backdated reposting? Is there a specific setting or a known fix in the stock_ledger.py logic to ensure Reconciliations always force the qty_after_transaction to match the document value?
Appreciate any insights or pointers to the relevant code responsible for this.
1 Like
Hey, I’ve run into something very similar before, and it usually comes down to how ERPNext’s reposting logic treats Stock Reconciliation versus backdated entries.
From what you’re describing, it sounds like the reconciliation isn’t being re-evaluated properly during the repost, even though the job shows as “successful.” In theory, the reconciliation should always override and force qty_after_transaction, but in practice, that only happens if the repost logic recalculates the delta correctly.
A couple of things you might want to double-check:
-
Repost sequence order: Sometimes the queue processes entries, but not strictly in chronological dependency. If the reconciliation isn’t recalculated after all prior entries are adjusted, it can behave like a no-op.
-
Valuation method edge cases: If you’re using FIFO or Moving Average, there are known quirks where reconciliation doesn’t inject the expected difference if valuation layers get inconsistent.
-
Negative stock / allow settings: If “Allow Negative Stock” was toggled at any point, it can mess with how the engine computes adjustments during repost.
-
Known bug behavior: There have been discussions where Stock Reconciliation lines end up with 0 qty diff during repost because the system assumes balance is already aligned (even when it’s not after backdating).
One workaround that has helped me:
- Cancel and re-submit the Stock Reconciliation after the repost completes.
This forces ERPNext to recompute the delta fresh instead of relying on the repost engine.
If you’re digging into code, the behavior is usually tied to how get_stock_ledger_entries and repost logic calculate qty_diff vs qty_after_transaction. The reconciliation should explicitly set the balance, but sometimes that enforcement gets skipped during repost.
Also, I found some useful discussions and references around stock logic quirks while troubleshooting on this website might be worth a look.
If you figure out whether it’s a sequencing issue or a logic gap in stock_ledger.py, definitely share—this is one of those edge cases that pops up more often than it should.
