с деньгами работать через double - дурдом.
15 знаков десятичных дает мантисса и все.
быстро нарветесь на ошибки округления, потерю точности и т.п.
см. BigDecimal со всеми вытекающими.
Decimal Arithmetic FAQ

авторА если double, то он что-то странное творит вместо допустим 345,56 пишет
345,5556767

А вот это странно.
ну когда в 15м знаке врет - это естественно эффект от binary float point.
но чтоб вот так вот...
примерчик есть?

Потеря точности из-за невозможности точного представления десятичного числа средствами двоичной арифметики с плавающей точкой.
(так же как невозможно точно представить 1/3 в десятичной системе)
см. из приведенного FAQ второй вопрос - пример с 70 центовым звонком и 5%налогом.
В готовой системе крайне неприятно отлавливать подобные ошибки когда они проявляются в виде несошедшегося на несколько центов консолидированного баланса - объем исходной информации при этом может быть сотни тысяч записей.

Нехватка разрядности - скромную сумму в 10млн. евро не удастся представить в турецких лирах с точностью до второго знака после запятой.

Вообще-то этим граблям уже лет 50 как минимум ;-)
COBOL и PL/I могли работать с настоящими десятичными числами произвольной разрядности natively.
В первых версиях COBOL вообще не было арифметики с плавающей точкой (зачем она бухгалтерам?).
И IBM производил когда-то процессоры которые способны были считать в том числе и в десятичной системе без преобразования в binary floating point.
( думаю и сейчас производит - они никогда ничего не выбрасывают ;-)
Так что в некотором смысле с тех пор железо деградировало.
По крайней мере в нынешних Intel-ах подобные вычисления если и делаются то "не в железе", а "софтверно".

mayton-Можно использовать встроенный тип int или long и считать все в копейках. А при выводе
форматировать с учетом двух дробных знаков.

Не поможет. если я торгую спичками по 1коп. и должен с них платить налог 18%, то рано или поздно вылезут "лишние" копейки.
Надо иметь резерв в несколько разрядов чтоб с округлением не было проблем.