[nyrikki]

You are correct, the problem is that Decimal64 has 16 digits of significand, while items like apportioned per call taxes need to be calculated with six digits past the decimal before rounding which requires about 20 digits.

Other calculations like interest rates take even more and cobol requires 32 digits.

As decimal128 format supports 34 decimal digits of significand, and has emulated exact rounding, it can meet that standard.

While items is more complex, requiring ~15-20% more silicon space in the ALU plus larger dataset size, compared to arbitrary precision libraries like BigNum it is more efficient for business applications.

This looks like a digestible cite:

https://speleotrove.com/decimal/decifaq1.html