Не может быть чтоб одна и та же зона принимала разные значения, а вот на первый взгляд две одинаковых - могут - это следствие неточности черчения, настроек - ну хоть учёт подоконных ниш, мало ли какие галки включены. Ну либо какой-то глюк в Архикаде.
Погрешность связанная с округлением есть всегда, в любых действиях сложения_вычитания. Другое дело что её можно несколько минимизировать сделав предварительное округление, ещё до того как данные попали в каталог. Есть несколько видов округления, в Архикаде применяется математический метод =первые пять - 0,1,2,3,4 - округляется до 0. Всё что больше 5 включая и 5, а именно 5,6,7,8,9 округляется до 1 и добавляется эта единичка к предыдущему разряду.
Любая дробная часть округляется, если у вас по умолчанию в Архикаде настроено в диалогах 3 знака, можно забить и 5 и 6 и 7, но эти знаки тут же будут округлены до 3 знаков. В любом диалоге, хоть в библах, хоть в настройках материалов, хоть в настройке штриховки.
Если у вас не стандартный параметр площади зоны - смотрим диалог рабочих единиц - столько знаков и будет в каталоге. Далее - в настройках расчётов и настройках размеров - это для того если вы выводите стандартные параметры зон - напр. ROOM_AREA или ROOM_CALC_AREA. Теперь сколько знаков у вас назначено в самой зоне, ну либо она может брать из настроек площадей рабочей среды, либо в скрипте жестко прописано число знаков, либо как у меня - имеет собственные настройки.
Посложнее со сметами - там всё в скрипте пишется. Ещё одно возможное место проблемы - если данные меняются через Add-on. Вот там может сидеть не округление, а отбрасывание не нужных знаков, а в каталоге будет считаться через округление. В GDL есть только округление. А вот в C++ на котором пишутся ADD_ON_ы ещё есть и отбрасывание. В итоге можно получить разные цифири для одной и той же дробной части, и проблема с пограничными значениями может вылазить в адд-оне. Напр 0,5 - не всегда четко округляется. Собственно это сродни вопросу чистый НОЛЬ это положительное или отрицательное число, ответа нет. То ли надо перед этим нолём знак минус ставить, то ли нет. 0,5 и прочие 5_рки п. зап. так же вызывают недоумение у add-on_a, вот поэтому и делается предварительное округление.
Мест откуда прилетит нежданчик - море. Но главное чтоб и в расчётах и на плане было одинаковое ко-во знаков. И желательно делать предварительное округление внутри скрипта того числа которое будет выводиться в расчётах.