В 10 из 36 учебных расчётов неотрицательный итог скрывал нехватку денег внутри периода. Ниже — 12 вымышленных наборов, результаты независимой сверки и файлы для проверки своей таблицы. Это не статистика бизнеса и не клиентский кейс.
В этой статье
Одинаковый итог, разный риск
Возьмём два вымышленных календаря. В обоих на старте 100 000, поступление 100 000 и выплата 150 000. Итог одинаковый: 50 000. В первом выплата происходит 2 октября, поступление — 15 октября: на время возникает нехватка 50 000. Во втором деньги приходят 2 октября, а выплата назначена на 15-е: дополнительный резерв не нужен.
Проверка только последней строки не различает эти календари. Для принятия решения нужны минимальный остаток и его дата. Это расчёт денег, не бухгалтерской прибыли: налоговые начисления и маржинальность такая модель не определяет.
На узком экране таблица прокручивается вправо →
| Учебный календарь | Порядок | Итог | Минимум | Резерв до нуля |
|---|---|---|---|---|
| Оплата позже | Выплата → поступление | 50 000 | −50 000 | 50 000 |
| Оплата раньше | Поступление → выплата | 50 000 | 50 000 | 0 |
Как устроена проверка
Проверка выполнена 30 сентября 2026. Для каждого из 12 наборов рассчитаны три варианта: исходные даты, задержка поступлений и отдельный рост выплат. В 36 из 36 результатов совпали дневные строки, итог, минимум, первый дефицит и оба резерва.
Первая реализация — JavaScript-модель опубликованного калькулятора, запущенная через Node.js. Вторая написана отдельно на Python: Decimal, целые копейки, группировка операций по дате. Совпадение двух реализаций снижает риск программной ошибки, но не доказывает, что предусмотрена любая ситуация.
Набор намеренно включает поздние поступления, отрицательный старт, нулевой календарь, копейки, переход года и 29 февраля. Сценарии не случайные и связаны между собой; число 10 из 36 нельзя переносить на долю реальных компаний или интерпретировать как статистическое исследование.
Резерв до подушки уже включает запас
В рабочем учебном примере задержка поступления создаёт минимум −240 000. При подушке 30 000 нужно 270 000 дополнительных денег. В протоколе это отдельные поля: резерв до нуля и резерв до подушки. Они обозначают альтернативные пороги и не складываются.
При аудите инструкции обнаружили несогласованность с обновлённым инструментом: прежний текст предлагал прибавлять подушку отдельно. Расчёт уже включал её в соответствующий результат. Инструкцию исправили; саму математическую модель ради старого текста не меняли.
Полная таблица всех 36 расчётов доступна в CSV; исходные настройки и операции — в архиве. Суммы в одной условной валюте. Протокол фиксирует результаты выбранной версии модели, а не обещает неизменность будущих версий.
Два ограничения, которые зелёный тест не снимает
В наборе «Операции одного дня» исходный вариант не показывает дефицит: поступление и выплата сворачиваются в дневную сумму. Если списание утром, а зачисление вечером, реальная нехватка возможна. Для такого решения нужен порядок операций внутри дня; наш калькулятор его не моделирует.
Начальный остаток входит в минимум даже до первой операции. Отрицательный старт нельзя скрыть будущим поступлением. И наоборот: при положительном минимуме денег может не хватать до установленной подушки. Проверка одного признака «итог больше нуля» не отвечает ни на один из этих вопросов.
Это проверка выбранных расчётных сценариев. Здесь не испытывались банк, кредитный продукт, безопасность всей системы или пересчёт в настольном Excel. Проценты, налоги, комиссии и неполученные обещанные оплаты не добавляются автоматически.
Как проверить свою таблицу и закончить расчёт
Сначала сохраните текущий проект калькулятора, если он заполнен. Распакуйте архив и импортируйте один JSON из папки projects: импорт заменяет текущий ввод. Нажмите «Рассчитать три сценария» и сравните с соответствующими строками CSV. Все файлы содержат только вымышленные данные.
Повторите пару календарей с одинаковым итогом в своей рабочей таблице. Если она не различает резерв 50 000 и 0, добавьте расчёт остатка по датам и минимум, а не ещё один итоговый показатель. Затем проверьте отрицательный старт, подушку и операции одного дня.
Для своих данных внесите свободные деньги на начало дня и только будущие обязательства. Найдите худшую дату, уточните порядок операций внутри дня и согласуйте способ покрытия. После договорённости измените даты и суммы, пересчитайте и сохраните XLSX-снимок из калькулятора. Снимок фиксирует значения; он не пересчитывается как редактируемая модель.
Для независимого повтора распакуйте архив, установите Python 3.11+ и Node.js, выполните: python cash-model-check.py cashflow.js. Код не использует сеть, учётные данные или сторонние Python-пакеты. Перед запуском его можно прочитать. Код и версия модели внутри архива зафиксированы на дату проверки.
Что взять в работу
При проверке денежного календаря начните с двух примеров с одинаковым итогом и разным порядком платежей. Затем проверьте начальный дефицит и запас до подушки. Только после этого используйте модель для обсуждения реальных дат и обязательств.