Почему отчёты 1С, CRM и интернет-магазина показывают разные цифры

И как найти единую версию правды, если каждая система «права» по-своему

Знакомая ситуация: руководитель смотрит выручку за месяц в 1С — одна цифра. Маркетолог открывает отчёт CRM — другая. Панель интернет-магазина показывает третью, ещё и число заказов не совпадает ни с одним из первых двух отчётов. Каждый специалист уверен, что его система показывает правду, а остальные «врут» или «не досчитывают».

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

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

Простое объяснение: почему «одна и та же» цифра — на самом деле разные цифры

1С, CRM и интернет-магазин — не три копии одной базы данных, а три системы с разным назначением:

• Интернет-магазин фиксирует заказ в момент, когда покупатель нажал «Оформить заказ» на сайте — независимо от того, оплатил он его, подтвердил менеджер заявку или нет.
• CRM ведёт сделку по воронке — от заявки до закрытия, и разные компании по-разному определяют, что считать «продажей»: подтверждённый заказ, выставленный счёт или поступившую оплату.
• 1С (бухгалтерия, «Управление торговлей», «Розница» и подобные конфигурации) фиксирует хозяйственные операции — отгрузку, поступление оплаты, возврат — и живёт по правилам бухгалтерского и налогового учёта, а не по логике воронки продаж.

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

Как это работает: путь заказа через системы и где он расходится

1. Разные точки фиксации данных (разные даты события)

У заказа есть несколько дат: дата создания на сайте, дата подтверждения в CRM, дата оплаты, дата отгрузки, дата закрытия документа в 1С. Один отчёт строится по дате создания сделки, другой — по дате оплаты, третий исключает отменённые заказы, а четвёртый учитывает вообще все обращения подрядГлавная причина расхождений — разные правила учёта: один отчёт берёт дату создания сделки, другой дату оплаты, третий исключает отмены, а четвёртый тянет всё подряд [1]. Если отчёты в 1С, CRM и на сайте строятся по разным датам, за один и тот же «месяц» они на самом деле показывают разные наборы заказов.

Это касается и рекламной аналитики: расхождения между счётчиком сайта, рекламным кабинетом и CRM тоже часто объясняются разными периодами, моделями атрибуции и тем, что заявкой в CRM считается не то же действие, что конверсией в счётчикеОсновные причины расхождений — отчёты построены по разным датам, выбраны разные модели атрибуции и в CRM заявкой считается другое действие [2].

2. Бухгалтерский учёт vs учёт по факту продажи

В 1С выручка признаётся не в момент, когда покупатель нажал «Купить», а по правилам бухучёта. Классический подход — метод начисления: доход учитывается на дату фактической передачи товара или оказания услуги, то есть в момент отгрузкиМетод начисления связан с периодом фактического проведения хозяйственной операции: доход учитывают в момент передачи товара, оказания услуги, выполнения работы, то есть в момент, когда доход был начислен [3]. Если по условиям договора право собственности переходит к покупателю не в момент отгрузки, а в момент оплаты, выручка в бухучёте до этого момента вообще не признаётся, хотя товар физически уже ушёл со склада — для этого в плане счетов есть отдельный счёт «Товары отгруженные»Если право собственности на товар переходит к покупателю в момент оплаты, выручка в момент отгрузки не признаётся, но поскольку товар фактически уходит со склада, в момент отгрузки используется счёт «Товары отгруженные» [4].

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

3. Возвраты и отмены учитываются по-разному

Возврат — ещё одна точка расхождения. В некоторых конфигурациях 1С возврат, оформленный в день покупки, вообще не проводится отдельным документом реализации — розничная выручка просто уменьшается на выданную покупателю суммуЕсли товар возвращается в день покупки, операция по возврату в учёте отдельно не отражается — розничная выручка, пробитая за смену, уменьшается на выданную покупателю сумму [5]. А в CRM или на сайте такой заказ может продолжать висеть в статистике как «оформленный» и «оплаченный», если статус отмены не был передан обратно.

4. Технические сбои и ошибки обмена данными

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

