Выплата есть в таблице, но остаток завышен на 1 500 000 ₽: проверка ОДДС

Для человека «Платёж» и «Расход» могут описывать одну выплату. Для формулы это разные значения. В демонстрационном тесте шаблона ОДДС такая замена убирает из свода выплату сотрудникам и увеличивает остаток на 1 500 000 ₽. При этом итоговый статус модели остаётся PASS.

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

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

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

Это воспроизводимый методологический тест, не история клиента. Ни потери компании, ни ошибку конкретного бухгалтера он не доказывает.

Все значения ниже демонстрационные, взяты из шаблона Finspect. Выплата фонда оплаты труда в исходнике обозначена как «ФОТ». В таблице суммы указаны в рублях.

Получившийся поток 2 100 000 ₽ не следует называть прибылью. Здесь учитываются деньги, а не признанные доходы и расходы. Книга не содержит расчёта прибыли и не объясняет разницу между ней и остатком.

Саму эту разницу разбирал в прошлом выпуске серии — почему месяц с прибылью 1,08 млн ₽ даёт операционный поток минус 10,545 млн ₽. Там вопрос был, куда деньги ушли; здесь — все ли операции вообще попали в денежный отчёт.

В отдельной учебной копии у выплаты сотрудникам заменяется только тип: «Расход» вместо «Платёж». Размер выплаты, месяц и прочие операции не меняются. Теперь условия суммирования пропускают эту строку.

Свод покажет платежи 2 600 000 ₽. Поток станет равен 6 200 000 − 2 600 000 = 3 600 000 ₽, а остаток — 3 000 000 + 3 600 000 = 6 600 000 ₽. Разница с исходным результатом составляет 1 500 000 ₽ — ровно сумму исключённой выплаты.

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

Лист «Контроль» ищет отрицательные суммы, пустой тип у положительной суммы и отрицательный конечный остаток. В нашем сценарии ничего из этого не произошло. Сумма положительная, «Расход» не пуст, остаток вырос.

Для сравнения: пустой тип у той же выплаты 1 500 000 ₽ даст «ПРОВЕРИТЬ». Отрицательная сумма выплаты тоже даст сигнал. Но непустое неподходящее слово не входит в условия этих проверок.

MODEL STATUS = PASS означает, что перечисленные технические условия пройдены. Из него нельзя вывести полноту выписок или корректность переноса операций. Статус отвечает ровно на те вопросы, которые заложены в формулы.

Три встроенные проверки смотрят на суммы и на типы. Про то, как записан сам месяц, в них нет ни слова — а свод сравнивает период текстом, символ в символ, с образцом вида «2026-01».

Проверил подстановкой в файл: если у трёх январских строк оставить те же суммы и те же типы, но записать месяц как «01.2026», январь в своде обнуляется. Поступления — 0 ₽, платежи — 0 ₽, конечный остаток равен начальному, 3 000 000 ₽. Февраль после этого стартует с 3 000 000 ₽ вместо 5 100 000 ₽ и закрывается на 6 900 000 ₽ вместо 9 000 000 ₽. Отклонение 2 100 000 ₽ дальше едет по всем месяцам года.

Все три условия листа «Контроль» при этом зелёные, MODEL STATUS = PASS. Замена типа выносит из свода одну строку; несовпадение формата месяца выносит месяц целиком, и заметно это не в самом отчёте, а при сверке его оборотов с выпиской.

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

Я бы начал с таблицы соответствия исходных типов и типов ОДДС. Бухгалтерская система может использовать собственные названия; при переносе каждому значению нужно назначить явное правило. Неузнанные значения должны попадать в перечень исключений, а не растворяться в итогах.

Затем сравниваются поступления и платежи из источников с оборотами свода. Одного конечного остатка недостаточно: пропущенное поступление и пропущенная выплата близких сумм сдвигают остаток навстречу друг другу, и итог сходится при двух потерянных строках. Также проверяются исходный остаток, совпадение набора счетов, период и повторные записи.

Финансовому директору: "за пять рабочих дней представьте проверку выбранного месяца ОДДС. Для каждой операции покажите источник, идентификатор, сумму, период, исходный тип и правило включения в свод. Отдельно сдайте операции с неподходящим типом, повторы и суммы вне расчётного диапазона. Начальный остаток и обороты сопоставьте с выписками того же набора счетов. До объяснения расхождений не подтверждайте итог собственнику. Если источников нет, перечислите их и назначьте дату повторного просмотра. Результат — денежный свод и расшифровка исключений."

Срок относится к первой проверке и фиксации пробелов. Он не обещает восстановление отсутствующих документов. Собственнику достаточно поставить задачу и обсудить исключения; вручную искать строки должен исполнитель.

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

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

У шаблона ограничен диапазон операций, а год указан в формулах. Перенос на иной период и расширение таблицы требуют проверки расчётной области. Это управленческий инструмент, а не бухгалтерская сверка или аудит.

Даже подтверждённый месячный остаток ещё не описывает сроки будущих выплат. Вопрос дат вынесен в отдельный материал «Деньги кончаются не в день платежа: платёжный календарь на восемь недель». Здесь критерий приёмки уже: финансовый директор объяснил включение исходных операций и разницу оборотов.

Получить шаблон ОДДС с разбором этого теста.

Автор — Артём Высоцкий, основатель Finspect.