We're reviewing a code change that one of our users has returned to us, claiming that they've found a bug in the code, where the total of some numbers doesn't add up correctly on a legal form. At first I was unable to reproduce the problem, which I told the user so that they were aware of the progress(in hindsight, telling them I could not reproduce the problem before knowing why may have been short-sighted, but I wanted feedback from them).
After reviewing it further, I've found a discrepancy in how the user put together their failure example. The order in which they are added up is based not on the order in which they're entered, but on the date they were received, which the user puts in when they enter the data. This means that the way the user put the data together, not a bug in the application, led to the discrepancy they saw, and I found that this is the way the application has always worked.
Now I am in a bit of a bind - it is important that the application remain consistent, and I need to tell the user about this discrepancy without offending them. They aren't known for being aggressive or getting highly upset, but I don't want them to base their decision off of being defensive about the test case they made being 'correct'.
How can I bring this up to the user without offending them? The users own this application, so for better or worse what they say goes, goes. I can show them the logic behind how this 'error' appears, and why it is programmatically correct, and I really do think it is also legally correct (and my co-workers agree), but if they decide we need to 'fix' it, we won't be able to stop them, so I would much rather talk them down the right path without being confrontational.
Just to be clear on how much power this user has:
In our specific case, the user is one of two heads of the department that uses this application, and specifically in charge of the part that this change is part of - essentially he is the biggest "stakeholder" in this part of our application