директор и машина · финансы · запись № 038 · 15 августа 2026 · Давид Герштейн

Финансовый контроль бизнеса: где расходятся цифры CRM и кассы

Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные.

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

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

Сверка платежей и CRM обычно выглядит формальностью — пока не начинает всплывать необъяснимая разница в цифрах. Разработчик настроил бота на ежечасную выгрузку данных из CRM и сравнение с предыдущей версией. Через несколько часов после синхронизации сделки «переезжали» в другие дни — сдвиг от 18 до 36 часов. В моменте версия показывала правильные даты, потом цифры расходились сами собой. Никто это не трогал руками. Просто так работала синхронизация.

Это частный случай общей проблемы. Сверка платежей в компаниях среднего размера почти никогда не заканчивается словами «всё сошлось». Обычно она заканчивается вопросом «а почему у нас расхождение в 300–500 тысяч рублей, и с какого месяца оно копится». Если сверку делает человек вручную — это полтора-два часа в день на поиск расхождений, письма с уточнениями, ожидание ответа от смежного отдела. При типичной часовой ставке такого сотрудника это выливается в кратные десятки часов в месяц, потраченные только на поиск расхождений, — притом что сверка всё равно опаздывает на месяц-два от момента, когда деньги реально разошлись.

Я собрал несколько историй с рабочих встреч — все они об одном: CRM и бухгалтерия смотрят на одну и ту же сделку с разных точек, и точки эти системно не совпадают. Ниже — где конкретно расходится, как это чинить механикой, а не разговорами, и во что это обходится, если не чинить вообще.

Момент признания дохода — ваш главный источник расхождений

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

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

Свести две системы к одной методологии — это навык руководителя, а не задача бухгалтерии. Бухгалтер отвечает за корректность проводок; за то, что вся компания считает выручку одинаково, отвечаете вы сами. Я сам долго считал это технической мелочью, которую финансист с коммерческим разрулят между собой, — и получал один и тот же спор каждый месяц, пока не сел и не написал определение на одну страницу. Спор о цифрах вообще не выигрывается аргументами — он снимается тем, что вы договариваетесь об одном источнике правды на каждый показатель.

Это не бюрократическая придирка. Если CRM признаёт доход в момент подписания, а касса — в момент поступления денег, зазор между «продано» и «оплачено» будет всегда. В отчёте для собственника этот зазор может выглядеть как воровство, хотя это просто разные точки отсчёта в двух системах, которые никто не свёл в одну методологию.

Пример с криптовалютным возвратом

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

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

Возвраты как чёрная дыра вашего учёта

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

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

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

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

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

Технические сбои, похожие на финансовые дыры

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

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

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

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

В мае так же не вовремя выплатили финансирование части рекламных кампаний. Рекламные площадки работают на предоплате, поэтому задержка платежа привела не просто к паузе, а к тому, что кампании начали хуже отрабатывать после возобновления. В CRM это никак не отразилось — сделки как шли, так и идут. А в реальности конверсия просела из-за финансового сбоя, который бухгалтерия видела, а маркетинг — нет.

Механика сверки: что → чем → куда

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

Соберёте это за день. Дальше сверка займёт у вас минуты в неделю вместо разбирательств в конце месяца.

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

1. Что: выгрузка сделок и платежей за период. Чем: Bitrix24 REST API (метод crm.deal.list) для CRM-стороны плюс банковская выписка или выгрузка из 1С для кассовой стороны. Куда: промежуточная таблица — Google Sheets на старте, база данных, когда объём вырастет.
2. Что: сопоставление по сумме, контрагенту и периоду с допуском на курсовые и комиссионные расхождения. Чем: скрипт-обвязка плюс модель для нечётких случаев — частичные оплаты, разное написание контрагента, объединённые платежи. Куда: лист или таблица «Расхождения» с типом и суммой отклонения.
3. Что: классификация каждого расхождения — дата съехала, доход не признан, возврат не зафиксирован, технический сбой платежа. Чем: тот же ИИ-модуль по фиксированным правилам. Куда: тикет в CRM или карточка задачи финансисту.
4. Кто и когда смотрит: финансист — ежедневно, руководитель отдела — на еженедельном разборе. В одной из компаний время финансового планирования специально перенесли с утра на 13:00 четверга, чтобы к моменту разбора данные успевали собраться полностью, а не наполовину.

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

