You try to post a stock entry dated last week and ERPNext refuses, because a Stock Reconciliation exists somewhere after that date. The entry is a legitimate correction, the quantities are real, and the system will not take it. This validation arrived on the v15.80 line and it has annoyed enough people to have its own issue. It is also, more often than not, doing exactly what it should. This guide separates the cases where the block is protecting you from the cases where the reconciliation itself was wrong, and gives you the unwind sequence for the second.
Not sure the reconciliation was right in the first place?
Everything below turns on that question. If you need to establish how a Stock Reconciliation is supposed to behave before deciding, ERPNext stock reconciliation: the complete how-to covers the mechanics.
A validation that people complain about is not automatically wrong — sometimes it is the first thing stopping a process problem from becoming a ledger problem. I am Manoj, ERPNext and Frappe implementation lead at Mith Tech in Bengaluru, and this block is the one clients most often ask me to switch off, and most often should not.
Why the validation exists
A Stock Reconciliation is not a movement. Every other stock document says "this much came in" or "this much went out"; a reconciliation says "regardless of everything before this instant, the quantity here is now 120". That absolute assertion is what makes it useful for correcting drift between the system and a physical count.
It is also what makes earlier insertions incoherent. If a reconciliation on the 15th asserts 120 units based on someone walking the aisle and counting, and you then insert a receipt of 30 units dated the 5th, one of two things must be true: either the count on the 15th was wrong, or those 30 units were already among the 120 counted. The ledger cannot represent both a physical count of 120 and an unrecorded 30 that preceded it.
The behaviour ERPNext exhibited before the validation is the reason the validation exists. As the documentation describes it, a reconciliation is not modified by subsequent transactions with an earlier posting date — so a backdated entry would post successfully and then be silently overridden by the reconciliation's assertion. Users met this as a stock-ledger mismatch, where an entry they had definitely made simply did not affect the closing balance.
Set the stock entry and reconciliation dates and quantities to see whether the entry is blocked, and what the closing balance becomes in each case.
The entry sits before a Stock Reconciliation, so the validation refuses it. Note what would happen if it were allowed: the reconciliation on day 15 would still assert 120, so your backdated 30 units would be absorbed and vanish from the closing balance — the mismatch reported on the forum.
Illustrative model of the validation from PR #49549 as described in #49861 (ERPNext v15.80.0). Confirm behaviour on your own release before designing a process around it.
Move the entry date across the reconciliation date and watch what happens to the closing balance. Before the reconciliation, the quantity is absorbed and disappears. After it, the quantity lands in stock. That difference is the whole argument for the validation: the blocked posting was never going to do what the user expected.
Check the accounting period before planning anything
Two independent locks can apply. The stock validation blocks the backdated posting, and your accounting period close blocks the general-ledger side even where the stock side would allow it. If your correction targets a closed period, solve the accounting question first — reopening a period to satisfy the ERP is almost never the right answer, and it is a decision that belongs with your finance lead rather than with whoever is holding the stock entry.
Which case are you actually in
The block has one behaviour and five quite different underlying situations. Only one of them justifies cancelling the reconciliation.
Select why you are trying to post a backdated entry to see why the validation is refusing it and what the correct response is.
Pick why you are trying to post a backdated entry.
The pivotal question is the one in the middle: did the physical count behind that reconciliation already include the stock you are now trying to add? If it did, posting the entry at all would double-count — the reconciliation is right and your correction is redundant as a quantity movement, however real the underlying paperwork is. If it did not, the reconciliation was measured against an incomplete picture, and it is the reconciliation that needs to go, not the validation.
That distinction is worth taking seriously because it is answerable. Someone counted. Ask them what they counted.
The correct unwind
Copy-paste diagnosis steps, the two correction sequences, a draft backdated-entry policy, and the process changes that stop the block firing.
Find the reconciliation that is blocking you, and check whether it already accounts for what you are trying to post.
1. Find the blocking reconciliation:
Stock > Stock Reconciliation
Filter: Item + Warehouse from the error
Sort: Posting Date ascending
The earliest one AFTER your intended posting date
is what is blocking you.
2. Open it. Note the counted qty it asserted and who
submitted it.
3. The decisive question:
Did the physical count behind that reconciliation
ALREADY include the stock you are now trying to
backdate?
YES → do not post it at all. You would double-count.
Record it for costing only, dated after.
NO → the reconciliation was measured wrong.
See "Correct properly" — cancel it first.
4. Check the accounting period status for your target
date before planning anything.Find the blocking reconciliation
Filter Stock Reconciliation to the item and warehouse from the error, sorted by posting date ascending. The earliest one after your intended posting date is what is refusing you. Open it, note the counted quantity it asserted, and find out who submitted it — you are going to need to ask them what the count covered.
Answer the double-count question
Did the physical count already include the stock you want to backdate? If yes, stop: the quantity is already in the ledger via the reconciliation, and posting it again inflates stock. Record the document for costing or audit purposes with a date after the reconciliation, and note why. If no, continue.
Cancel the reconciliation before anything else
Where the reconciliation was measured wrong, cancel it first. Everything after it inherits an assertion that was never true, so correcting around it produces a second wrong number rather than a right one. Cancelling a submitted reconciliation should be an approved action with a logged reason — this is not a routine operation.
Post the backdated entry, then let the repost finish
With the reconciliation gone, post the entry with its true posting date and time. A backdated insertion triggers a Repost Item Valuation across everything after it. Let it complete before proceeding — a queued or failed repost means the valuation you are about to reconcile against is not yet settled, which is covered in our Repost Item Valuation guide.
Re-run the reconciliation and verify
Re-run the Stock Reconciliation with the correct counted quantity, then confirm the Stock Ledger balance at the reconciliation's posting instant matches it. If those disagree, something else is outstanding — most often a second backdated entry nobody mentioned, or a negative-stock condition of the kind covered in our negative stock guide.
When stores, accounts and the ERP owner are different people
The person hitting this block is usually in stores, at the end of the day, holding a delivery challan from last week. The person who submitted the blocking reconciliation is in accounts. The person who could cancel it is neither.
Left unresolved, the predictable outcome is that the stores user posts the entry with today's date and says nothing, because that is the only action available to them. The quantity is then right and the timing is wrong, which is usually the lesser evil — but it happens silently, so nobody knows the ledger contains a movement attributed to the wrong week, and nobody can explain the variance when a customer queries a delivery date three months later.
The pattern that works is a documented escalation with a named owner and a short queue. Give stores one sanctioned action — post after the reconciliation, narrate the true date — plus a log. Then have whoever owns inventory review that log weekly and decide which entries warrant cancelling a reconciliation and which do not. You are not trying to give stores the power to cancel reconciliations. You are trying to stop them from needing to make the decision alone at six in the evening.
Draft policy for your inventory and finance leads to ratify. Stock Reconciliation is a scheduled period-end control, not a routine correction tool. No stock entry is posted with a date earlier than the most recent Stock Reconciliation for that item-warehouse; where the reconciliation is believed wrong, it is cancelled and re-run under approval from the inventory owner, with a logged reason — it is never worked around. Corrections belonging to a closed accounting period are posted in the current open period, referencing the original date in the narration; periods are not reopened to satisfy the ERP. Data entry runs no more than two working days behind physical movement, and routine backdating is treated as a process defect rather than a system limitation. The entry-lag window and approval threshold are a starting point — set them against your own volumes and have your auditor confirm the period-close treatment before adoption.
Post after, or cancel and re-run
FAQ
+Why can't I post a backdated stock entry in ERPNext?
Because a Stock Reconciliation exists later in the timeline for that item and warehouse. The validation added in PR #49549 refuses backdated entries in that situation, since a reconciliation asserts an absolute counted quantity that an earlier insertion would contradict.
+Can I turn off the backdated entry restriction?
+What happens if a backdated entry is posted before a stock reconciliation anyway?
The reconciliation overrides the balance regardless of what precedes it, so the backdated quantity is absorbed and does not affect the closing balance. Users meet this as a stock-ledger mismatch where an entry they definitely made appears to have had no effect — which is the behaviour the validation now prevents.
+How do I correct a stock reconciliation that was wrong?
Cancel it, post the backdated entry that should have existed with its true posting date, let the resulting Repost Item Valuation finish, then re-run the reconciliation with the correct counted quantity. The order matters: correcting around a wrong reconciliation produces a second wrong number rather than a right one.
+Which ERPNext version introduced this validation?
+What if the correction belongs to a closed accounting period?
Do not reopen the period. Post the correction in the current open period with a narration referencing the original date, which is the standard treatment for a prior-period stock correction. Whether it needs any further disclosure depends on materiality, and that judgement belongs with your auditor.
+How do we stop hitting this block?
Reconcile on a schedule rather than reactively, and close the gap between physical movement and data entry. Most backdating exists because paperwork reaches the desk days after the goods moved — the validation is surfacing that process problem rather than creating it. Fewer, scheduled reconciliations mean fewer walls in your timeline.
Related issues you may also hit
- Backdated entries not being absorbed as expected by a future reconciliation, discussed on the Frappe forum.
- The opposite request — more validation to restrict backdated entries (#47673).
- ERPNext Repost Item Valuation stuck: causes and fix — what runs after every backdated insertion.
- ERPNext negative stock error — the other validation backdating commonly trips.
- ERPNext stock ledger vs general ledger — where an unresolved mismatch eventually shows up.
Closing
This is one of the rare cases where the right response to a blocking validation is to leave it alone. The block exists because the alternative — a backdated entry silently absorbed by a later reconciliation — was worse and harder to detect. Treat reconciliation as a scheduled control rather than a way to fix a number, close the gap between goods moving and paperwork landing, and the validation stops being something you meet at six in the evening.
Stock corrections piling up behind reconciliations nobody wants to cancel?
We work out which reconciliations are load-bearing, set the escalation path for corrections that need one cancelled, and close the entry lag that creates the backdating in the first place.