точка банк + битрикс24: платежи в CRM без ручной сверки

какую проблему это решает

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

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

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

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

что умеет интеграция

Связка строится на банковском API и работает в обе стороны. Ниже — что реально настраивается.

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

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

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

как это выглядит в работе

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

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

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

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

как настраивается

Шаг 1. Доступ к банковскому API. В интернет-банке выпускается токен для интеграции с ограниченными правами — только чтение выписки и, если нужно, создание платёжных ссылок. Управление деньгами через этот доступ невозможно, платежи из CRM не отправляются.

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

Шаг 3. Правила сопоставления. Самая содержательная часть. Определяем порядок: сначала ищем номер счёта в назначении платежа, потом ИНН плательщика, потом точное совпадение суммы. Отдельно решаем, что делать с частичными оплатами и переплатами.

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

Шаг 5. Тест на реальных платежах. Неделю смотрим, как отрабатывает сопоставление: сколько платежей привязалось само, какие ушли в неопознанные и почему. По результатам правила уточняются. Эта неделя входит в работу.

подводные камни

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

Оплата от третьего лица. Счёт выставлен на одну компанию, платит связанное юрлицо или директор как физлицо. По ИНН такой платёж не сопоставится. Если это регулярная практика, нужно завести в CRM список связанных плательщиков.

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

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

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

сколько стоит и когда окупается

Объём работ зависит от того, насколько сложные у вас правила сопоставления. Базовая настройка — подключение, выписка, привязка по номеру счёта и уведомления — это 8–12 часов. С платёжными ссылками, обработкой частичных оплат, возвратов и связанных плательщиков — 16–24 часа.

Разбивка по шагам на типовом проекте: выпуск токена и подключение к порталу — 2 часа; разбор ваших назначений платежа и настройка правил сопоставления — 4 часа; реакция на платёж (стадия, уведомление, автозадача) — 2 часа; список неопознанных поступлений и права доступа — 2 часа; неделя наблюдения и уточнение правил — 2 часа. Итого 12 часов на полноценный базовый сценарий.

Теперь окупаемость на конкретном примере. Компания с 15 платежами в день тратит на сверку около 40 минут ежедневно — это примерно 14 часов в месяц работы бухгалтера, которая не создаёт ничего нового. Плюс менеджеры узнают об оплате в среднем на день позже, чем деньги пришли, и на этот же день сдвигается отгрузка — то есть и получение следующего заказа от этого клиента.

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

что потребуется от вас

Часть шагов нельзя сделать без вас — банковские доступы и решения про деньги остаются на стороне компании. Вот что нужно подготовить.

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

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

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

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

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