One thing you can do is try to shorten your rejection cycle. It's not clear from your question where the problems occur. But, for a specific example, Jakob Nielsen (https://www.nngroup.com/) [disclaimer: no relation, no benefit accrues to me] has published a newsletter for more than 10 years about user experience testing and UX design. He offers specific advice on how to prototype user interfaces, and how to do UX testing "on the cheap."
It might be the case that sitting down with someone from the user side and going through a prototype that is mocked up with a paper document and some cut out paper buttons and menus could save you considerable design/rework effort.
There are similar modeling options in other aspects of your software. For example, if your problems spring from accounting issues, maybe a primitive model built in a spreadsheet could make things go more smoothly. ("Oh, we have to apply sales tax? Okay, let's add that in at line 22.")
Honestly, it sounds like you guys are doing things slightly wrong, because it shouldn't be possible to get to the situation you describe. If your system owner is laying down requirements, you need to back them off and work more on user stories. If there's a user story, and someone tries to change it, THEN you challenge them: how could this user story have changed? Is this really a change to the user story, or is this a new user story with a slightly different circumstance?
I can imagine something like logging or auditing showing up late, where you spoke to the end users, got their stories straight, and didn't realize that every order entered required an audit entry. But invisible requirements are invisible. They won't change the user story, so it shouldn't be too hard to add those features.