Yes, you can handle a lot of the monetary issues with scaled integers. But things still get complicated. You need to decide ahead of time what your exact scale factor will be, and woe to you if you get it wrong. For example, what resolution do you store unit prices in? I will tell you as a fact that I have bought parts where the unit price for some of the parts had significant digits in the 1000ths of a cent. (Yes, you had to order at least a 1000 of them to get that price, but you didn't need to buy them in multiples of 1000, they did apply rounding to the penny to the net price of the part after multiplying by quantity). Also, since you end up with numbers for intermediary results needing to be rounded off to different number of fractional digits, it does become a lot of work to track this down. And, since the numbers types themselves don't track this scale information, there is lots of need for checking and double-checking and then some law changes and you need to add a digit of precision and everything needs to be checked again, and all uses traced down, and if that value was saved in a database, that means checking EVERY program in the system to see if it uses it. This is why COBOL and similar languages had fixed-point types with declared precision, so IT could handle all that mess. Decimal types that can exactly represent the values you want to exactly represent don't get rid of all the problems, but they do clean up a lot of them and leave to you the real problems to solve.