Расхождения в отчётах: как свести данные из разных источников

Регулярный отчёт, который собирают руками из пяти-семи систем, ломается всегда в одном и том же месте. Не в формулах — формулы как раз работают. Ломается там, где выгрузки из разных источников надо привести к единому виду, чтобы формулы вообще получили на вход то, что ожидают. Один и тот же магазин в одной системе называется «ТК-1204», в другой — «Магнит, ул. Ленина 12», в третьей у него внутренний код из семи цифр. Дата отсечки в одной выгрузке — последний календарный день, в другой — последний рабочий. И пока человек это выравнивает, уходит день.

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

Почему данные не сходятся: шесть причин, которые повторяются

Прежде чем что-то автоматизировать, полезно назвать причину расхождения. Их немного, и они кочуют из компании в компанию.

Разная дата отсечки. Витрина обновляется ночью, CRM — в момент запроса, рассылка от смежного подразделения ушла в 16:00 вчера. Три цифры за «один и тот же месяц» относятся к трём разным моментам времени.

Разный справочник объектов. Магазины, проекты, контрагенты, юрлица. В одной системе список ведёт бухгалтерия, в другой — коммерция, и они расходятся на десяток позиций: закрытые точки, переименования, дубли с пробелом в конце названия.

Разное определение метрики. «Выручка» с НДС и без, «сделка» — подписанный договор или оплаченный счёт, «просрочка» — от плановой даты или от даты последнего переноса. Формально считают одно и то же, фактически — разное.

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

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

Ручные правки в источнике. Кто-то поправил цифру в промежуточном файле, потому что «так правильнее», и не записал, что именно поправил.

Дальше каждый шаг закрывает одну или несколько этих причин.

Шаг 1. Карта отчёта на одной странице

Первое действие — не выгрузка, а описание. Нужна таблица, в которой для каждой метрики отчёта записано: определение одной фразой, источник, формат выгрузки, ключ, по которому строка опознаётся, период и дата отсечки, владелец данных. Одна страница, обычно 20–40 строк.

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

Составить карту быстрее всего диктовкой. Вы описываете отчёт словами так, как рассказали бы новому сотруднику, а модель раскладывает это по столбцам и — главное — возвращает список того, что вы не сказали.

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

Правила:
— ничего не додумывай; если из моего описания не ясно определение метрики,
  ключ или дата отсечки, ставь «уточнить»;
— все «уточнить» собери внизу отдельным списком вопросов, по одному на строку;
— если две метрики считаются из одного источника по-разному, отметь это.

Вот описание отчёта: <ваш текст>

Список вопросов в конце — самая ценная часть ответа. По опыту участников анкет, там обычно всплывает 5–10 мест, где у смежных подразделений разные представления об одной цифре. Их разбирают один раз, письменно, и дальше отчёт перестаёт расходиться по этой причине.

Шаг 2. Справочник соответствий, без которого ничего не сойдётся

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

Сопоставление названий — задача, где модель работает хорошо, потому что она умеет видеть, что «ООО "Строймонолит"» и «Строймонолит, ООО» — одно и то же. Но она же охотно сопоставит «Проект Север-2» и «Проект Северный», если её не ограничить. Поэтому ограничиваем явно.

Дано два списка названий одних и тех же объектов из разных систем.

Список A (CRM):
<вставить>

Список B (учётная система):
<вставить>

Сопоставь построчно. Верни таблицу: A | B | уверенность | основание сопоставления.
Уверенность: высокая / средняя / низкая.
Высокая — только если совпадает ИНН, номер объекта или адрес.
Совпадение «по смыслу названия» — это средняя, не выше.
Если пары нет, пиши «нет пары», не подбирай ближайшее.

Отдельно после таблицы выведи два списка:
1) всё, что ниже высокой уверенности, — на ручную проверку;
2) позиции из A и из B, которым вообще не нашлось пары.

Дальше человек глазами проверяет только второй и третий блок — обычно это 10–15% строк вместо всех. Готовый справочник кладут туда же, где лежит отчёт, и при следующем сведении он подставляется автоматически.

Шаг 3. Привести выгрузки к одной длинной таблице

Здесь чаще всего и застревает работа. Структура у источников разная: где-то месяцы разъехались по столбцам, где-то шапка на трёх уровнях, где-то итоговая строка внутри данных. Power Query решает это, когда структура стабильна, и перестаёт помогать, когда у каждого источника она своя — на каждый источник нужен свой запрос, а при изменении шапки запрос падает.

Рабочий приём: привести все выгрузки к одному длинному формату «дата | объект | метрика | значение | источник». Одна строка — одно наблюдение. Из такой таблицы любой срез собирается сводной за минуту, и, что важнее, две выгрузки в этом формате сравниваются механически.

Преобразование пишет код, а не чат. Вы даёте модели по 10–15 строк из каждой выгрузки и просите скрипт.

Ниже — первые 15 строк четырёх выгрузок с разной структурой.
Напиши скрипт на Python (pandas), который приводит их к одной таблице
со столбцами: дата | объект | метрика | значение | источник.

