Cycle Count & Backflush Materials


I am trialing cycle counting using ABC codes and whilst it seems to work well for most materials. I was wondering what solutions other people have come up with for backflush materials.

For example, you have a part that it included in the cycle count that has an on hand quantity of 30 on Epicor, however, physically, there are only 20 as 10 have been issued to an operation, but not taken from the on hand quantity as they will be backflushed when the operation completes.

The person performing the count enters the count of 10 against the tag which generates an adjustment of -20.

However, the operation completes and takes 10 out of stock, bringing the the on hand quantity to 20, plus the negative adjustment of -20, will make the on hand quantity zero, when it should be 10.

At the moment I am going to issue a work instruction that tells the counter to manually check for backflush operations.

However, I was wondering whether I had missed something within the cycle count mechanism?



Hello Andrew,

You’re spot on. You need to have a good procedure here. I don’t see how Epicor can “know” what has not been recorded yet. We cycle count daily and our first rule is that all transactions are complete before the cycle count. If we find a discrepancy, we first look for unposted transaction then alter our count to include the quantity so when the transaction completes, the count is correct.

Mark W.

1 Like

You need to know what job operations are running that affect that part and factor this in.

A baq/dashboard can do this. Enter a material part number and show the open job operations related.


1 Like

Thanks all - very useful feedback