Автоматизация выставления счетов без бухгалтера в 2026

Автоматизация выставления счетов это не одна кнопка в CRM (системе управления клиентами), а цепочка из пяти звеньев, и рвётся она обычно на последнем.

Содержание:

→ Сколько на самом деле стоит счёт, выставленный руками
→ Из чего состоит автоматизация выставления счетов
→ Три схемы связки под разные типы бизнеса
→ Как выглядит связка в работе: событие, данные, документ
→ Обратный поток: что должно вернуться в CRM после оплаты
→ Чек‑лист перед запуском: что проверить, чтобы счета не поехали
→ Где автоматизация не заменит бухгалтера

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

Сколько на самом деле стоит счёт, выставленный руками

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

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

Дальше цепочка рвётся ещё в трёх местах:

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

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

Поэтому автоматизировать имеет смысл не только создание документа, но и весь путь счёта до отметки об оплате в сделке.

Из чего состоит автоматизация выставления счетов

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

1. Событие в CRM. Сделка перешла в нужный статус, появился новый заказ, менеджер отметил готовность к оплате. Это команда на старт.
2. Сбор данных. Связка берёт из карточки реквизиты контрагента, позиции, сумму, ставку НДС (налог на добавленную стоимость) или её отсутствие, срок оплаты.
3. Создание документа. Счёт формируется в сервисе, у которого есть на это право: в бухгалтерском сервисе, платёжном сервисе или системе учёта.
4. Доставка клиенту. Письмо с файлом, ссылка на оплату или сообщение в мессенджер, в зависимости от того, как клиенту удобнее платить.
5. Возврат оплаты в CRM. Факт оплаты возвращается в сделку, меняет её статус и снимает задачу с менеджера.

Главное здесь третье звено. В большинстве связок CRM не выставляет счёт: она даёт событие и данные, а документ создаёт внешний сервис. Заметное исключение это Битрикс24, где счёт это объект самой CRM.

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

Связать эти звенья между собой можно в Альбато, no‑code платформе (связки собирают без программиста) с каталогом на 1 000+ коннекторов: она соединяет CRM с сервисами, которые формируют счета и принимают оплату.

Три схемы связки под разные типы бизнеса

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

Схема А, услуги и агентства. Источник события это amoCRM с триггером «Обновлен статус сделки». Дальше в дело вступает Контур Эльба: действие «Создать контрагента» заводит клиента, если его ещё нет, а «Создать исходящий счёт» формирует сам документ. Когда работа сдана, тем же способом создаётся акт через «Создать исходящий акт».

Схема Б, онлайн‑оплаты. Здесь счёт и оплата это одно действие. Эквайринг CloudPayments умеет «Создание счета для отправки по почте» и версию с чеком, а Robokassa отдаёт действие «Сформировать ссылку на оплату», которую менеджер тут же отправляет клиенту. Механику одного платёжного сервиса подробно разбирает материал про то, как связать Robokassa с CRM и обновлять статусы оплат.

Схема В, товарный бизнес и учёт. Событием становится заказ: МойСклад отдаёт триггер «Заказ создан», а Битрикс24 закрывает весь путь внутри себя действиями «Добавить счет» и «Добавить товарную позицию». Тем, у кого склад и заказы уже собраны в одном месте, пригодится разбор про МойСклад как единый источник заказов и остатков.

Отдельная история это компании, у которых учёт уже ведётся в 1С. Коннектор 1C (так карточка называется в каталоге Альбато) умеет «Создать запись в Документе» и «Поиск записи в Документе», а как именно связывают бухгалтерию с продажами, показано в материале про то, как связать 1С с amoCRM и Битрикс24.

amoCRM и Битрикс24 ведут себя здесь по‑разному. В Битрикс24 счёт это объект самой CRM, и в каталоге Альбато у него есть собственные триггеры «Счёт создан», «Счёт обновлён», «Счёт удалён» плюс действия «Добавить счет» и «Удалить счет». У amoCRM счета внутри системы тоже есть, но в каталоге Альбато у этого коннектора нет ни триггеров, ни действий по счетам, поэтому в связке документ создаёт внешний сервис.

Как выглядит связка в работе: событие, данные, документ

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

