MODEL STATUS = PASS, а отрицательные часы дают 148,25% рентабельности проекта
MODEL STATUS = PASS, а отрицательные часы дают 148,25% рентабельности проекта
У проектного реестра есть зелёный контроль. Он проверяет отрицательную выручку, отрицательные прямые затраты и арифметическую связь общей прибыли с себестоимостью. Этого хватает для PASS, но не для проверки часов команды.
Если в демонстрационной строке проекта Г поставить −160 часов, книга покажет стоимость труда −288 000 ₽, полную себестоимость −193 000 ₽, прибыль 593 000 ₽ и рентабельность 148,25%. Статус останется зелёным.
Все значения ниже — учебные входы XLSX Finspect и воспроизводимые подстановки. Это не клиентский кейс, не рыночная ставка и не норматив маржи.
Как устроена модель
В строке проекта шесть входов: название, клиент, выручка, прямые затраты, часы и ставка часа. Формулы считают:
- стоимость труда = часы × ставка;
- полную себестоимость = прямые затраты + стоимость труда;
- прибыль = выручка − полная себестоимость;
- рентабельность = прибыль / выручка.
Базовый набор содержит пять проектов. 
Проверка сложением: 3 320 000 − 1 155 000 прямых затрат − 1 692 000 труда = 473 000 ₽.
Рейтинг по выручке и рейтинг по рентабельности различаются. Проект Д имеет крупнейшую выручку 950 000 ₽, но оставляет 62 000 ₽ прибыли. Проект А при меньшей выручке даёт 226 000 ₽. Причину таблица не доказывает: для этого нужны состав работ, команда, цена, переделки и условия клиента.
Десять часов проекта Г
У проекта Г выручка 400 000 ₽, прямые затраты 95 000 ₽, 160 часов и ставка 1 800 ₽/ч. Точная точка нулевой прибыли:
(400 000 − 95 000) / 1 800 = 169,44 часа
Для решения нужен первый целый час за границей. При 170 часах труд стоит 306 000 ₽, полная себестоимость — 401 000 ₽, прибыль — минус 1 000 ₽, рентабельность — минус 0,25%. 
Вопрос собственника звучит так: почему у проекта Г при выручке 400 000 ₽ остаётся 17 000 ₽ прибыли, кто подтверждает 160 часов и что будет, если в табель добавятся ещё 10?
Почему PASS не замечает неверный знак
Формула стоимости труда не ограничивает часы положительными значениями. Контроль такого условия тоже не содержит. Поэтому отрицательные часы не создают техническую ошибку: они создают отрицательную себестоимость и ложную прибыль.
После подстановки −160 часов проект Г показывает 593 000 ₽ прибыли. Общая прибыль портфеля растёт до 1 049 000 ₽, рентабельность — до 31,60%. Все контрольные строки остаются OK.
Я бы не называл такой контроль проверкой данных. Он пропускает отрицательные часы и показывает PASS при 148,25% рентабельности, то есть сверяет арифметику. Подтверждением табеля зелёный статус не служит.
В финансовой модели доставки похожая граница проявлялась иначе: годовой статус оставался зелёным при убыточных месяцах. В калькуляции услуги отрицательная ставка тоже могла занизить себестоимость. Общий вывод один: список контролей важнее цвета статуса.
Нулевая выручка и спокойный процент
Если выручку проекта Г заменить нулём, его затраты останутся 383 000 ₽. Прибыль станет отрицательной на ту же сумму. Формула рентабельности делит на ноль, а IFERROR возвращает 0%.
Проверка отрицательной выручки не срабатывает: ноль формально не меньше нуля. Общий статус остаётся PASS. Поэтому 0% рядом с нулевой выручкой означает не «проект без отклонений», а «показатель не определён»: решение принимается по сумме прибыли.
Есть и обратный пример — поломка, которую лист замечает. Название проекта Г стёрто, суммы в строке остались: формулы IF(B="";0;...) обнуляют труд, себестоимость и прибыль, а выручка 400 000 ₽ продолжает сидеть в своде. Свод показывает прибыль 456 000 ₽ при разнице выручки и себестоимости 856 000 ₽, третья проверка ловит разрыв 400 000 ₽ и переводит статус в FAIL. Значит, граница контроля проходит так: строка, выпавшая из расчёта целиком, видна, а строка с неверным знаком внутри — нет.
Минимальный набор контролей для рабочих данных
К существующим трём проверкам проектный реестр обычно добавляет условия, которые следуют из принятой методики. Часы не могут быть отрицательными. Ставка не может быть отрицательной. Заполненная строка проекта не должна иметь нулевую выручку без отдельного статуса. У каждой суммы должен быть период, источник и владелец.
Такие условия нельзя вставить в шаблон как универсальную истину без оговорок. Например, отрицательная строка может быть корректировкой прошлого периода. Тогда она не запрещается, а получает тип операции, ссылку на исходную запись и объяснение. Нулевая выручка может относиться к внутреннему проекту, но его нельзя ранжировать по той же рентабельности, что клиентские заказы.
Рабочая контрольная таблица поэтому отделяет ошибку от исключения: 
PASS после этого всё равно не становится аудитом. Он лишь говорит, что перечисленные риски обработаны. Если табель загружен не полностью или ставка собрана по неверной базе, формулы не узнают об этом сами.
Что должно быть рядом с формулой
Для выручки нужен договор, акт или другой принятый источник. Для прямых затрат — документ и проектный идентификатор. Для часов — табель с периодом и владельцем. Для ставки — утверждённое правило расчёта. Без этих четырёх связей книга остаётся калькулятором на введённых данных.
Стоимость труда в проектной строке не означает повторный расход в ОПиУ. Проектный отчёт распределяет ресурс между заказами; общий отчёт компании показывает фактический фонд оплаты труда. Между ними нужен мост, чтобы сумма распределённых затрат сверялась с источником и не считалась второй раз.
Финансовому директору — пять рабочих дней на реестр проектов одного закрытого месяца в XLSX. В каждой строке: выручка и прямые затраты в одной базе без НДС, часы, ставка, стоимость труда, прибыль, рентабельность, а рядом — источник каждой суммы и роль, которая её подтверждает. К файлу добавить четыре проверки: часы и ставка не меньше нуля, у заполненной строки есть выручка, рентабельность не выше 100%. Всё, что эти проверки остановили, — в реестр расхождений с причиной и ответственным. Для трёх наименее рентабельных проектов — запас часов до нуля и первый целый час убытка. Сдать проверенный XLSX и одну страницу: какие цены, премии и новые загрузки ждут закрытия данных.
Результат такого реестра — не вердикт команде. Тонкая маржа бывает осознанной: первый заказ клиента, обучение, продуктовый тест. Разница в том, записано это решение до работы или найдено объяснением после убытка.
Подробный разбор формул и XLSX находятся в материале Finspect о рентабельности проектов.