Почему отчёты Битрикс24 и Power BI показывают разные цифры

Расхождение между отчётом Битрикс24 и Power BI ещё не означает, что данные выгрузились с ошибкой. Один отчёт может считать созданные сделки, другой — успешно завершённые. Один показывает сумму карточек, другой — оплаты. А после объединения с товарами одна сделка может превратиться в несколько строк и увеличить итог.

В статье о выгрузке данных из Битрикс24 через BI-коннектор, REST, SQL и Excel мы разобрали получение данных. Здесь — следующий шаг: как найти причину разницы и проверить расчёт на конкретных сделках. Подход подходит для сверки списка CRM, стандартного отчёта, BI Конструктора и собственной модели Power BI, но правила каждого источника нужно проверять отдельно.

Официальные источники проверены 2 октября 2026 года. Все суммы, ID и даты в примере ниже учебные; это не клиентский кейс.

Сначала определите показатель: сумма сделок, оплаты или выручка

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

Сделка на 120 000 ₽, завершённая успешно, не доказывает оплату на 120 000 ₽. Клиент мог внести только 60 000 ₽. И даже эти 60 000 ₽ нельзя автоматически назвать выручкой: в данных может отсутствовать событие, по которому компания её признаёт. Если источником служат только карточки CRM, честное название показателя — «Сумма успешных сделок», с уточнением используемой даты.

Паспорт сверки удобно записать одной фразой: «Количество уникальных сделок и сумма в RUB, успешных по согласованному событию в сентябре 2026 года; московское время; воронка A; одинаковый разрешённый круг ответственных; одинаковый снимок данных». Дополните её правилом повторного открытия, составом суммы и моментом её фиксации: текущее значение карточки или значение на дату события.

Даты создания и закрытия: одинаковый месяц не означает одинаковую выборку

Сделка, созданная в августе и успешно завершённая в сентябре, войдёт в сентябрьский результат по успеху, но не по созданию. Если выгрузку заранее ограничили сентябрьской датой создания, никакая мера Power BI уже не вернёт эту августовскую сделку. Проверяйте ограничения и в источнике, и в загрузке, и на экране отчёта.

Плановая дата не заменяет событие успешного завершения

В официальном описании набора crm_deal поле CLOSEDATE обозначено как планируемая дата закрытия. В истории crm_deal_stage_history поле DATE_CREATE — время перехода на стадию. Назначение этих полей различается. Справочник наборов данных Битрикс24.

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

В REST поле MOVED_TIME означает время перехода на текущую стадию. Оно не является универсальной датой первого успеха. Для истории существует отдельный метод crm.stagehistory.list. Источники: поля CRM и история движения по стадиям.

Проверьте, какая связь с календарём работает в Power BI

Срез «Сентябрь» фильтрует данные через связи модели. Если календарь связан с датой создания, название визуала «Закрытые сделки» эту связь не меняет. Сверьте активную связь, выражение меры и фильтры визуала. Неактивная связь используется в расчёте через USERELATIONSHIP; для независимого отбора по разным датам могут понадобиться отдельные календари. Рекомендации Microsoft по активным и неактивным связям.

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

Задайте границы месяца и часовой пояс явно

Для сентября по Москве используйте интервал от 2026-09-01 00:00:00+03:00 включительно до 2026-10-01 00:00:00+03:00 исключительно. В UTC это от 2026-08-31 21:00:00Z до 2026-09-30 21:00:00Z. Такой полуоткрытый интервал не требует угадывать последнюю долю секунды месяца.

Событие 2026-09-30 21:30:00Z произошло уже 1 октября в 00:30 по Москве. Если сначала отбросить время и только потом вспомнить о часовом поясе, сделка ошибочно останется в сентябре. Не добавляйте три часа ко всем полям вслепую: выясните, содержит ли источник UTC, локальное время, смещение или только календарную дату.

