Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

There is a natural tendency to fight against change. You’ve worked so hard to build things a certain way. You invested many hours in requirements gathering, analysis, architecture, and development. You are confident that you have implemented (or are well on your way) this feature exactly the way the business needs it.
That doesn’t matter.
When the business needs change, the development team needs to respond with an appropriate shift in strategy. Priorities change. Details change. Requirements change. If you don’t embrace these changes, you will no longer be building valuable software.
You can’t deliver valuable software if those values have changed.
The whole point of an agile approach is to be able to rapidly respond to change. In a slow waterfall approach, a change in requirements would call for extensive contract renegotiations. It could be months before the development team gets back in alignment with where the business needs them to be.
Furthermore, a company that can rapidly respond to changes in business needs will have a competitive advantage over companies that do not. Compare a company that releases daily against one that releases only twice a year. The faster company could have very important features for several months before the competition can react.