That’s funny. In my programming classes I recall they were telling us these kind of problems happen all the time with businesses because they will choose a number type of “double” or “float” for currency fields and then when you do calculations (multiplication, etc) it doesn’t calculate exactly the way you expect it to, because technically speaking the double or float number isn’t kept to a precise value as intended, but they are stored as an exponent plus a fraction and is thus stored with as many bits as the computer has left after the storing the exponent, so the precision degrades more the larger the number becomes.
As an example, $160.01 isn’t stored as 160.0 1, it’s stored as the fraction 1.600999999999999996 with an exponent of 1*10^2. So as you multiply this value, it technically calculates incorrectly the larger it gets. I am having this same problem with a payroll system I manage because the devs encoded things using double or float designations and so everything is calculated screwy.
I believe that is the same thing happening here. For the most part it will ultimately round off to a correct number, or nearly correct…but it means someone didn’t set it all up correctly to be precise. Most databases will include an explicit money type to correct these issues and make sure it all calculates correctly,…but it apparently was used here. You’ll see this kind of thing happen a lot if you pay close attention. By default it can be difficult to make it precise since currency isn’t one of the default options with most basic programming.