Отдельно проверьте относительные периоды «сегодня» и «текущий месяц». Microsoft указывает, что DateTime.LocalNow в Power Query Desktop использует время компьютера, а в облачной среде Power Query Online возвращает UTC. Поэтому одинаковое выражение может давать разные границы суток. Поведение функций текущего времени.

Фильтры, стадии и права доступа: сравнивайте один набор сделок

Выгрузите список ID из обоих отчётов при одинаковом срезе. Сначала сравнивайте состав сделок, а уже потом итоговую сумму. Удобно разделить результат на три группы: только в Битрикс24, только в Power BI и в обоих источниках.

• Воронка и стадия. Проверяйте идентификаторы и смысл стадий. В REST группы P, S и F означают работу, успех и неуспех. Признак завершённости не равен успешности. Названия стадий могут отличаться между воронками. Описание полей и семантики стадий.
• Ответственный и подразделение. Уточните, используются текущие назначения или назначения на момент события. Переданная другому менеджеру сделка меняет текущий срез, даже если закрылась давно.
• Скрытые условия. Проверьте фильтры отчёта, страницы и визуала, выделения в других диаграммах, сохранённые состояния, а также условия внутри меры и запроса загрузки. Включите записи без ответственного, источника или пользовательского поля в отдельную контрольную группу.
• Служебные записи. Согласуйте учёт тестовых сделок, шаблонов регулярных сделок и исключённых направлений. Не удаляйте их из сверки молча: фиксируйте конкретное правило.

Права проверяют на двух уровнях: что получил загрузчик и что видит зритель. Не предполагайте, что список CRM под сотрудником, выгрузка через BI-коннектор и REST-запрос вернут одинаковый состав. Для выбранного канала установите контекст доступа и проверьте несколько известных ID. У crm.item.list доступ к чтению зависит от прав пользователя. Документация метода.

В Power BI отдельно проверьте RLS — ограничения доступа к строкам. В рабочей области они применяются к зрителям с ролью Viewer и не ограничивают Admin, Member и Contributor. Поэтому проверка владельцем модели не подтверждает, что сотрудник видит тот же набор. Документация Microsoft по RLS. Сверяйте данные в пределах разрешённого доступа; расширять его ради совпадения итогов не требуется.

Валюты, состав суммы и округление

Сначала сверяйте суммы отдельно по каждой валюте. Складывать 80 000 RUB и 1 000 EUR как 81 000 денежных единиц бессмысленно. После этого можно сравнивать пересчёт в валюту отчёта, если в обеих системах совпадают источник курса, дата курса, направление пересчёта и порядок округления.

В наборе сделок Битрикс24 различаются OPPORTUNITY — сумма сделки и OPPORTUNITY_ACCOUNT — сумма в валюте отчётов. Не сравнивайте исходную сумму с пересчитанной и не конвертируйте уже пересчитанное значение повторно. Поля денежных сумм в наборе сделок.

При одинаковой валюте проверьте ещё три вещи: входят ли в сумму налоги и скидки; не заменена ли вручную заданная сумма карточки суммой товарных позиций; не применяются ли разные правила округления. Сумма округлённых строк и округлённый общий итог могут отличаться. Для сверки сохраняйте исходную точность и отдельно показывайте результат округления. Замена ошибки преобразования числа на ноль также способна скрыть потерянные суммы.

Дубли после объединения таблиц и зерно данных

Зерно данных — это то, чему соответствует одна строка. В таблице сделок это может быть одна сделка, в оплатах — один платёж, в товарах — одна позиция, в истории — один переход стадии. Если соединить эти строки в одну широкую таблицу, сумма сделки начнёт повторяться.

Проверьте число строк и число уникальных ключей до и после каждого объединения. Ключ сделки должен различать порталы; при смешении сущностей — ещё и их типы. Уникальность одного числового ID нельзя переносить на всю интеграцию.