Требования:
— значения не менять, только переставлять и переименовывать;
— даты привести к формату ГГГГ-ММ-ДД, для каждой выгрузки явно указать,
  какой исходный формат ты распознал;
— строки, которые не удалось разобрать, не выбрасывать, а собрать
  в отдельный датафрейм errors с именем файла и номером строки;
— итоговые строки («Итого», «Всего») в данные не включать, вынести отдельно;
— в конце вывести контрольные суммы: количество строк и сумму значения
  по каждому источнику до и после преобразования.

Сначала перечисли допущения по структуре, которые ты сделал. Потом код.

Выгрузка 1: <вставить>
Выгрузка 2: <вставить>

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

Тот же подход годится, если вы остаётесь в Excel: попросите не код на Python, а формулу или шаги Power Query, и обязательно — с объяснением, что делает каждый шаг. Документацию по самому Power Query Microsoft держит открытой, и сверяться с ней быстрее, чем спорить с моделью.

Шаг 4. Когда источник приходит в PDF

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

Извлечение таблицы из PDF — задача, которую ИИ решает, но с оговорками. Хорошо разбираются ровные таблицы с одной строкой шапки. Плохо — объединённые ячейки, таблицы, разорванные переносом страницы, и сканы плохого качества. Поэтому в промпт закладывается проверка объёма.

Во вложении отчёт подрядчика за месяц. Извлеки таблицу «Выполнение работ»
в CSV со столбцами: раздел | работа | ед. изм. | план | факт | комментарий.

Правила:
— переноси значения ровно как в документе: без округлений, пересчётов
  и приведения единиц;
— пустая ячейка остаётся пустой, ноль туда не подставлять;
— если значение не читается или строка разорвана переносом страницы,
  поставь «?» и перечисли такие строки отдельным списком после таблицы;
— в конце укажи: сколько строк в таблице исходника и сколько в твоём CSV.

Если числа строк не совпали, дальше не идём — ищем, где потерялось. Когда таких PDF приходит несколько десятков в месяц и от разных подрядчиков, имеет смысл один раз описать целевую структуру и прогонять все документы по одному шаблону: тогда на выходе получается единая таблица, а не двадцать разных.

Шаг 5. Протокол расхождений вместо переписки

Когда два источника дали разные цифры, обычно начинается обмен письмами: «у нас 41,2», «а у нас 39,8», «перепроверьте». Это и есть основная потеря времени — не сведение, а выяснение.

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

Даю две таблицы с одинаковыми ключами и разными значениями метрики.
Сделай таблицу расхождений: ключ | значение A | значение B | разница |
разница в % | гипотеза причины.

Гипотезы выбирай только из списка:
разная дата отсечки, разный справочник объектов, дубль строки,
разное определение метрики, возврат или сторно, НДС, курс валюты.
Если ни одна не подходит — пиши «не ясно», своих вариантов не добавляй.

Строки с нулевой разницей не выводи. Отсортируй по модулю разницы.
После таблицы одним абзацем: на какие 3 строки смотреть в первую очередь и почему.

Таблица A: <вставить>
Таблица B: <вставить>

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

Что считает код, а что — модель

Граница простая, и её стоит держать в голове при каждом шаге.

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

Модель: то, что связано с языком и структурой. Разобрать неровную шапку и понять, где тут метрика, а где размерность. Сопоставить названия. Вытащить таблицу из PDF. Объяснить, что означает формулировка в отчёте подрядчика. Написать черновик комментария к цифрам для руководителя. Предложить список гипотез, почему две цифры разошлись.

Черновик комментария — недооценённая часть. Свод готов, цифры сошлись, и человек ещё сорок минут формулирует, что они значат. Если отдать модели итоговую таблицу и попросить три абзаца: что изменилось к прошлому периоду, где отклонение больше 10% и какие вопросы это ставит, — получится заготовка, которую остаётся поправить. Подробнее этот сценарий я разбирал в статье «Отчёт руководителя с помощью ИИ» — там про сборку текста отчёта, здесь про сборку данных под него.

Проверка перед отправкой

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

Сходятся ли контрольные суммы — количество строк и сумма значений по каждому источнику до и после преобразования. Совпадает ли итог свода с итогом, который показывает сама система-источник на своём экране. Нет ли объектов, которым не нашлось пары в справочнике, — они молча выпадают из расчёта и не видны в итоге. Все ли периоды закрыты одной и той же датой отсечки. Не попали ли в данные строки «Итого» из исходников.

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

Что нельзя загружать и как настроить приватность

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

По настройкам: в личных тарифах ChatGPT и Claude использование переписки для обучения моделей включено по умолчанию и отключается вручную в настройках — как это устроено у OpenAI, стоит проверить первым делом, а не наоборот. У бизнес-тарифов условия другие, и описаны они отдельными страницами справки вендора; читать их лучше до того, как в чат уехала первая выгрузка, а не после. Корпоративные правила обычно и сводятся к двум пунктам: какие данные обезличиваем и в каком контуре работаем.

С чего начать на этой неделе

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

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

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