• Задержка или сбой синхронизации. Данные о ценах, остатках или статусах заказа передаются не мгновенно, а по расписанию (например, раз в час или раз в сутки), и в течение этого окна отчёты в разных системах показывают разные состояния одного и того же заказа.
• Неуникальные идентификаторы. Одна из частых технических причин сбоя обмена — повторяющийся код-идентификатор в справочнике 1С: система 1С проверяет уникальность кода как целой строки, а CRM или сайт может индексировать каждую цифру кода отдельно, из-за чего запись «расклеивается» и синхронизация обрываетсяПроблема чаще всего возникает из-за неуникальности кодов в 1С: код-идентификатор в 1С проверяется на уникальность как целая строка, тогда как в CRM может индексироваться каждая цифра кода отдельно [6].
• Дубли клиентов и товаров. Если справочники клиентов и номенклатуры не синхронизированы, один и тот же товар может иметь разную цену в CRM и 1С, а один клиент — попадать в базу несколько раз под разными карточкамиОдин и тот же товар может иметь разную цену в CRM и 1С, что приводит к конфликтам с клиентами при отсутствии синхронизации [7].
• Конфликт «кто главный». Если и менеджер, и автоматическая синхронизация могут менять одно и то же поле (например, цену сделки), система с более поздним обновлением перезаписывает данные другой — и пользователь видит «чужую», необъяснимую для него цифруМенеджер правил цену сделки прямо в CRM, а ночная синхронизация затирала её ценой из 1С: утром менеджер видел «не свою» цифру, правил снова — и так по кругу каждый день [8].
• Ошибки ручного ввода. Там, где интеграция не настроена и данные переносятся вручную, добавляются опечатки в артикулах и количествах, а статус заказа может «зависать» на сайте, даже если товара уже нет в наличииСотрудники вручную переносили заказы в 1С, допуская ошибки в артикулах и количестве, а статус заказа на сайте мог продолжать висеть несколько дней, даже когда товара уже не было в наличии [9].

Российская специфика: как устроен обмен данных с 1С

Для российского рынка типовой канал обмена между сайтом и 1С — открытый XML-стандарт CommerceML, разработанный «1С» и «1С-Битрикс» для передачи каталога, остатков, цен и заказовДля организации обмена данными между системой «1С:Предприятие» и интернет-магазином фирмами «1С» и «1С-Битрикс» разработан и опубликован специальный протокол на основе XML-стандарта обмена коммерческой информацией CommerceML 2 [10]. Стандарт существует в нескольких редакциях (2.x, 3.x), которые отличаются набором файлов и возможностямиАвтоматический обмен CommerceML 3.0–3.1 использует файлы import.xml, offers.xml, prices.xml, rests.xml, а CommerceML 2.x — только import.xml и offers.xml [11] — и если сайт и 1С настроены на разные версии схемы, часть данных (например, характеристики товара) может просто не передаваться.

У такого обмена есть характерная особенность: он в основном рассчитан на выгрузку «файлом по расписанию», а не на мгновенную передачу событий через API. Из этого вытекает системная проблема: обмен, изначально собранный на файловых выгрузках без обработки ошибок, рано или поздно начинает «рассыпаться» при малейшем изменении номенклатуры или структуры данныхГлавная причина, по которой обмен «ломается», — не 1С, а то, что его изначально собрали на выгрузках без обработки ошибок [12]. Для интеграции 1С с сайтом, CRM и маркетплейсами системный подход означает отдельный слой обмена — с логированием, обработкой ошибок и алертами, а не просто «выгрузку по кнопке»Надёжная интеграция с 1С — это не «выгрузка по кнопке», а отдельный слой обмена с логированием и алертами [12].

Кроме формата обмена, стоит учитывать общие для российского бизнеса требования: персональные данные клиентов, которые «путешествуют» между сайтом, CRM и 1С, подпадают под требования 152-ФЗ — при построении обмена стоит заранее понимать, какие поля и куда передаются, чтобы не создавать неучтённые копии персональных данных в новых местах хранения.