В Power BI факт сделок и факты оплат или товарных строк лучше моделировать с явно определённым зерном, а общие фильтры передавать через согласованные справочники. Связи и направление фильтрации проверяют на небольшой выборке. Это соответствует подходу со схемой «звезда», описанному в руководстве Microsoft по моделированию.

DISTINCTCOUNT ключа может исправить число сделок, но не сумму, повторённую в нескольких строках. SUM(DISTINCT amount) тоже не решение: у двух разных сделок бывает одинаковая стоимость. Не удаляйте дубли по одной сумме или названию. Нужно вернуть расчёт к одной строке на сделку либо предварительно агрегировать дочернюю таблицу до нужного уровня.

Проверьте и обратную ситуацию: INNER JOIN с товарами исключит сделки без товарных строк. А соединение со справочником, в котором один ключ встречается дважды, размножит факт. При разбивке по нескольким контактам или тегам одна сделка может попасть в несколько групп: сумма строк такой диаграммы не обязана равняться общему числу уникальных сделок. Для распределения денег между группами нужно отдельное правило.

Задержки обновления: сверяйте данные на один момент

Между изменением карточки и экраном отчёта может быть несколько шагов: источник Битрикс24, выгрузка, хранилище, модель Power BI и визуализация. Успешное завершение одного шага не означает, что обновилась вся цепочка.

В режиме Import Power BI работает с загруженной копией данных. Новые значения источника попадут в неё после обновления модели; перезагрузка вкладки браузера не заменяет эту операцию. DirectQuery обращается к источнику, но сам источник может быть отстающей витриной. Как устроено обновление данных Power BI.

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

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

Симптом → возможная причина → проверка

Учебный пример: шесть сделок и проверяемые итоги

Все данные в этом разделе вымышлены и предназначены только для проверки расчётов. Один учебный портал, одна воронка, одинаковые права и снимок. Суммы карточек не менялись. Повторных открытий нет; «Успех» означает единственный переход на успешную стадию. Сентябрь считаем по Москве, от 1 сентября включительно до 1 октября исключительно.

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

• Созданы в сентябре: ID 102, 103, 104, 105 и 106 — пять сделок; 250 000 RUB и отдельно 1 000 EUR.
• Успешно завершены в сентябре: ID 101, 102, 105 и 106 — четыре сделки; 280 000 RUB и отдельно 1 000 EUR.
• Созданы и успешно завершены в сентябре: ID 102, 105 и 106 — три сделки; 160 000 RUB и отдельно 1 000 EUR. Такой результат получится, если одновременно ограничить обе даты.

Сделка 101 объясняет, почему фильтр только по созданию теряет старую успешную сделку. Сделка 104 объясняет ошибку часового пояса: её успех в исходном UTC — 2026-09-30 21:30:00Z. При отборе сентября в UTC рублёвый итог успехов станет 320 000 вместо 280 000.

Воспроизводимый расчёт без подключения к CRM

Ниже самостоятельный SQL-запрос с учебными значениями. Он проверен в SQLite; реальные таблицы не нужны. Даты записаны в едином ISO-формате, уже по Москве, поэтому сравнение строк даёт ожидаемый порядок. В рабочей модели используйте подходящие типы дат. won_at — наше учебное поле события успеха, а не имя готового поля Битрикс24.

WITH deals(id, created_at, won_at, amount, currency) AS (
  VALUES
  (101, '2026-08-28 10:00', '2026-09-03 12:00', 120000, 'RUB'),
  (102, '2026-09-05 10:00', '2026-09-20 12:00',  80000, 'RUB'),
  (103, '2026-09-18 10:00', NULL,                50000, 'RUB'),
  (104, '2026-09-30 00:30', '2026-10-01 00:30',  40000, 'RUB'),
  (105, '2026-09-12 10:00', '2026-09-25 12:00',  80000, 'RUB'),
  (106, '2026-09-14 10:00', '2026-09-26 12:00',   1000, 'EUR')
)
SELECT currency,
  SUM(CASE WHEN created_at >= '2026-09-01'
            AND created_at <  '2026-10-01'
           THEN 1 ELSE 0 END) AS created_count,
  SUM(CASE WHEN created_at >= '2026-09-01'
            AND created_at <  '2026-10-01'
           THEN amount ELSE 0 END) AS created_amount,
  SUM(CASE WHEN won_at >= '2026-09-01'
            AND won_at <  '2026-10-01'
           THEN 1 ELSE 0 END) AS won_count,
  SUM(CASE WHEN won_at >= '2026-09-01'
            AND won_at <  '2026-10-01'
           THEN amount ELSE 0 END) AS won_amount