1. Ловим событие. «Обновлен статус сделки» в amoCRM, «Изменение сделки» или «Сохранен заказ» в Битрикс24, «Заказ создан» в МойСкладе. Одно событие на всю связку, иначе счета начнут дублироваться.
2. Проверяем условие. Счёт нужен не на каждую сделку: например, только выше определённой суммы или только для юрлиц. Условие отсекает лишнее до создания документа.
3. Ищем контрагента. Действия «Найти контрагента» в Контур Эльба и «Поиск контакта» в amoCRM нужны, чтобы у повторного клиента не появился второй профиль в бухгалтерии.
4. Собираем данные счёта. Реквизиты, позиции, сумма, срок оплаты, ставка налога. Эти данные связка берёт из полей сделки, поэтому пустое поле здесь равно несозданному счёту.
5. Создаём документ. Одно действие в выбранном сервисе: «Создать исходящий счёт», «Добавить счет» или «Создание счета для отправки по почте».
6. Оставляем след в CRM. Номер и сумма счёта пишутся обратно в сделку через «Новое примечание» в amoCRM или «Комментарий в таймлайн» в Битрикс24. Без этого менеджер не знает, выставлен счёт или нет.
7. Отправляем клиенту. Письмо, ссылка на оплату или сообщение в мессенджер, дальше связка ждёт события об оплате.

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

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

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

Обратный поток: что должно вернуться в CRM после оплаты

Именно обратный поток даёт основную экономию, а не создание документа. Создание счёта руками это минуты, а вот ручная сверка банка съедает вечер руководителя каждую неделю.

Событие оплаты приходит из одного из трёх источников:

• Эквайринг. Эквайринг CloudPayments отдаёт триггер «Уведомление об успешной операции (Pay)» сразу после оплаты картой.
• Платёжная ссылка. Robokassa отдаёт «Оповещение об оплате», как только клиент завершил платёж.
• Расчётный счёт. Безналичные оплаты ловят через Т‑Бизнес и его триггер «Получить выписку по счету клиента за определенный период».

По этому событию связка делает три вещи: обновляет сделку через «Обновление сделки по ID» в amoCRM или «Комментарий в таймлайн» в Битрикс24, уведомляет менеджера в мессенджере и снимает с него задачу на контроль оплаты.

Тишина тоже должна быть событием. Если счёт не оплачен через оговорённый срок, менеджер получает задачу («Новая задача» в amoCRM), а не узнаёт об этом случайно через месяц. Так напоминание об оплате перестаёт зависеть от памяти конкретного человека.

Частичная оплата это отдельная ветка, а не частный случай. Если её не заложить, сделка перейдёт в «Оплачено» после первого же аванса, и остаток никто не проконтролирует. Правильно так: пометка в сделке, задача менеджеру, статус остаётся прежним до полной суммы.

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

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

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

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

1. Поля реквизитов есть в карточке и заполняются. Название, ИНН, КПП (код причины постановки на учёт) для юрлиц. Поле необязательное на словах равно пустому на деле.
2. Определён налоговый режим. Ставка НДС или её отсутствие должны быть заданы заранее, иначе сервис сформирует счёт не по вашим правилам.
3. Нумерация не задваивается. Номер счёта присваивает один сервис. Если номера параллельно генерят и CRM, и бухгалтерия, у вас будет два счёта с одним номером.
4. Тест на трёх‑пяти сделках разных типов. Физлицо, юрлицо, частичная оплата. Тестировать надо до включения на весь поток, а не после.
5. Назначен человек для еженедельной сверки. Автоматика не отменяет контроль, она меняет его частоту: раз в неделю вместо каждого вечера.
6. Есть ветка на случай сбоя. Если счёт не создался, менеджер получает задачу. Молчание автоматики хуже, чем её отсутствие.

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

Где автоматизация не заменит бухгалтера

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

За человеком остаются четыре зоны:

• Отчётность и налоги. Декларации, взносы, сроки. Ни одна связка их не подготовит и не сдаст.
• Сверка с контрагентами и закрытие периода. Здесь нужен человек, который смотрит на картину целиком, а не на отдельную сделку.
• Закрывающие документы по нестандартным договорам. Этапы, авансы, зачёты. Счёт на оплату сам по себе не закрывает сделку, закрывают акт или накладная.
• Спорные ситуации. Возвраты, переплаты, неверное назначение платежа. Их разбирают руками, и это нормально.

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

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

Для счетов эта граница проходит понятно. Автоматика собирает документ по данным сделки, отправляет его клиенту и ловит оплату, а бухгалтер занимается учётом, а не перепечатыванием реквизитов.

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