«Записано 260 строк». В таблице за месяц оказалось 227

Итог сходится, а подразделения в отчёте нет. Глазами на выборке такое не поймать: большая часть строк правильная.

Загрузка, которой все верят

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

В компании IT-консалтинга, где я руководил маркетингом, раз в месяц проверяли рекламные кабинеты нескольких подразделений. Проверку делали AI-агенты по рубрике из 21 критерия, находки записывались в онлайн-таблицу: на одном листе все находки строками, на другом свод по подразделениям и месяцам. По этой таблице потом подводили итоги месяца.

В начале сентября 2026 года агент провёл проверку за август: 260 находок, из них 39 критических. Через пару минут отчитался: «Результат в таблице». Основанием был ответ самой таблицы: записано 260 строк. Лист после записи никто не перечитывал.

Что было в таблице на самом деле

Я спросил: «Ты точно всё перепроверил?» Через четверть часа после отчёта агент перечитал лист.

Строк было 260. Но за август числилось только 227. Остальные 33 висели под месяцем, которого не существует: вместо «2026-08» в ячейке стояло число 46235.

Объяснение простое, хотя и неприятное. Таблица, получая текст «2026-08», в части строк решила, что это дата, и сохранила её так, как хранит даты внутри: числом. Для таблицы 46235 означает 1 августа 2026 года. Для человека это непонятное число, а для отчёта, который ищет строки по «2026-08», это вообще не август.

Пострадали не все строки, а только те, что легли в часть листа, где от старых данных сохранилось оформление «дата». Остальные записались правильно. Поэтому глазами ошибку не видно: смотришь выборку, всё на месте.

Кто выпал: одно подразделение целиком (31 строка) и две строки второго. Итоговое количество сходилось, а в августовском срезе одного подразделения просто не было.

Это было не всё

Дальше вопросы задавал я, и после каждого всплывал следующий слой.

Свода за август не существовало. Агент записал строки и остановился. Свод живёт на отдельном листе блоками по месяцам, и блок для нового месяца раньше добавляли руками. Шага «создать блок месяца» в процессе не было.

Одно подразделение называлось по-другому. У него два названия: короткий внутренний код и полное имя. Проверке передали код, а свод ищет полное имя. Если бы это не заметили, 17 августовских строк не попали бы в свод, итог показал бы 243 вместо 260, и ни одна формула не выдала бы ошибку. Формулы при несовпадении не ругаются, они просто не считают.

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

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

Та же проверка нашла ещё одну мину. Для удобства месяцы переименовали из «2026-08» в «Август 2026». А защита от повторной записи искала строки по старому написанию. Если бы загрузку по какой-то причине запустили повторно, она не увидела бы своих строк и записала август второй раз. В таблицу, по которой подводят итоги месяца.

Что изменили

1. Данные записываются как текст, без догадок таблицы. Там, где таблица должна что-то считать, считают формулы, а исходные значения она больше не толкует по-своему.
2. После записи таблицу перечитывают и сверяют минимум по трём разрезам: сколько строк за месяц, сколько по каждому подразделению, сколько по уровню важности, плюс сколько строк со странными значениями. В тот вечер после починки: 260 из 260, по подразделениям совпало, по уровням 135 незначительных, 86 серьёзных, 39 критических. Честно: автоматически программа пока сверяет только число строк, остальное перечитывается вручную.
3. Названия подразделений сверяются со списком до записи. Проверка сразу сработала на реальном примере: старый файл с кодом вместо полного названия она отказалась записывать.
4. Блок нового месяца в своде создаётся сам. Повторный запуск ничего не меняет и не задваивает.

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

Как проверить загрузку у себя

1. Смотрите на тот экран, которым пользуетесь сами. Не ответ системы «загружено 260», а итоговый отчёт или свод, по которому вы принимаете решения. Есть ли в нём нужный период вообще?
2. Сверьте итог по разрезам, а не одним числом. Общее количество может сойтись, когда внутри целый отдел выпал. Проверьте по подразделениям, менеджерам или точкам: каждое ли на месте и похоже ли число на прошлый месяц.
3. Ищите странные значения. Отфильтруйте колонку с датой или месяцем: нет ли там чисел вроде 46235 или пустых ячеек. Одна такая строка — повод проверить все.
4. Проверьте названия. Если у отдела, точки или кампании два написания, отчёт посчитает только одно. Сравните список в отчёте со списком, который вы знаете.
5. После любой «косметической» правки перепроверьте. Переименование, новая колонка, смена формата — ровно в такие моменты ломаются проверки, которые на эти названия опирались.

Если загрузки и отчёты у вас собирает подрядчик, эти пять пунктов можно отдать ему как чек-лист приёмки. А если хочется, чтобы кто-то сверял это каждый день за вас, начните с бесплатного разбора.