Недостатки банковского способа округления

НИ О ЧЕМ. И ОБО ВСЕМ

• Раздел:Своими руками
• Метки: Разработка
• Просмотров: 20031
• Подписаться на комментарии поRSS

Пару месяцев назад нужно было написать на php небольшой скрипт, который должен был подсчитывать большое количество финансовых данных — брать от сумм банковских переводов процент и подсчитывать сумму. При вычислении процентов появлялись суммы с десяти- и стотысячными долями значений, которые при последующем суммировании и округлении давали весьма интересные эффекты. Например, скрипт генерировал отчет, в котором суммы исходные и рассчитанные различались на 10-20 копеек. Начал разбираться с этим, и открыл для себя новый тип окрулегия — банковское округление.

Сначала я пошел неправильным путем — начал прогонять рассчитанные проценты через функцию round. Но это не помогло. Все равно были расхождения на копейки. Пришлось засесть за чтение теории, и всего через 10 минут выяснилось, что для борьбы с такими эффектами применяется метод «бухгалтерского округления», или за рубежом — «bank rounding».

Способ простой — если тысячные доли рубля равны 5, то смотрится цифра перед ней (единицы копеек). Если она четная, то тысячные просто отбрасываются, а если нечетная — то копейки округляются вверх. То есть по сравнению с математическим округлением разница такая (это тестовый массив чисел, подсчитанных руками).

4.565335, // bank: 4.56, math: 4.57
34.565783, // bank: 34.56, math: 34.57
56.355532, // bank: 56.36, math: 56.36
9.4557642, // bank: 9.45, math: 9.45
10.345643, // bank: 10.34, math: 10.35
7.235345, // bank: 7.24, math: 7.24
9.285456, // bank: 9.28, math: 9.29
3.225, // bank: 3.22, math: 3.23
10.25527, // bank: 10.26, math: 10.26
11.41525, // bank: 11.42, math: 11.42
0.105, // bank: 0.10, math: 0.11
0.115, // bank: 0.12, math 0.12

На самом деле, такой подход не снимает проблему округления полностью, а только значительно сокращает вероятность накопления ошибки за счет того, что количество «четных» и «нечетных» сумм статистически примерно одинаково. Но на практике такой точности вполне достаточно. После использования этой функции, по крайней мере видимые расхождения в скрипте прекратились.

Осталось только найти реализацию этой функции в Интернете, и дело сделано. Конечно, алгоритм простейший, но всегда лучше полагаться на чей-то успешный опыт. А вот тут и ждал меня мега облом. Я не нашел реализацию этой функции для PHP! Вернее, нашел одну на StackOverflow, но она работала через преобразование в строку и выделение функцией substr десятых долей суммы. Для друих языков находил реализации через логарифмы.

Меня это не устроило, поэтому написал за минуту свою функцию. Пояснять ее смысла нет, она «прозрачна».

