The regular Purchase Invoice being processed with the same entries before updates to erpnext June 2026 does not accept the entries anymore. Here are the screenshots, first the error:
the Purchase Invoice Items
and the tax details:
where the calculations are correct but the Purchase Invoice is not allowed to Save not even Submit. The Purchase Invoice has been created by duplicating the previous month’s invoice with similar amounts.
Is there a field getting copied while duplicating?
Looks like when the same tax account is added twice to the calculation, one automatically calculated and the latter manual meaning Actual, the updated logic throws the error.
To fix this issue, you need to remove the duplicate tax entries and let ERPNext handle the math automatically.
ERPNext maps taxes behind the scenes using a hidden map called item_wise_tax_detail. When you apply a tax template, the system dynamically calculates the tax allocation for every individual item based on the selected Account Head.
When you insert the exact same Account Head twice - once as an automated On Net Total row and again as a manual Actual row, the calculation engine gets conflicted. It cannot cleanly distribute a fixed, manual amount to the item rows when that same account head is already bound to an automated percentage calculation. This breaks the background math and triggers the validation mismatch error.
Remove Manual Rows: Go to the Purchase Taxes and Charges table on your draft invoice and delete the duplicate manual Actual rows that are using the same account heads as your calculated rows.
Set Up Taxes on the Item Master: Ensure that the specific tax rules and rates are mapped correctly within your Item Tax Templates or directly inside the Item Master.
Reset the Tax Table:
Clear out the rows in the invoice’s tax table completely.
Re-select your standard Tax Template.
This forces the system to flush the old calculation data copied from the previous month’s invoice and auto calculate the entire breakdown cleanly based on your item settings. Once the automated breakdown matches, the invoice will save and submit without any errors.
Let me know if it clears the roadblock for you 
Hi @Jatin_Banshpal more or less everyopne has access to AI. What makes the difference is the experience and the process you are dealing with.
This is not a one off entry and it’s been working fine as per the process requirements until June. The logic introduced recently has broken the flexibility of the controller. So, your suggestion is another waste of valuable resources.
The process involves automatically calculated and manually added fixed amount taxes posting to the same account. That’s where I’ve been able to narrow down the possible source of the issue.
The prompt is:
erpnext/erpnext/controllers/taxes_and_totals.py at develop · frappe/erpnext · GitHub is failing when both calculated and manually added fixed amount taxes post to the same account
and the AI response is:
You have just hit one of the most infamous, long-standing architectural quirks in the ERPNext accounting engine.
Because you are looking directly at erpnext/controllers/taxes_and_totals.py on the develop branch, you already know this isn’t a simple UI glitch. You are experiencing a dictionary key collision in the hidden item_tax_detail JSON that causes the exact validation error (“Item Wise Tax Details do not match…”) you saw earlier.
Here is exactly why the code fails when mixing “Actual” and “Calculated” taxes on the same account head, and how to bypass it.
In ERPNext, the calculate_taxes_and_totals logic distributes the overall document taxes down to individual items. It stores this distribution in a hidden JSON field on each item row called item_tax_detail.
The core flaw is how this JSON dictionary is structured. It uses the account_head as the unique key for each tax:
JSON
{
"VAT - MyCompany": [10.0, 50.00]
}
// [Tax Rate, Tax Amount]
When you have two rows in your Taxes and Charges table pointing to the exact same account_head—one for a percentage (e.g., 10%) and one for an “Actual” fixed amount (e.g., $21.82)—the Python code in taxes_and_totals.py loops through the tax table and attempts to write them both to the item row.
Because both taxes share the same account head, they fight for the exact same dictionary key.
Depending on the exact version of the develop branch, the loop either:
Overwrites the calculated percentage amount with the apportioned “Actual” amount (or vice versa).
Attempts to merge them but fails to calculate a valid unified “Tax Rate” for the array, dropping the actual amount from the item-wise sum.
When the document saves, the final validation routine compares the sum of the bottom Tax Table (which successfully added both rows) against the sum of the item_tax_detail JSONs (which lost a row due to the key collision). They don’t match, and it throws your error.
Since Frappe has historically resisted changing the item_tax_detail key from account_head to a unique tax_row_id (due to deep dependencies in the GL Entry posting logic), you have to solve this functionally or via custom scripts.
The cleanest way to bypass this codebase limitation without hacking core files is to never let two tax rows share the same account head if they use different calculation methods.
Create a child ledger account in your Chart of Accounts (e.g., VAT - Adjustments or VAT - Fixed Charges) nested under the same parent tax group.
Point your calculated percentage row to the main VAT account.
Point your “Actual” fixed-amount row to the VAT - Adjustments account.
Because the account heads are now different strings, taxes_and_totals.py will create two separate keys in the JSON dictionary, and the math will validate perfectly.
If you are trying to add a fixed shipping or handling fee that is subject to the calculated tax, do not put the fixed amount in the Taxes table.
Add the fixed amount as an Item on the invoice itself (e.g., “Service Charge” item).
The calculated percentage tax in the bottom table will automatically apply to it, distributing cleanly.
If you absolutely must patch taxes_and_totals.py for your instance, you have to intercept the set_item_wise_tax method (or wherever the item_tax_detail dict is populated in your specific commit).
You must add logic that checks if tax.account_head already exists in item_tax_dict.
If it exists, you must add the item_tax_amount to the existing amount at index [1], rather than overwriting it.
Warning: You also have to calculate a blended, fake “Tax Rate” for index [0] (e.g., (Total Tax / Item Base) * 100), or the print formats and downstream validation will still complain.
Having access to AI and actually testing a issue on a live system are two very different things. I don’t give theoretical answers. I test them on real instances.
I ran a clean test on a fresh ERPNext v16.10.1 / Frappe v16.12.0 instance to see what actually happens on the screen. Both released on March 2026.
When I create a draft invoice with 3 purchase items with a tax account set to auto-calculate via tax template set in item master, the system correctly generates the amount (in my test, ₹52.20).
Then, as soon as I manually add a second row using that exact same tax account and set it to Actual with ₹12.00, ERPNext immediately wipes the first row’s calculated amount down to ₹0.00 right on the form.
If you open the document’s Activity Log, the system explicitly records this automatic change:
“You changed the values for Amount from ₹52.20 to 0 in row #1”.
The system simply doesn’t allow a single tax account to hold two different calculation methods on the same invoice. The second entry overwrites the first one on the form, wiping out the calculated tax and causing the mismatch error when saving.
And to complete the test: the moment I delete that second Actual tax row from the invoice, ERPNext automatically recalculated Row 1 back to the correct amount (₹52.20), exactly as tracked in the Activity Log history.
So the behavior is crystal clear: stacking the same tax account twice forces a calculation overwrite every single time, whereas keeping it to a single entry lets the calculation flow smoothly.
In your case, even though the amounts stay visible on your form, it seems the calculation engine still overwrites the keys behind the scenes - creating mismatch error the moment you hit Save.
Hopefully, seeing actual system behavior, backed by logs helps more than relying on AI generated theories.
Somehow your test does not reflect our case as we have many purchase invoices transacted in 10 years like I have mentioned and the behaviour has just recently changed. Moreover such a behaviour does not make any sense businesswise. Using AI I also have pinpointed the logical error in coding and opened a bug. Sorry if I did not reflect my case propetky so that you could totally test it but I dont see any difference in what youce made so maybe the cose change is around march.
In v16 we have added the validation that taxable amount and rate should match with tax value in item wise tax details.
Why you need same account twice ?
What is the use case ?
ERPNext dosen’t support this.
The tem tax details should be validated agaist automatically calculated rows. It does not even need any business case. Say, the value calculated has a rounding error and you would like to correct it by entering a manual entry. Simplest case.
Our case is the same tax is both within the item and in the tax details as a separate lump sum tax as per the regulation. We’ve been doing fine for 10 years until we upgraded to v16.
Anyone interested in this and the solution is nearly submitted.