Варианты решения: что делать с расхождениями

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

Уровень 1. Договориться о едином языке метрик

Прежде чем чинить интеграцию, полезно ответить на вопросы: что именно компания считает «заказом», «продажей» и «выручкой»; по какой дате строится каждый отчёт; какие статусы включаются, а какие исключаются. Это управленческая, а не техническая задача. Подход, который в аналитике данных называют единым источником правды (Single Source of Truth, SSOT), подразумевает, что вся компания использует один согласованный источник данных для ключевых сущностей — клиентов, заказов, метрикSSOT — это принцип, согласно которому вся компания использует один источник данных для ключевых бизнес-сущностей: клиентов, продуктов, заказов, метрик [13]. Но на практике успех такого подхода определяется не хранилищем данных и не ETL-процессами, а внутренними регламентами и согласованными методиками расчёта показателейНа практике успех SSOT зависит не столько от хранилища данных или ETL-процессов, сколько от внутриорганизационных регламентов, закреплённой ответственности и согласованных методик расчёта показателей [13]. Иными словами, без договорённости «что именно мы считаем» любая, даже самая дорогая техническая интеграция всё равно даст три разных отчёта.

Практический способ найти, где именно расходятся данные, — построить цепочку: рекламный источник → визит → заявка → CRM → продажа → выручка, и выборочно проверить 20–50 сделок по этой цепочке, чтобы увидеть, на каком шаге теряются или задваиваются данныерекламный источник → визит → заявка → CRM → продажа → выручка — проверьте выборку из 20–50 сделок, так можно быстро определить участок, где теряются данные [2].

Уровень 2. Выбрать и настроить технический способ обмена

Есть три основных варианта передачи данных между 1С, CRM и сайтом:

• Файловый обмен (например, по стандарту CommerceML) — подходит для небольшого ассортимента и невысокой частоты изменений, но плохо справляется с задачами, где важна скорость и надёжность именно на статусах заказов и деньгах.
• Веб-сервис / регламентный обмен через HTTP — среднее решение по сложности и скорости обновления.
• Прямая интеграция через API — используется для сложных сценариев, где нужен обмен в реальном времени: остатки, цены и статусы заказов синхронизируются без ручного вмешательстваИнтеграцию через API используют для сложных задач, где нужен мгновенный обмен данными: например, при подключении CRM к 1С:ERP API синхронизирует остатки товаров, цены и статусы заказов без ручного вмешательства [14]. Такой подход требует привлечения технических специалистов, но даёт большую гибкость и контроль.

Выбор зависит от бюджета, объёма каталога и требований к скорости обменаДля малого бизнеса обычно достаточно файлового обмена, для среднего удобнее web-сервис, а для крупных проектов с уникальными процессами нужен API интернет-магазина — решение выбирают исходя из бюджета, объёмов каталога и требований к скорости обмена [15].

Отдельно стоит решить вопрос «мастер-данных»: какая система является источником истины для конкретного поля — цена задаётся в 1С, а CRM только читает её, или наоборот. Без этого правила любое ручное изменение в одной системе рано или поздно будет затёрто автоматической синхронизацией из другой.

Уровень 3. Настроить контроль и мониторинг обмена

Даже правильно настроенный обмен со временем накапливает нестыковки — меняется структура каталога, появляются новые статусы заказов, обновляются версии систем. Разумный минимум контроля:

• логирование каждой сессии обмена и алерты при сбоях;
• автоматические проверки на пустые обязательные поля, дубли и резкие скачки показателей;
• контроль уникальности идентификаторов там, где объекты начинают «двоиться»Если в отчётах часто пропадают сделки без ответственного, проверяется это поле; если двоятся объекты, вводится контроль уникального идентификатора [1];
• регулярная сверка контрольных выборок заказов между системами, а не разовая проверка при внедрении.

Практические этапы: как навести порядок пошагово

