Our Finance team have noticed an issue with a part when it ships that the unit costs are different. I originally thought as it was Lot FiFo costing it was because of that but the transactions of materials and shipments would suggest otherwise. He has just had a call with an Epicor Financial consultant who has suggested to raise a support call but i thought i would ask here to see if someone had seen something similar
These are all MFG-CUS shipments… so, shipping from the job. I’m assuming this is one job where you’re shipping in small releases? Are all the parts going through each operation together… or are you completing a couple through all operations, shipping them, then going back and completing a couple more, shipping them, going back, completing more, etc.?
I know if we ship parts from a job, the system will take the then-current job cost and divide it by the quantity taken off the job (shipped, received to inventory, transferred?).
I could be way off base… but to me this looks like:
On 8/9/2026, you shipped (2) from the job… at that time… it took ALL the accumulated job cost (potentially raw materials for 24 parts, operations so far for 24 parts, burden so far for making 24 parts) and divided the accumulated cost (possibly the 26,121.38 value) divided it by (2) and that was your first unit cost of 13,060.69.
You then shipped (4) more (on the same day?)… at this point, there was NO COST LEFT ON THE JOB… so those parts shipped at 0.00 unit cost.
You then kept working to complete additional parts (adding labor and burden to the job cost) and on 14/9/2026 you shipped (1)… accumulated cost on that date was 4,353.72… so that was the unit cost for that one.
You kept working to complete additional parts and on 17/9/2026 you shipped (10). But… again, the same pattern… you shipped (5) which got all the accumulated cost to that point which was divided by the (5) parts… but then you shipped another (5) and again, with no cost left on the job, the 2nd set of (5) saw 0.00 unit cost.
You then kept working to complete the last (5) parts and on 24/9/2026 you shipped the last (5) and they inherited the 21,767.89 accumulated on the job at that point.
That’s my best reverse-diagnostic attempt.
If this makes sense and this is what’s going on… you could investigate using “Split Jobs”. This is the route we started taking when things like this happened.
Scenario: We have a stock job to produce (6) parts. Typically, these all go through all the operations together and then we receive all (6) parts into inventory. The job cost is split (6) ways and the unit cost makes sense.
But, while running these (6), we get a customer order for (2). We’ve learned, in order to keep the unit costs correct… we should finish all (6), receive them to inventory, then ship (2) to the customer…OR… we could rush and finish (2) through all remaining operations and ship them… then go back and finish the remaining (4). BUT, this is when our unit costs see exactly what you (I think) were showing.
We found using Split Jobs can get around this situation.
Basically, we “split” a qty of (2) off of the stock job onto their own job. When you perform the job Split, it looks at the different cost components and moves a portion of the cost(s) to the new job:
Material… we had already issued materials for (6) parts.
Labor/Burden… we had already completed (6) parts through the first few operations.
etc.
So, it will take the Material costs and divide by (6)… it will then pass 2/6 of the material cost to the new job.
For Labor/Burden (this is crucial) it evaluates the production quantity of each operation independently.
So, if, for example your operators don’t report ANY quantity complete for Op 10… NO LABOR/BURDEN COSTS will transfer to the new job for that operation.
If you completed (6) on Op 20… 2/6 ths of that operation’s labor/burden will transfer.
If you only completed (5) on Op 30… 2/5 ths of that operation’s labor/burden will transfer.
So… it is critical to be accurate on the quantity completed for each operation! When we want to perform a job split, BEFORE performing the split, our Production Manager(s) will review quantities on each operation and even add LaborDtl records (with 0 hrs, but completed production qty) to correct the quantities and make sure each are accurate. This ensures all the proper costs get transferred.
I even had an operation (during a test run) where the operators over-reported. The job was for (6) but they reported a Production Qty of (7) on Op 40. Well, for Op 40, 2/7 ths of the operation cost got transferred. Was confusing at the time, but that’s what helped us verify that it is not JOB quantity that drives the process… its the quantity completed on each operation. Costs are evaluated at the operation level and transferred to the new job.
Anyway… we then complete the (2) on the Split Job and we ship that to the customer. Unit Costs are calculated correctly.
We then go back to work on the original job, which is now for a quantity of (4)… and we can complete that job and receive those parts to Stock.
As usual David your explanations are brilliantly written with a real-world grounding that makes it easy to understand thank you so much.
We have had issues using Job split in the past and have since been reluctant to use it reading you post has made me realise why. For us it is twofold one the Production quantity for the OPS would definitely have been inaccurate and two our thought process on how it works we were coming from the position that we are leaving the finished items on the Job ie 2 and the new job would be the remaining cost and work to be done but it should be the other way round 