ИИ-связка: сопоставление CRM и кассы

Здесь машина делает за вас скучную часть: сопоставляет строки и приносит список расхождений с причинами. Вам остаётся решить, что с ними делать.

Схема конвейера простая: почасовой или ежедневный вебхук из CRM → таблица с историей версий → сравнение текущей и предыдущей выгрузки → модель классифицирует найденные отклонения → уведомление финансисту при превышении порога.

Для шага классификации не нужна дорогая модель — задача сводится к сопоставлению по чётким правилам, а не к творческой генерации. Дешёвая модель уровня GPT-4o-mini справляется с этим за секунды и обходится примерно в 200–400 ₽/мес при объёме в сотни строк в день (оценка). Дорогую модель имеет смысл подключать только там, где нужно разобрать неструктурированный комментарий менеджера о причине расхождения — это отдельный, более редкий шаг.

Ты — модуль сверки платежей. На входе два JSON-массива:
1) deals — сделки из Bitrix24 (поля: ID, OPPORTUNITY, DATE_CREATE,
   DATE_MODIFY, STAGE_ID, CONTACT_ID, prev_date_create — дата создания
   из предыдущей выгрузки для той же сделки);
2) payments — платежи из банковской выписки (поля: date, amount,
   purpose, counterparty).

Данные:
deals: {{deals_json}}
payments: {{payments_json}}

Задача:
1. Сопоставь сделки и платежи по сумме (допуск ±1%) и контрагенту.
2. Если сделке из CRM не найден платёж в течение 5 рабочих дней
   после DATE_MODIFY при статусе "оплата ожидается" — пометь как
   риск "платёж_не_найден".
3. Если платёж найден, но сумма отличается более чем на 1% —
   пометь как риск "расхождение_суммы" и укажи разницу.
4. Если DATE_CREATE отличается от prev_date_create — пометь как
   риск "дата_сдвинулась" и укажи сдвиг в часах.
5. Верни только JSON-массив расхождений без пояснений и без markdown.

Пример ответа модели на реальной структуре данных:

[
  {"deal_id": "48213", "type": "дата_сдвинулась", "shift_hours": 36},
  {"deal_id": "48250", "type": "платёж_не_найден", "amount": "180000", "days_overdue": 6},
  {"deal_id": "48266", "type": "расхождение_суммы", "crm_amount": "150000", "payment_amount": "142000", "diff": "8000"}
]

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

Инженерная обвязка: скрипт крутится по расписанию — облачная функция или сервер компании, запуск раз в час, дёргает Bitrix24 REST API и выгрузку из банка/1С. История версий хранится в отдельной таблице, чтобы было с чем сравнивать текущую дату создания. При ошибке вебхука — таймаут или 5xx от Bitrix24 — три повторные попытки с интервалом 5 минут, после чего алерт в телеграм-канал финансиста. Отдельный алерт — если сумма найденного расхождения превышает заданный внутренний порог: такие случаи не должны ждать еженедельного разбора.

На диаграмме ниже — движение одного резервного фонда за месяц из практики разбора: при обороте компании около 9 млн ₽/мес расхождение даже в 3–5% от согласуемых расходов — это 270 000–450 000 ₽ в месяц (оценка), которую никто не объяснит постфактум, если не сверять регулярно.

В другом разборе — не связанном с этим фондом — точно так же всплыл необъяснённый рост фонда заработной платы без единого нового найма, в объёме около 300 000 ₽ — сопоставимо с месячным резервом на непредвиденные расходы (оценка на масштабе условной компании): к нему я вернусь ниже отдельно, чтобы не смешивать два разных кейса в одной сумме.

Экономика: что стоит и что даёт

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

Настройка сверки — 12–22 часа разработчика на старте, эксплуатация — 200–400 ₽/мес на вызовы модели, эффект — высвобождение около 48 000 ₽/мес стоимости рабочего времени финансиста (оценка, расчёт ниже) плюс более раннее обнаружение кассовых разрывов на десятки-сотни тысяч рублей.

