Интеграция с Т-Банком связывает поступление со счётом в CRM, а агенты проверяют соответствие оплаты

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

У Т-Банка есть готовый сценарий: выставить счёт через T-API и получить его статус. В документации для оплаты через входящий счёт Т-Бизнеса описана банковская сверка по идентификатору платежа. Если этот путь подходит вашей компании, в CRM надо перенести полученный статус и сохранить связь со счётом на оплату.

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

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

T-API позволяет читать операции по счёту за период. Документация различает неподтверждённую авторизацию и подтверждённую транзакцию. Для правил этой интеграции зачёт начинается с подтверждённого входящего платежа; раннее движение по счёту ещё не повод разрешать отгрузку.

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

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

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

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

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

В задании ИИ-агенту нужны примеры ожидаемого результата. Вместо «сверяй корректно» передайте обезличенные пары «платёж и счёт» и состояние CRM после обработки. Таблица ниже может стать началом такой приёмки.

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

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

В журнале машины видно, как устроена разработка vibecoding.ru. Наш близкий пример относится к кассе курса: ревью 9 сентября 2026 выявило ошибки в связи оплаты, товара и доступа. Эта касса работает с другим платёжным сервисом, поэтому её опыт переносится как способ проверки, а не как готовая интеграция Т-Банка.

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

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

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

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

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

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

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

На странице разработки по подписке тариф «Один проект» стоит 250 000 ₽ в месяц на 8 октября 2026. В нём один поток: одна задача в работе, остальные ждут в очереди. Можно поставить подписку на паузу в любой месяц.

В рамках этой задачи инженер ведёт машину агентов: пишет с ними чтение поступлений доступными методами T-API и сопоставление со счетами CRM. Код остаётся в репозитории клиента. Приёмка включает частичную оплату, неопознанный платёж, повторы и ручное подтверждение спорного совпадения.

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

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

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

2. Запишите правила зачёта до кода. Определите однозначное совпадение, частичную оплату и случаи для сотрудника.

3. Принимайте результат в CRM. Повтор не увеличивает оплату, часть суммы не закрывает счёт, неопознанный платёж виден в очереди.

4. Замкните проверку на исключения. Сохраните решение сотрудника, исправьте правило и повторите прогон.

5. Разделите бюджет. Подписка оплачивает поток разработки; лицензии, комиссии и работа интеграции считаются отдельно.