FROM deals
GROUP BY currency
ORDER BY currency;

Что произойдёт после объединения с товарами

Для рублёвых успехов сентября добавим две товарные строки у сделки 101, одну у 102 и три у 105. После обычного соединения будет шесть строк вместо трёх. Сумма повторённых значений карточек: 120 000 × 2 + 80 000 × 1 + 80 000 × 3 = 560 000 RUB. Правильная сумма сделок остаётся 280 000 RUB.

Количество уникальных ID всё ещё равно трём, поэтому правильное количество не гарантирует правильную сумму. А SUM(DISTINCT amount) даст 200 000 RUB: одинаковые 80 000 двух разных сделок будут учтены только один раз.

Отдельный набор оплат

Добавим четыре учебных подтверждённых платежа: 60 000 RUB по сделке 101 от 4 сентября; 80 000 RUB по 102 от 21 сентября; 20 000 RUB по 105 от 28 сентября; 400 EUR по 106 от 27 сентября. Других платежей и возвратов в примере нет.

Оплаты сентября: 160 000 RUB и 400 EUR. Это не ошибка по сравнению с 280 000 RUB и 1 000 EUR успешных сделок: измеряется другой факт. Выручку по этому набору определить нельзя — данных о её признании мы не задали. Курс тоже не задан, поэтому общего итога в одной валюте здесь нет.

Как провести сверку рабочего отчёта по шагам

1. Зафиксируйте паспорт показателя. Название, формула, дата, период, часовой пояс, валюты, воронки, стадии, права, момент снимка и правило повторного открытия.
2. Возьмите небольшой контрольный набор. Нужны старые сделки с новым успехом, запись на границе месяца, сделка без товаров, несколько товарных строк, две одинаковые суммы, другая валюта и частичная оплата. Используйте доступные существующие записи; создавать реальные сделки ради сверки не нужно.
3. Сравните ключи. Выведите два списка с ID и объясните каждый ID, присутствующий только с одной стороны. Проверяйте на уровне одного портала и типа сущности.
4. Сравните значения совпавших ID. Сумму, валюту, нужные даты, стадию, ответственного, число строк на ключ и время обновления. Разделите отличия состава и отличия значений.
5. Найдите первый шаг появления разницы. Сырой ответ или файл → очищенная таблица → объединение → модель → мера → визуал. Исправляйте конкретное правило и повторяйте тот же набор.
6. Проверьте общий период и соседнюю границу. После совпадения контрольных записей сверяйте весь месяц, а также последний день предыдущего и первый день следующего. Сохраните результаты до и после исправления.

Практический журнал расхождений — таблица «ключ сделки, источник, значение CRM, значение BI, причина, исправление, результат повторной проверки». Не ограничивайтесь записью «разница 40 000»: она не объясняет, из каких сделок получился итог. Для более широкого контроля качества полезен контрольный набор проверок выгрузки.

Когда цифры можно считать сверенными

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

• По каждому показателю известны источник суммы и используемая дата.
• Количество проверено по уникальному ключу, денежные суммы — по валютам и на нужном зерне.
• Фильтры и права проверены под тем пользователем, для которого предназначен отчёт.
• Пограничные даты, повторные открытия и изменения старых сделок обработаны по согласованному правилу.
• Видны время успешного обновления и состав контрольной выборки; повторная сверка воспроизводит результат.

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