1. Зафиксировать, что и как считает каждая система. Для 1С, CRM и сайта отдельно выписать: по какой дате строится отчёт, какие статусы включены, что происходит с отменами и возвратами.
2. Договориться об определениях показателей. «Заказ», «продажа», «выручка» должны получить одну формулировку для всей компании — лучше зафиксировать её письменно (паспорт метрики).
3. Проверить справочники. Устранить дубли клиентов и товаров, привести номенклатуру, единицы измерения и коды к единому виду перед настройкой или пересборкой обмена.
4. Определить мастер-систему для каждого типа данных. Явно решить, где правится цена, где — статус заказа, а где — контактные данные клиента, и настроить обмен так, чтобы он не перезаписывал ручные правки бесконтрольно.
5. Выбрать способ обмена под масштаб задачи — файловый, через веб-сервис или API — и заложить обработку ошибок, а не только «счастливый путь».
6. Настроить мониторинг обмена: логи, алерты об ошибках, автоматические проверки на дубли и пропуски.
7. Провести контрольную сверку — выборку из нескольких десятков заказов сверить вручную по всей цепочке систем.
8. Закрепить регламент — кто и как часто проверяет сходимость отчётов, что делать при обнаружении расхождения.

Ограничения, ошибки и риски

• Ошибка «чинить интеграцию, не договорившись о метриках». Даже идеальная техническая синхронизация не устранит расхождение, если 1С считает выручку по отгрузке, а CRM — по факту создания сделки. Сначала — определения, потом — техника.
• Риск «тихого» расхождения. Небольшие ежедневные нестыковки часто не бросаются в глаза, но накапливаются: сначала всплывают мелкие несовпадения, потом — крупные, и в какой-то момент отчёты начинают жить отдельно от происходящего в бизнесеСначала всплывают мелкие нестыковки, потом крупные расхождения; в какой-то момент отчёт живёт своей жизнью, отдельно от того, что происходит в продажах на самом деле [16].
• Ошибка при обмене со площадками (маркетплейсы, эквайринг). Расхождения бывают и на границе с внешними площадками: если самостоятельно искать расхождения построчно между отчётом площадки и своим учётом, это даёт понимание, но занимает очень много времениПошаговый алгоритм поиска расхождений эффективен и необходим, но имеет критический недостаток — он занимает огромное количество времени [17], поэтому для регулярной сверки лучше настраивать автоматизированный контроль, а не разовые ручные проверки.
• Риск потери доверия сотрудников к системам. Если менеджеры видят, что цифры в CRM регулярно «не бьются» с реальностью, они возвращаются к работе в Excel и параллельному учёту, а внедрённые системы перестают быть источником решенийСамая частая причина, по которой интеграция CRM заканчивается провалом, — не кривой код и не «плохая система», а то, что менеджер через две недели после запуска снова открывает свой Excel [8].
• Не путать техническую доступность API с открытым доступом. Наличие протокола обмена (как CommerceML) не означает, что всё настраивается «само»: часть операций может требовать конкретной версии схемы, доработки на стороне сайта или 1С, тестовой среды и согласования форматов полей.

Рекомендации по выбору решения

Если расхождения небольшие и системный обмен в принципе есть, но «сыпется» время от времени — вероятно, достаточно диагностики: проверить версии протокола обмена, справочники, логи ошибок и донастроить существующую интеграцию.

Если систем несколько, а обмена между ними нет вообще (данные переносятся вручную или через Excel-выгрузки) — нужна разработка интеграции с нуля: определить, какая система выгружает данные первой, какая — источник истины по каждому полю, и в каком формате (файл, веб-сервис, API) вести обмен.

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

Как может помочь «Пятый фактор»

Сопоставление данных, обработка ошибок и контроль обмена между сайтом, CRM и 1С — это то, с чем компании обычно и приходят: сайт корректно настроен, CRM работает, 1С ведёт учёт, но между собой системы либо не связаны, либо связаны ненадёжно, из-за чего отчёты расходятся. Команда «Пятого фактора» может изучить существующий процесс, разобраться, на каком шаге данные теряются или задваиваются, и помочь с архитектурой и реализацией интеграции — от точечной доработки обмена до сквозной синхронизации заказов, остатков и статусов между системами.

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

