Storing, calculating, and working with Currency data types seems like one of the few things that still provides a mixed bag of emotion. in C#, on the one hand you have the decimal data type, but on the other, you have pretty much no functions which actually accept a decimal data type or return one.

As it is the most suitable, the decimal data type is largely recommended for financial calculations.This makes the most sense. And while, as mentioned, there are many functions and calls you might need to make which will result in casts back and forth from  other data types like double or even float, if you design your software and data from the ground up to deal with it you can usually accommodate these issues.

The problems arise, as usual, when we start looking at existing systems. For example, your old product might be working reasonably well with only a few problems for a customer, and they have loads of data. They aren’t going to be as likely to hop aboard your new system if it means that they will have to re-enter a load of data, and they aren’t going to like seeing errors from their current data appear in the new system. It was working before, after all. These old systems might be using ISAM databases and may have used floating point internally for calculations; even if it doesn’t use it’s own math routines you’ve got to consider that whatever programming environment was used for the old software might not follow the same mathematical rules as the new system, and so you have to decide how to proceed. Something as simple as a rounding function dealing with a corner case differently could result in massive amounts of manual data entry for either the customer or even yourself. On the other hand, using floating point types and writing wrappers to mimic the fiobles of the old functions is effectively building technical debt into the product. The compromise solution- have some sort of configuration which will either set it to use floating point compatibility mode or for the product to use decimal native mode would involve a lot of ground-up architecture to  implement. Database schemas will differ, and you can’t just willy-nilly swap the option either

It’s the sort of problem that doesn’t seem to get covered in Academia on the subject, but it comes up often and each decision must be made carefully, in order to avoid alienating customer bases while attempting to avoid unnecessary technical debt. particularly since technical debt is why new systems might be implemented to begin with- bringing forward technical debt from the replaced system sort of defeats the purpose.