Формула для прикидки своего случая: (часы в день на ручную сверку) × (часовая ставка сотрудника, который её делает) × (рабочих дней в месяце) = скрытые трудозатраты в месяц. Разовые часы на настройку × ставка разработчика — это стоимость внедрения. Разделите одно на другое — получите срок окупаемости в месяцах.

Пример расчёта окупаемости: суммарно на настройку уходит 12–22 часа, возьмём верхнюю границу. При типичной ставке разработчика это разовое вложение, которое соотносится с ежемесячной экономией времени сотрудника (расчёт ниже) как примерно 1,5 к 1 — то есть окупаемость около полутора месяцев.

Считаю эффект только от самой сверки, не смешивая с соседними инициативами вроде контроля дебиторки или прослушки звонков. Полная стоимость сотрудника, который вручную ищет расхождения, для компании обычно выше, чем его оклад: базовая ставка плюс налоги и отчисления (около половины ставки сверху) плюс сопутствующие затраты на рабочее место и инструменты — полная стоимость такого специалиста для компании обычно вдвое превышает оклад «на руки». Возьмём для примера финансиста с окладом 80 000 ₽ на руки — полная стоимость для компании тогда около 160 000 ₽/мес. Если автоматическая сверка освобождает порядка 30% его времени — это около 48 000 ₽/мес его стоимости для компании, которую можно перераспределить на работу с дебиторкой или клиентами вместо ручного поиска расхождений в таблицах. Это оценка, а не измеренный факт: часы финансиста не исчезают из штатного расписания, они переходят на другую работу — сам по себе этот сдвиг не equals прямому доходу компании.

Второй эффект — не количество часов, а скорость обнаружения риска. В одном из разборов при типичных для компании такого масштаба месячных расходах и выручке компания обнаружила дефицит кэша около 700 000 ₽ — это около 8% месячного оборота — только по факту: когда денег не хватило даже на зарплаты. Регулярная сверка с ежедневным просмотром метрик не устраняет сам дефицит, но переносит момент его обнаружения на недели раньше, пока ещё есть время договориться о кредитной линии или перенести необязательный платёж — а не решать вопрос за полчаса, потому что подрядчику «нужно прямо сейчас».

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

На диаграмме — разрыв между плановым лимитом и фактической потребностью из истории с проектной услугой:

Лимит фонда на финансирование этапа работ был установлен на уровне, который оказался на порядок меньше нужного, а реальная потребность на пике оказалась почти в девять раз выше плана. Разрыв не виден ни в CRM, ни в плановом бюджете, если не сверять фактический расход с фактическим объёмом работ помесячно.

Что делать вам, если расхождения уже накопились

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

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

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

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

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

Чек-лист: с чего начать в понедельник

• Выгрузить сделки за последний месяц из CRM и платежи из банка или кассы в одну таблицу — вручную, без автоматизации, просто чтобы увидеть масштаб расхождения.
• Договориться об одной методологии признания дохода на всю компанию: по факту поступления денег, а не по дате договора.
• Завести отдельный регистр возвратов с полями «удержано», «возвращено», «причина» — и назначить, кто его ведёт.
• Настроить регулярную, хотя бы ежедневную, выгрузку данных из CRM с сохранением истории версий, чтобы ловить сдвиги дат до того, как они превратятся в расхождение по сумме.
• Назначить фиксированное время и владельца еженедельной сверки — не «когда попросят», а по календарю.
• Проверить, что перенесённые или отложенные платежи не «зависают» технически и не требуют забытого вручную повторного запуска.

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

Как автоматизировать сопоставление и получать расхождения списком, а не искать их руками, — в бесплатном курсе.

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

Частые вопросы

Почему в CRM одна сумма по сделке, а в кассе другая?

Чаще всего это разный момент фиксации: CRM показывает договор, касса — фактическое поступление денег, а между ними могут быть возвраты, комиссии или частичная оплата.

Как проверить, что даты сделок в CRM не съезжают?

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

Кто должен фиксировать возвраты клиентам?

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

Это то же самое, что акт сверки взаиморасчётов?

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

#автоматизация #ошибки и провалы #деньги