first I need to understand what is exactly is wrong here.

I like to try these "WHY" questions. Forgive me if I get a bit pedantic here.

In binary formats, scientific numbers (SINGLE and DOUBLE) do great with integers up to a point. Counting numbers do great up to a point. That point occurs when you run out of bits to represent your numbers. At that point, either overflow or truncation will occur.

With that in mind, let's discuss the fraction 1/10 (or 0.1 if you prefer.) To represent this number you have to divide 10 into 1. The number 10 has factors of 2 and 5, so 1/10 = 1/2 * 1/5. On a binary machine, 1/2 is TRIVIAL. But 1/5 is not - because it is not an even number. Just like the numbers 1/3 and 1/7 are infinitely long when expressed in decimal, the number 1/10 is infinitely long when expressed in binary. Of course, 1/3 = 0.333333... representing an unending string of the digit "3" in that result. The value of 1/7 = 0.142856142856...., endlessly repeating that 6-digit sequence. And the BINARY fraction of 1/10 is 0.0001100110011001100... repeating the 1100 pattern infinitely.

Problem is, your binary machine doesn't have infinite capacity. So that fraction has to stop at either 23 bits (SINGLE) or 53 bits (DOUBLE). When you truncate that infinite fraction, you introduce a representation error. Now when you have those two apparently equal numbers and subtract the difference between them, they are different somewhere in the 7th decimal place of the number (based on the E-7). Your "913750000" is 9 digits. The 7th decimal place makes the entire number 16 digits long, which tells me you have a DOUBLE. I.E. allowing for scaling, your numbers differ in the 16th place, which is the limit for DOUBLE numbers.

You would ask, "why don't the numbers cancel each out?" Well, they almost do - but if there was ANY DIFFERENCE in the way the two numbers were defined or provided or computed, that fractional difference will show up in DOUBLE numbers way down in the 15th or 16th decimal place. The difference between two identical numbers entered in the identical way SHOULD balance to zero. However, I note that your query says that one of the numbers is a balance and the other is a balance sum. If they have even the smallest difference in computational source, that is where you got rounded off or truncated.

NOW back to practicality. The suggestion to switch to CURRENCY as a data type is probably going to work just fine because, as noted, it is a CAST (a.k.a. TYPECAST) of a really long integer. Integers don't truncate the same way that scientific numbers do. They would prevent the rounding error.

Hope that tells you enough to satisfy you as to why this happened.