Yes, Math::BigFloat probably does it right. But it may be quite slow.

When dealing with monetary value having typically 2 decimal places, many (most ?) business databases actually store monetary values as integers with a scale factor of two (in other words, they store internally monetary amounts in cents instead of dollars or euros and perform the necessary conversions when needed). I guess this is deemed to be more accurate and probably faster. For tariffs related with usually small amounts (such as rating telephone calls), I have seen price rates actually stored internally as integers in 1/10,000 of a euro. But anytime the database engine reads from the database or writes to it, the scaling factor is applied. Most people using the database or even developing for it don't ever get to see this, as this is buried deep in the very low levels of the database software.