Definitely. Saying no is not really denying, it's negotiating.
In the business user’s mind, negotiation means the developer can do X but the developer is lazy. Usually, it is requirement X doesn’t make any sense because a meeting was held where the business decided to pivot to a new direction and decided the new technical solution. The product owner simply gives out the new requirement without the context. If an architect or senior developer was involved in the meeting, they would have told the business you just trashed six months of development and we will now start over.
What you have to do is dig into the REASONS they want X or Y or Z (all of which are either expensive, impossible, or both) - then show them a way to get to their destination or close to it.
Sometimes. I have often had to say "no" because the customer request is genuinely impossible. Then comes the fun bit of explaining why the thing they want simply cannot exist, because often they'll try "But what if you just ... ?" – "No! It doesn't work that way, and here's why..."
I had to explain recently that `a * x !== b * x when a !== b`*... it is infuriating hearing "but the result is the same in this other competitor" coupled with the "maybe the problem here is you're not knowledgeable enough to understand".
We've definitely had our fair share of "IDK what to tell you, those guys are mathing wrong".
TBF, though, most customers are pretty tolerant of explainable differences in computed values. There's a bunch of "meh, close enough" in finance. We usually only run into the problem when someone (IMO) is looking for a reason not to buy our software. "It's not a perfect match, no way we can use this" sort of thing.
At this particular job I used the plus, the star (multiplication) and once I even got to use the minus.
There's a legend going around that a friend of mine has used division, but he has a PhD.