Thanks for the responses. I found the issue when testing real code to calculate a quota of free jobs based on 5% of jobs (rounded down) and posed it as a slightly provocative question. Anyone who got the right answer should have two points deducted for either cheating (running the script or a similar one) or guessing!
For the record, a rewording of the required algorithm is 'give one free for every 'whole lot' of 20 they have'.
We all think we know about the perils of inexact values, but rarely does it show itself so weirdly, especially that 20 * 1.05 doesn't round down but 100 * 1.05 does.
Some have commented that @Quota should be not an integer, but this doesn't make sense when my answer is to be an integer.
Some suggest using Round, but the algorithm is required to always round down, so @Value=99 should give 4 free and a total of 103 (whereas e.g. Hugo's and Tom's versions using Round gives 104). And even with 'normal' rounding to the nearest integer, one could imagine a calculation generating say 2.4999999 and rounding down rather than up as expected.
When I was researching the answer I did browse some articles on IEEE floating point definitions, and got somewhere down page two before my eyes glazed over. Perhaps it would be fixed by an improved floating point specification. I'd have to say the results I got are counter-intuitive and in an ideal world, it shouldn't happen.
In the meanwhile, I have re-coded it to to follow the reworded algorithm, i.e. set @Quota3 = (@value / 20) + @Value. Where such a solution is not possible then I'll stick with the ugly solution of adding a tiny fraction, and I'll keep a much more careful eye out in future when rounding.