We started experiencing a critical issue with the Inventory WIP Reconciliation Report after our Epicor Kinetic update on July 11–12.
For the same reporting period (July 1–13) and using what appears to be the same report parameters, I generated three separate Inventory WIP Reconciliation reports and received different results for GL 5094 (Job Material Variance).
What I’m seeing: NET GL 5094 balance remains the same across all three reports. However, the underlying variance transactions and job assignments are completely different.
One report shows variance transactions for 2 jobs.
Another report shows variance transactions for 3 jobs.
A third report shows variance transactions for 4 jobs.
When I drill into each job and run a detailed Inventory WIP Reconciliation analysis, the transaction details do not match the parent report and produce a different net variance amount altogether.
This behavior is concerning because running the same report for the same period should produce consistent and reproducible results.
Has anyone experienced a similar issue after a Kinetic upgrade? If so:
What was the root cause?
Was it related to WIP costing, variance processing, job closing, phantom purge, or report logic?
How was the issue resolved?
Did Epicor provide a patch or identify it as a known defect?
Unfortunately, our IT Manager is currently out of office and is the primary contact for Epicor Support, so I’m trying to gather as much information as possible before we can formally escalate the issue.
Any insights, recommendations, or similar experiences would be greatly appreciated.
First thing you need to do is to have a copy of LIVE into a test environment - this way you are sure nobody marks jobs as closed while you run the reports. Alternatively you can run the WIP report outside business hours and check it then but this can still be inconclusive if there is a job auto closing process running between your tests.
Also make sure you run it with both posted and unposted transactions marked: if cos&wip gets posted automatically overnight, the report from today will look different than the report from tomorrow (run up to today) because some transactions were posted (or some labor transactions were approved and posted as well).
So far never had a COS&WIP Recon report change on same period so I would not think it is a Epicor defect but rather some other explanation for your problem.
Hi Mihai Dorin, thank you for your response and suggestions.
We’ve been running the Inventory WIP Reconciliation Report under controlled conditions. The report is generated for a fixed period (from the first day of the month through the day prior to the report run), or after business hours when no users are processing inventory transactions, labor entries, or job activity in Epicor. In addition, Finance doesn’t post COS/WIP until after our review of the reconciliation report for the selected period is complete.
So, we verified that the overall NET variance in Job Variance GL is accurate and reconciles correctly at the GL level. The issue appears to be with the allocation of Job Variance GL records to individual jobs within the parent report, where amounts are being assigned incorrectly despite the total DR and CR remaining correct.
Given these findings, we escalated the issue to Epicor Support. The case has since been reviewed by Epicor and is currently being prioritized with their Development team. Based on their investigation to date, Epicor believes the behavior may be related to a recent Epicor Kinetic update deployed around July 10–11, as the issue was not observed prior to that update.
Hi Haso Keric, we do experience the MFG-VAR transaction issue with the similar error when overall NET variance in Job Variance GL is accurate and reconciles correctly at the GL level. And it appears to be with the assignment of Job Variance GL records to individual jobs within the parent report.
If someone is closing a job (job close is called in the menu) it will impact the inventory wip report as it calculates on the fly the variance which will be posted when you run the report.
Assuming the report is wrong (and it might be), try this : go to gl transaction types, choose type inventory wip reconciliation , choose the active revision and mark it to manually review the transactions.
Because of this when you capture cos&wip, transaction will land in review journal. Do a BAQ with a review journal number as parameter and get yur data into Excel and check the total (there is also the option of printing a copy of the review journal but is super ugly).
If you cancel the review journal and run the capture again next day (with same parameters)and see the same number, this is your winner : if happy with it, post the journal, if not happy, cancel and investigate further.
Our finance person ususally runs the report so I am not as familiar with it. My findings are when running the report per steps on the PRB0320574 example(Run the inventory wip reconciliation report for unposted - start 07/01/2026 End 07/31/2026 Only unposted to the GL - Filter on trantype MFG-VAR Standard SSRS report - Print/preview) we also see the job#'s change each time the filtered report is run but the detail amounts, grand total and GL Recap accounts/amounts match exactly on each report. However, if I do NOT filter the report for trantype MFG-VAR and keep everything else/parameters the same, the job#'s match those on the 1st run/filtered report and they remain consistent each time the unfiltered report is run.
Hi Susan, thanks for your comment. Unfortunately, we DO NOT filter trans type for this report, so this unexpected issue remains critical, especially after Epicor Update and our month-end is approaching
Leah, Sorry to hear you are seeing the issue on unfiltered reports. We are seeing the issue on filtered reports only. Just ran two unfiltered reports again to CSV for side-by-side compare and they match. Hopefully Epicor resolves the PRB soon!