Вывод

Расхождение цифр между 1С, CRM и интернет-магазином — это не сигнал о том, что одна из систем «неправильная». Это сигнал о том, что у компании пока нет согласованного определения ключевых показателей и надёжного технического моста между системами. Решение начинается не с выбора «самого точного» отчёта, а с ответа на вопрос, что именно каждая система считает заказом, продажей и выручкой, — и только после этого имеет смысл чинить или выстраивать техническую интеграцию.

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

Источники

[1] businessbrainware.com — Отчёты не сходятся с данными: причины и ремонт — https://businessbrainware.com/analytics/otchyoti-ne-skhodyatsya-s-dannimi-prichini-i-remont/

[2] cybrain.io — Метрика, Директ и CRM не сходятся: причины и как исправить — https://cybrain.io/blog/metrika-direkt-crm-ne-skhodyatsya/

[3] fd.ru — Особенности признания выручки в бухгалтерском учете — https://www.fd.ru/articles/161417-osobennosti-priznaniya-vyruchki-v-buhgalterskom-uchete

[4] glavkniga.ru — Проводки по реализации товаров и услуг — https://glavkniga.ru/situations/k503011

[5] buhexpert8.ru — Возврат товаров в Отчете о розничных продажах — https://buhexpert8.ru/voprosy/voprosy-1s-buhgalteriya/vozvrat-tovarov-v-otchete-o-roznichnyh-prodazhah.html

[6] crm.ru — Интеграция CRM с 1С — возможности и руководство по настройке — https://crm.ru/blog/integratsiya-crm-s-1c/

[7] sbercrm.com — Как провести интеграцию 1C с CRM-системой — https://sbercrm.com/blog/start/tpost/0skhu305n1-integratsiya-crm-sistemi-s-1c

[8] brutalmarketing.me — Интеграция данных CRM: что делать и что нет — https://brutalmarketing.me/blog/integraciya-dannyh-crm-chto-delat-chego-izbegat

[9] spark.ru — Интеграция интернет-магазина и 1С: как синхронизация избавила нас от ошибок — https://spark.ru/startup/42clouds-1c-onlajn/blog/287643/integratsiya-internet-magazina-i-1s-kak-sinhronizatsiya-izbavila-nas-ot-oshibok-i-uskorila-otchetnost

[10] v8.1c.ru — Обмен данными с интернет-магазином — https://v8.1c.ru/tekhnologii/obmen-dannymi-i-integratsiya/realizovannye-resheniya/obmen-dannymi-s-internet-magazinom/

[11] hostcms.ru — Автоматический обмен с 1С (CommerceML) — https://www.hostcms.ru/documentation/modules/shop/exchange/1c/trade/

[12] mzrdigital.ru — Интеграция 1С с сайтом, CRM и маркетплейсами — https://mzrdigital.ru/blog/integraciya-1s-s-saytom-crm-marketplace

[13] habr.com — Миф о «едином источнике правды»: почему консолидация данных — это не про технологию, а про процессы — https://habr.com/ru/companies/modusbi/articles/952072/

[14] kt-team.ru — Интеграция CRM с 1С, сайтом и мессенджерами — https://www.kt-team.ru/blog/crm-integration-business-automation

[15] infraone-research.ru — Интеграция 1С с интернет-магазином — пошаговое руководство и чек-лист — https://infraone-research.ru/upravlenie-i-integracija-1s/integracija-1s-s-internet-magazinom-chto-nuzhno-znat/

[16] ifabrique.ru — Почему отчёты по продажам врут и как CRM помогает это исправить — https://ifabrique.ru/blog/pochemu-otchyoty-po-prodazham-vrut

[17] totalcrm.ru — Не сходится отчет Wildberries: пошаговый алгоритм поиска расхождений — https://totalcrm.ru/blog/2025/12/ne-shoditsya-otchet-wildberries-poshagovyj-algoritm-poiska-rashozhdenij-i-spornyh-summ_78