When a new transaction is posted, the MEM benefit Expiration Date is not advanced a year from the Expiration Date on the previous MEM benefit.
This can happen if the most recent MEM benefit was not the active one.
This can also happen if you adjust an older transaction with a MEM benefit and have the benefits on it recalculated. That will insert a new MEM benefit in the batch for it, which when posted, will reactivate the existing MEM benefit that had been superseded by the most recent MEM benefit, but maintain it's current Expiration Date, which would be a year earlier. So when a new transaction is posted with a MEM benefit, it is basing its new Expiration Date off of an older MEM benefit, setting it a year after that instead of a year after the newer MEM benefit.
For example, you have a transaction on 1/15/2015 that had a MEM benefit Expiration Date of 4/30/2016, then another transaction was posted on 2/18/15 with a MEM benefit, which supersedes the old MEM benefit, and has an Expiration Date of 4/30/17. Then you adjust the older 1/15/2015 transaction and tell it to recalculate benefits. When you adjust transactions, it will only pull into batch any benefits that are active - since the MEM benefit was superseded (sts 'S') it would not be pulled into batch. But when you recalculate benefits on it, it can award a MEM benefit to it again, which then gets used to reactivate the Sts 'S' MEM benefit it already had, so now MEM benefit with expiration date 4/30/16 is active again, which also sets MEM benefit with Expiration Date 4/30/17 to sts 'S'. So when a new transaction comes in with a MEM benefit, it is setting the Expiration Date to a year after the active MEM benefit's Expiration Date, which is 4/30/16, so it gets set to 4/30/17.
The solution is to not recalculate benefits when adjusting older transactions.
Another solution, in one case, was for the client to adjust the affected benefits and turn them from Status "S" to Active.