function bank_round ($val)
<
$tmp = intval (abs ($val) * 100);
if ($tmp % 2 != 0) $tmp +=1;
if ($val Поделиться заметкой

Источник

Округлить сумму НДС в счете‑фактуре, декларации

Округление — замена числа на его приближённое значение (с определённой точностью), записанное с меньшим количеством значащих цифр. Модуль разности между заменяемым и заменяющим числом называется ошибкой округления.

Округление применяется для представления значений и результатов вычислений с тем количеством знаков, которое соответствует реальной точности измерений или вычислений, либо той точности, которая требуется в конкретном приложении. Округление в ручных расчётах также может использоваться для упрощения вычислений в тех случаях, когда погрешность, вносимая за счёт ошибки округления, не выходит за границы допустимой погрешности расчёта.

В бухучете применяют Округление к ближайшему целому — наиболее часто используемое округление, при котором число округляется до целого, модуль разности с которым у этого числа минимален. В общем случае, когда число в десятичной системе округляют до N-го знака, правило может быть сформулировано следующим образом:

Правила округление сумм в бухгалтерских документах, декларациях, счетах-фактурах

Правило об округлении суммы налога до полных рублей, изложенное в пункте 6 статьи 52 НК РФ, применяется только при заполнении налоговых деклараций.

Всем известно, что даже имея маленькие суммы расхождения между начисленными и уплаченными налогами или страховыми взносами могут стать поводом для проверяющих потребовать заплатить недоимку.

Налоги можно платить в рублях, используя общие правила округления, а вот страховые взносы уплачиваются и начисляются — в рублях и копейках. В первичных документах суммы можно округлять, а в счетах-фактурах — нет .

Для бухгалтерской отчетности существую свои правила. Поэтому из-за всего этого многообразия можно случайно неверно округлить сумму платежа. А это приведет к задолженности перед бюджетом. Вроде бы всего-то копейки, но, как показывает практика, лучше таких ситуаций избегать, потому что:

1. Проверяющие часто выставляют требования даже на копеечные суммы.
2. Мизерная недоимка может помешать получить справку об отсутствии долгов перед бюджетом.

Как правильно округлять суммы в документах, платежках, декларациях, счет-фактура

Соответственно, в декларации по НДС сумму налога следует указать в полных рублях. А в счетах-фактурах и в книге продаж эту сумму нужно отразить в рублях и копейках без округления. Такое мнение высказал Минфин в письме от 15.10.19 № 02-07-10/79001.

В первичных документах и счетах-фактурах — с копейками.

В первичных документах допускается округление показателей до целых рублей. Бухгалтеры в компаниях вправе вести бухгалтерский учет хозяйственных операций на основе плана счетов, имущества без учета копеек (п. 25 Положения, утв. приказом Минфина России от 29 июля 1998 г. № 34н).

В то же время округлять показатели до целых рублей в счетах-фактурах не допускается. Их заполняют в рублях и копейках (письмо Минфина России от 29 января 2014 г. № 03-02-07/1/3444). При этом разница между суммой налога в декларации по НДС и суммой налога, указанной за соответствующий налоговый период в книге продаж, недоимкой не признается.

Если вы округлите цены и стоимость в счетах-фактурах, то налоговики могут отказать вашему покупателю в вычете НДС. И хотя компаниям удавалось раньше оспорить такие решения налоговых инспекторов, лучше изначально не округлять суммы в документах до целых рублей.

Округлять ли пени по налогам и как

Пени по налогам исчисляют из 1/300 ставки рефинансирования. Она в настоящее время (конец 2017 г.) равна 7,75 процента. То есть размер ежедневных пеней составляет 0,0275 процента (8,25: 300).

Округлять дневную ставку пеней до двух знаков после запятой, то есть до 0,03 процента, не надо. Ведь из Налогового кодекса РФ не следует, что ежедневную сумму пеней надо округлять. А все неясности толкуют в пользу компаний. Поэтому выгоднее применять дневную ставку, в которой четыре знака после запятой — 0,0275. Так сумма пеней у компании будет меньше. И только их общую сумму за все дни просрочки можно округлить до двух знаков после запятой (определение ВАС РФ от 22 октября 2009 г. № ВАС-13685/09). Такой вариант не спровоцирует споров с проверяющими. Именно такой расчет приводят налоговики в приказе ФНС от 18 января 2012 г. № ЯК-7-1/9@.

Если в счетах-фактурах вы будете указывать стоимостные показатели с копейками, а в первичке в целых рублях, у компании возникнут разницы. Из-за этого налоговые инспекторы наверняка откажут вашему покупателю в вычете входного НДС. Поэтому во всех документах показатели лучше отражать с копейками. Тем более бухгалтерские программы обычно автоматически округляют данные в первичных документах и счетах-фактурах до двух знаков после запятой. Однако у контрагентов могут возникнуть сомнения, правильно ли сделано округление. Предположим, ваш покупатель рассчитал сумму аванса в размере 125 026,55 руб., а вы выставили ему счет на предоплату в сумме 125 026,52 руб.

Если контрагенты обращаются с такими требованиями регулярно, то имеет смысл прописать в учетной политике, как программа делает округления. А выписку из учетной политики представлять контрагентам (образец — см. ниже). Это избавит вас от частых исправлений первички.

В декларациях и платежках по налогам — денежные суммы указываются в целых рублях

Абсолютно все налоги необходимо перечислять в полных рублях (п. 6 ст. 52 НК РФ). В налоговых декларациях суммы также округляют до целых рублей по правилам математики. Причем в форме любой декларации вы можете увидеть, что округляют не только итоговые данные, но и промежуточные цифры на каждом листе. Поэтому ту сумму налога, которую бухгалтер отразит в декларации, он укажет также в платежном поручении. Никаких расхождений не будет.

Исключение — ситуация с НДС. Платеж по этому налогу компании разбивают на три равные части и перечисляют их в течение следующего квартала. Чаще всего сумма НДС поровну на 3 не делится. В связи с этим платеж в одном из месяцев будет отличаться на рубль от платежей в двух других месяцах. Причем компания вправе в первом и втором месяце перечислить поменьше, а в третьем — побольше. Это мнение высказали в ФНС России в письме от 15 января 2009 г. № ВЕ-22-3/16@. Разъяснение доведено до сведения налоговых инспекторов.

В отчетности и платежках по взносам — указываются суммы с копейками

Страховые взносы нужно платить в рублях и копейках (п. 5 ст. 431 НК РФ). Но если в налоговых декларациях суммы округляют, то в отчетности по страховым взносам нет. Показатели в формах РСВ ПФР и 4 ФСС указывают в рублях и копейках. Поэтому между данными в отчетности и в платежках могут возникнуть небольшие расхождения.
Проблема в том, что эти небольшие расхождения часто становятся поводом для споров с проверяющими. Например, когда специалисты фондов требуют уплатить недоимку в размере нескольких копеек. В прошлом году специалисты Минтруда России выпустили разъяснение о том, что такие доначисления неправомерны (письмо от 14 февраля 2013 г. № 17–4/264). Но данное разъяснение не доведено до сведения региональных отделений фондов. Поэтому не исключено, что вы столкнетесь с такими требованиями. Кроме того, недоимка будет числиться в акте совместной сверки с фондом.

Еще одна проблема — страховые взносы платят ежемесячно не позднее 15-го числа следующего месяца. А отчеты сдают раз в квартал. И если при приемке расчетов проверяющие заметят, что в отчетности отражены не те суммы, которые были в платежках, документы могут не принять. Чтобы не было таких проблем, советуем перечислять страховые взносы в рублях и копейках.

Какие показатели можно округлять, а какие нет

Показатели	Правила округления
Выплаты сотрудникам	Все выплаты сотрудникам надо начислять с копейками.
Лимит Кассы	Лимит наличности в кассе можно округлить до целых рублей по правилам математики. Это подтвердили чиновники (письмо ФНС России от 6 марта 2014 г. № ЕД-4-2/4116@). А кассовую первичку, например кассовые расходники, заполняйте с копейками
Коэффициент в декларации по транспортному налогу	Коэффициент владения транспортным средством в отчетном периоде (строка 120 раздела 2) приведите с четырьмя знаками после запятой. Этот коэффициент надо указывать, если компания являлась собственником машины не весь период
Коэффициенты в декларации по ЕНВД	Коэффициент К1 округлять не нужно. В 2014 году К1 — 1,672 (строка 080 раздела 2 декларации по ЕНВД). Коэффициент К2 ЕНВД округляют до трех знаков после запятой, его утверждают местные власти (строка 090 раздела 2)

1. Показатели в счетах-фактурах округлять до целых рублей нельзя . А в первичке можно, но нежелательно.
2. Расчеты по страховым взносам заполняют с копейками , а налоговые декларации — в целых рублях .

ИСПОЛЬЗУЕМАЯ ЛИТЕРАТУРА и ДОПОЛНИТЕЛЬНЫЕ ССЫЛКИ

1. КАК СДАТЬ налоговую отчетность
   Законодательством РФ предусмотрены два способа сдачи налоговых деклараций (расчетов).

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

Источник

Загадки округления

Автор: Алексей Михайличенко, Королевство Delphi

Эта статья задумывалась как краткий ответ на вопрос N 40789, где обсуждались ошибки в функциях округления. Как сказал автор, «мне все равно что «бухгалтерское», что «арифметическое» — главное чтоб считало также как в Excel’е». Другими словами, возникла необходимость прояснить, чем отличается бухгалтерское округление от арифметического, какое из них реализовано в Excel’e — этом «гении чистой красоты», и почему некоторые Delphi-функции странным образом работают иначе.

Стоило копнуть эту тему поглубже, и новости повалили как из сказочного горшочка с кашей. Не претендуя на академическое раскрытие темы, поделюсь материалом, имеющимся на данный момент. Предлагаю следующий план:

1. Очень кратко вспомним, почему вычисления на компьютере могут давать неожиданные результаты. Приведем некоторые ссылки.
2. Подумаем, как можно с этим бороться. Для этого рассмотрим правила приближенных вычислений.
3. Перейдем собственно к правилам округления. Особое внимание уделим так называемому «банковскому», или «бухгалтерскому» округлению, и покажем, зачем оно нужно, и какие еще способы округления существуют.
4. Рассмотрим функции округления различных языков программирования, как встроенные, так и самописные. Покажем на примерах, что большинство из них, в том числе и встроенные функции Delphi, работает с ошибками. Укажем на правильную реализацию таких функций.
5. В большом приложении к статье приведем полные результаты пятидесяти тестов функций округления разных языков, как встроенных, так и найденных на Круглом столе этого сайта, чтобы каждый мог, найдя в этом списке свою любимую функцию, увидеть, на каких значениях она, возможно, подвирает.

Итак, все мы в свое время обнаруживали, (а если нет — то вас еще ждет это волнующее открытие), что 0.1 в компьютере не равно 0.1. Читали статью «Неочевидные особенности вещественных чисел» Антона Григорьева, ужасались результатам сравнения и вычитания extended, погружались в дебри внутреннего представления чисел с плавающей запятой и размышляли о бесконечных цифровых хвостах. Интересующимся этой кухней порекомендуем классику — Дональд Кнут: «Искусство программирования», том 2, Глава 4. «Арифметика», где увлекательнейше описана история позиционных систем счисления, и в общем виде рассмотрены алгоритмы арифметики с плавающей запятой. Удачно дополняет ее статья Дэвида Голдберга «Что должен знать каждый ученый-компьютерщик о об арифметике с плавающей запятой». В ней приводятся некоторые теоремы, позволяющие оценить величину ошибок, возникающих в машинной арифметике, рассматриваются соответствующие IEEE-стандарты, и вопросы их реализации.

Возвращаясь из этих научных миров в реальную жизнь, приходится сделать неутешительный вывод: по сравнению со школьным курсом арифметики компьютеры считают неточно. Эта мысль достаточно тяжело укладывается в голове. Действительно, с первых уроков математики нам показывали рулетки, линейки, штангенциркули и микрометры, и говорили о том, что все измерения имеют погрешность. Демонстрировали картинки с оптическими обманами и говорили о несовершенстве органов чувств. И в противовес этому превозносили саму математику, ее арифметические действия, как символ незыблемой правильности. Ведь еще Пифагор понял, что числа существуют независимо от нашего сознания, и логические рассуждения над ними переживут века. В народе это отразилось в поговорке «как дважды два — четыре» — то есть заведомо верно.

Чтобы снять с компьютера незаслуженный ореол научной святости, представим себе, что это всего лишь один из школьных измерительных приборов, со своими ограничениями и некоторым классом точности. А внутри него происходит вот что. Например, пусть нам нужно сложить два числа: 10 и 20. Берется школьная линейка и огурец. Отрезается от огурца два кусочка: 10 и 20 мм длиной, складывается вдоль, и этой же кривоватой линейкой измеряется длина результата. Получаем ответ с некоторой погрешностью. Именно с такой степенью доверия нам придется относиться к результатам компьютерных вычислений с плавающей запятой.

Иногда приходится слышать, будто компьютеры считают приближенно. Но это совершенно не так. Для обсуждения этого вопроса срочно определимся с терминами.

Приближенные вычисления — давний и почтенный раздел математики. Он дает набор неких практических правил по обработке данных, полученных нашими несовершенными измерительными и вычислительными приборами. Именно следуя этим правилам, наша цивилизация вершила настоящие чудеса — строила храмы и мосты, предсказывала затмения, летала на фанерных аэропланах и керосиновых ракетах и стреляла из пушек за горизонт. И все это — заметьте — совершенно без помощи компьютеров. Что же это за столь замечательные правила?

Согласно Правилам Приближенных Вычислений (ППВ), каждому числу, полученному в результате измерений или вычислений, неотрывно сопутствует некая величина, характеризующая его точность. Эта величина может быть выражена абсолютной погрешностью, например (10 +/- 1); относительной погрешностью (10 +/- 10%); количеством значащих цифр, которое обычно выражается в записи (1.000); или записью числа в виде интервала возможных значений (99..101). Эти формы записи в общем-то эквивалентны, и могут быть получены одна из другой. Суть в том, что мы:

1. Имеем на входе приближенные числа с известной погрешностью.
2. Производим над ними арифметические действия как с точными числами
3. На выходе имеем результат также с известной погрешностью.

Например, при сложении приближенных чисел достаточно просто сложить их абсолютные прогрешности. При умножении и делении — сложить относительные погрешности. Таким образом можно определить погрешность результата любой цепочки арифметических действий. Более подробно о ППВ можно прочитать в любом математическом справочнике.

Вернемся к нашим баранам — компьютерам. Что делают они?

1. Имеют на входе некоторые числа.
2. Вносят в них некоторую погрешность даже при присвоении переменным, как результат особенностей внутреннего представления.
3. Производят над ними арифметические действия, внося некоторые погрешности как результат реализации вычислителя
4. На выходе имеют неточный результат с неизвестной погрешностью.

Как видим, на алгоритмы ППВ похоже с точностью до наоборот.

Что же за странную задачу решает компьютер, и кому она такая нужна?

Подобный порядок вычислений имеет смысл лишь тогда, когда контроль точности результата ведется отдельно, либо заложен в саму задачу. В первом случае нам необходимо параллельно с формулами вычислений написать формулы вычисления погрешности. Иллюстрацией второго может быть решение некоего уравнения численными методами, когда берем результат в «артиллерийскую вилку», и итеративно приближаемся к нему с обеих сторон, прекращая вычисления при достижении шагом итерации некоего малого значения. Конечно, для решения учетно-бухгалтерских задач такие подходы выглядят экзотично. Но если вспомнить, что первые компьютеры использовались в основном для решения чисто научных либо военных задач (например, баллистики), то станет понятно, что другого от компьютеров тогда и не требовалось.

Ученые той поры привыкли к своенравной вычислительной технике, и учитывали это в соответствующих математических моделях. Представьте, например, баллистическую ракету. Десятиметровая бандура, сделанная из жести. Она не стоит, а скорее висит на захвате стартовой вышки, потому что жесткости у нее никакой — она играет как резиновая. Включаются двигатели, захват отпускают, и представьте, что вы вертикально держите ее на кончике пальца, как карандаш. Карандаш норовит упасть, вы ловите отклонение и пододвигаете палец. А ракета, кроме того, ревет двигателями, норовит сложиться пополам, скрутиться по спирали, да и нужно ее не просто удержать, а запустить именно в заданную сторону. Все это своенравие учитывается в математической модели устойчивости, выворачивается наизнанку и кладется в систему стабилизации и наведения — ящик между гироскопами и двигателями. А перед тем гоняем математическую модель ракеты на аналоговой ЭВМ — наборе операционных усилителей и деталюшек, изготовленных с точностью в лучшем случае 0.1%. И все работает. Ну и скажите, имеет ли значение некоторая погрешность, если пыхтящую аналоговую ЭВМ заменить не совсем точной цифровой? Если исходная математика правильна и обратные связи модели отрабатываю верно, то все будет работать в любом случае. Поэтому не ругайте компьютеры — при правильном подходе из них можно извлечь немалую пользу.

Прошли времена железных людей, управляющих железными компьютерами. Теперь мы хотим считать на машинах килограммы, штуки, и конечно же деньги. И чтоб все сходилось до копеечки. А floating-point-вычислители-то остались прежними — пахнущими ракетной копотью и научной романтикой. И если мы хотим получить предсказуемые результаты и нести за них какую-то ответственность, то нам в наших программах придется вернуться к Правилам Приближенных Вычислений, и попытаться организовать их самостоятельно, не надеясь на компьютер, а используя его как вспомогательный инструмент.

Как мы уже говорили, ППВ позволяют знать погрешность результата на каждом этапе вычислений. Но для длинных цепочек трехэтажных формул прослеживание погрешности каждого этапа может оказаться делом нелегким, да и необходимо это сравнительно редко — в основном в научных задачах, где погрешность может оказаться соизмеримой с результатом. На практике пользуются упрощенными правилами, основанными на подсчете значащих цифр:

1. При сложении и вычитании приближённых чисел в результате следует сохранять столько десятичных знаков, сколько их в приближённом данном с наименьшим числом десятичных знаков.
2. При умножении и делении в результате следует сохранять столько значащих цифр, сколько их имеет приближённое данное с наименьшим числом значащих цифр.
3. При возведении в квадрат или куб в результате следует сохранять столько значащих цифр, сколько их имеет возводимое в степень приближённое число ( последняя цифра квадрата и особенно куба при этом менее надежна, чем последняя цифра основания ).
4. При увеличении квадратного и кубического корней в результате следует брать столько значащих цифр, сколько их имеет приближённое значение подкоренного числа (последняя цифра квадратного и особенно кубического корня при этом более надёжна, чем последняя цифра подкоренного числа).
5. Во всех промежуточных результатах следует сохранять одной цифрой более, чем рекомендуют предыдущие правила. В окончательном результате эта «запасная» цифра отбрасывается.
6. Если некоторые данные имеют больше десятичных знаков (при сложении и вычитании) или больше значащих цифр (при умножении, делении, возведении в степень, извлечении корня), чем другие, то их предварительно следует округлить, сохраняя лишь одну лишнюю цифру.
7. Если данные можно брать с произвольной точностью, то для получения результата с K цифрами данные следует брать с таким числом цифр, какое даёт согласно правилам 1-4 (К+1) цифру в результате.

Здесь уместно привести высказывание выдающегося инженера-кораблестроителя академика Крылова, который говорил: «Лишняя вычисленная цифра есть ОШИБКА». Вопреки распространенному мнению, таскание хвостов незначащих цифр вместо их округления вовсе не повышает точности вычислений, а наоборот — может привести к накоплению ошибок в самых неожиданных местах. Ну и кроме этого, речь идет об элементарной грамотности и аккуратности — при выводе результата 10,1230 лишние цифры могут создать впечатление их достоверности, скажем, до четвертого знака, в то время как исходные данные задавались плюс-минус лапоть. А это уже чревато рухнувшими мостами и взорванными реакторами. Недостоверные разряды следует округлять. Поэтому перейдем к фундаментальной операции приближенных вычислений — округлению.

Согласно школьного курса математики, при округлении чисел мы отбрасываем ненужные разряды, причем если первая отбрасываемая цифра больше или равна 5, то последняя сохраняемая цифра увеличивается на единицу. Будем называть этот способ «Арифметическим округлением».

Недоверчивый читатель, наверное, уже заподозрил, что сейчас пойдет речь и о других способах округления, и тянет руку с вопросом: а зачем, собственно? Чем не устраивает этот, столь родной и знакомый?

Проблема заключается в накоплении статистической погрешности при округлении большого количества чисел. Другими словами, многие задачи требуют, чтобы сумма столбика неокругленных значений была равна, или хотя бы близка сумме столбика округленных значений, а арифметическое округление приводит к серьезной и неизбежной ошибке, нарастающей с объемом данных. Причем это вовсе не связано с машинной арифметикой. Чтобы убедиться в этом, выключим компьютер, вооружимся счетами и карандашом, и решим такую задачу.

Контора заработала ровно миллион рублей, и поручила бухгалтеру разделить их на тысячу работников пропорционально коэффициенту трудового участия (КТУ). Тот выполнил арифметические действия и получил для каждого работника некоторое число Ni, с некоторым хвостиком дробных копеек. Убедился, что сумма всех Ni дает ровно миллион (мы опускаем проблемы неделимости нацело и бесконечных дробей — пусть хоть сегодня у нас все поделилось). Рассчитал сумму к выдаче — округлил каждое Ni до копеек, и подбил итог. И что же он видит?

Итог к выдаче составил что-то вроде один миллион рублей 50 копеек. А где ж эти 50 копеек взять? Он бы уже рад их и из своей получки добавить, да только проверяющие придут, и скажут — батюшки, да у вас бухгалтерия не пляшет — вот вы у нас теперь и попляшете. Плясать бухгалтеру вовсе не хотелось, поэтому вздохнул он и начал разбираться.

КТУ в конторе по старой советской традиции ставили с потолка, поэтому он достаточно хорошо подчинялся закону распределения случайных чисел. Соответственно, когда дело доходило до округления, то среди «первых отбрасываемых цифр» было примерно поровну нулей, единичек, двоек и всех остальных цифр. Каждая операция округления вносила свою погрешность (разницу между первоначальным и округленным значением) в зависимости от отброшенного хвостика. При этом погрешности отброшенных единичек (-0.001) компенсировались погрешностями девяток (+0.001), двойки компенсировали восьмерки, и так далее, и лишь погрешности, вносимые при отбрасывании пятерок (+0.005), оставались нескомпенсированными, и накапливались. В среднем на тысяче человек встретилось 100 операций отбрасывания пятерки, каждая из которых дала погрешность пол-копейки. Отсюда и набежали злосчастные 50 копеек.

Вот фрагмент расчетной ведомости, демонстрирующий набегание одной копейки при раздаче суммы в 2000 руб.21 коп.:

Источник