Обработка входящих счетов в малом и среднем бизнесе почти всегда устроена одинаково: инвойс приходит на почту, бухгалтер открывает PDF или скан, перебивает реквизиты, позиции и суммы в банк и учётную систему, руководитель подтверждает платёж. Пока счетов несколько в неделю, схема живёт. Когда поставщиков становится десятки, а письма идут потоком, ручной путь начинает рваться: счета теряются в переписке, цифры перебиваются с ошибками, оплаты уходят с опозданием. В этой статье разберём, где именно ломается ручной процесс и как выглядит автоматизация, в которой ИИ достаёт данные из документа, платёжку формирует детерминированный код, а подтверждает её человек.
Где ломается ручная обработка входящих счетов
Один счёт — простая задача: открыть, прочитать, оплатить. Проблема начинается на объёме. Сначала счёт нужно найти в почте среди рассылок, трекингов и рабочей переписки. Потом понять, что перед вами именно счёт на оплату, а не проформа, акт сверки или обновлённый прайс. Дальше — самое уязвимое место всего процесса: данные из PDF перебиваются руками в банк и в учётную систему.
Отдельная сложность — контекст. У импортёра счета приходят на разных языках, в разных валютах, со своими условиями оплаты, отсрочками и скидками за объём. Чем разнообразнее поставщики, тем больше знаний держит в голове один конкретный человек — и тем болезненнее для компании его отпуск, больничный или увольнение.
На этом пути стабильно повторяются одни и те же сбои:
- потерянные счета — письмо ушло в общую папку, никто не отреагировал, поставщик напоминает о себе позже уже с претензией;
- ошибки ввода — переставленные цифры в сумме или номере счёта; во что это выливается на практике, мы подробно разбирали в статье об ошибках ручного ввода;
- двойные оплаты — один и тот же инвойс пришёл дважды: в исходном письме и в напоминании, и оба раза попал в оплату;
- сорванные сроки — счёт со скидкой за раннюю оплату дождался своей очереди и потерял выгоду.
Важно честно признать: ни один из этих сбоев не лечится призывом «внимательнее проверять». Внимание — исчерпаемый ресурс. К концу потока счетов за неделю оно заканчивается у любого, даже очень аккуратного человека.
Автоматический разбор счетов на оплату: механика по шагам
Теперь посмотрим, как тот же путь выглядит, когда рутину забирает система. Опишем механику на примере HORUVIA — ИИ-оператора бизнеса, который работает с почтой и документами компании. Принцип здесь важнее конкретного продукта, и он простой: ИИ работает с текстом, детерминированный код работает с деньгами, человек принимает решение.
Шаг 1. Счёт сам находит своё место
Система подключается к почтовому ящику по IMAP и разбирает входящий поток: отделяет счета от прайсов, актов и обычной переписки, привязывает каждое письмо к конкретному поставщику и бренду. Если документ пришёл сканом или фотографией, подключается OCR — распознавание превращает картинку в текст, с которым можно работать дальше. Счёт больше не нужно искать: он появляется в системе с пометкой, от кого пришёл и что содержит.
Шаг 2. ИИ извлекает данные из инвойса
Дальше языковая модель вытаскивает из документа структуру: поставщика, номер и дату счёта, валюту, позиции, суммы, реквизиты, срок оплаты. Это именно та задача, где генеративный ИИ силён: форматы инвойсов у всех поставщиков разные, жёсткими шаблонами их не покрыть, а модель уверенно справляется с разнобоем вёрстки, языков и формулировок. Результат шага — не платёж, а структурированные данные, которым ещё предстоит пройти проверку.
Шаг 3. Инвойс в платёжное поручение превращает код, а не нейросеть
Само превращение инвойса в платёжное поручение — работа детерминированного кода. Это обычная программа, которая на одних и тех же входных данных всегда выдаёт один и тот же результат. Код берёт извлечённые данные, сверяет реквизиты с карточкой поставщика в памяти системы, проверяет суммы и формирует черновик платёжки. Никакой генерации на этом этапе нет. Если реквизиты не совпали с известными, черновик не создаётся молча — расхождение поднимается человеку как отдельный вопрос.
Шаг 4. Человек проверяет и подтверждает
Последнее слово всегда за человеком. Бухгалтер или руководитель видит черновик платежа рядом с исходным документом: что извлечено, с чем сверено, где совпало, а где нет. Подтверждение — осознанное действие, а не машинальный клик по привычке. Система не отправляет деньги сама: она убирает перебивание руками, но не убирает контроль.
Почему деньгам нельзя доверять генеративную модель напрямую
Этот момент принципиальный, поэтому остановимся отдельно. Генеративная модель по своей природе вероятностна: она предсказывает наиболее правдоподобный ответ, а не вычисляет гарантированно верный. Для черновика письма это приемлемо. Для платёжного поручения — нет, потому что «правдоподобная» сумма и правильная сумма — разные вещи.
- модель может галлюцинировать — уверенно выдать реквизит или сумму, которых в документе нет;
- одинаковый вход не гарантирует одинаковый выход, а платёж обязан быть воспроизводимым и предсказуемым;
- решение модели трудно разобрать постфактум — у неё нет журнала «почему я так посчитала» в привычном для аудита смысле.
Это не значит, что языковая модель бесполезна — это значит, что у неё есть своя зона ответственности. Чтение неструктурированного документа, классификация письма, извлечение полей — задачи, где вероятностная природа модели уместна, потому что результат в любом случае проверяется на следующем шаге. А вот арифметика, сверка реквизитов и формирование платёжного документа — территория обычного кода, который можно протестировать, зафиксировать и при необходимости предъявить аудитору строку за строкой.
Поэтому граница в архитектуре проведена жёстко: ИИ читает и извлекает, детерминированный код сверяет и формирует, человек подтверждает. У генеративной модели нет прямого доступа к деньгам ни на одном этапе. Отдельный вопрос — какие данные вообще уходят модели и как они защищены; этому посвящён материал о безопасности данных при работе с ИИ.
Счета от поставщиков: учёт и память системы
Разовая обработка документа — только половина ценности. Вторая половина в том, что учёт счетов от поставщиков накапливается в память: система помнит каждого контрагента, его документы, реквизиты и историю цен. Такая память нарабатывается на живых кейсах импорта — по каждому поставщику накапливаются реквизиты, история поставок и цен, сроки действия сертификатов.
Память превращает каждый новый счёт из изолированного документа в событие с контекстом:
- цена позиции заметно отличается от прошлых поставок — это повод разобраться до оплаты, а не после;
- реквизиты в счёте внезапно «поменялись» — классическая схема мошенничества с подменой инвойса ловится сверкой с карточкой поставщика;
- сертификат поставщика подходит к концу срока — система предупредит заранее, а не когда груз уже стоит на таможне.
Что происходит после оплаты: алерты и сроки
Обработанный счёт встраивается в общий контур напоминаний. В Telegram приходят алерты: пришёл новый инвойс, в письме оферта с дедлайном, письмо поставщику осталось без ответа слишком долго. Дедлайн-движок ведёт сроки по договорам, декларациям и страховкам и предупреждает заранее, в несколько шагов по мере приближения даты, — счёт перестаёт быть единственным документом, за которым нужно следить вручную.
Та же дисциплина работает и в обратную сторону — по деньгам, которые должны вам. Как выстроить систематические напоминания клиентам, мы разбирали в статье о работе с дебиторкой.
Как это встраивается в текущие процессы
Автоматизация обработки счетов не требует ломать существующий учёт. Система работает поверх привычных инструментов: почта остаётся почтой, банк — банком, учётная программа — учётной программой. Обмен с 1С поддерживается на базовом уровне, поэтому данные разобранных счетов не приходится вносить в учёт второй раз. Если часть документов живёт не в почте, а в папках на компьютере — например, сканы, которые приносит менеджер по закупкам, — агент на ПК следит за папкой и сам передаёт новые файлы на сервер.
Стартовая настройка тоже не начинается с чистого листа. Для типовых сегментов — импорт и ВЭД, розница на маркетплейсах, услуги, HoReCa, логистика — есть онбординг-пресеты: наборы правил разбора и типов документов, характерных для каждого сегмента. Разобранные счета и связанные с ними задачи попадают на канбан-доску, а по импортным поставкам «Пульс компании» показывает грузы по этапам — от инвойса до прихода на склад.
Что остаётся человеку
Автоматический разбор счетов на оплату не делает бухгалтера лишним — он убирает из его дня механическую часть: поиск писем, перебивание цифр, ручную сверку реквизитов. Остаётся то, что действительно требует человека: решение платить или не платить, разбор расхождений, общение с поставщиком, когда что-то пошло не так. Система готовит фактуру для этих решений и следит, чтобы ни один счёт не потерялся по дороге. В командах, где счета идут потоком, это постепенно меняет саму роль бухгалтерии: из операторов ввода данных люди превращаются в контролёров и переговорщиков.
Честная оговорка: автоматизация не отменяет наведение порядка. Если реквизиты поставщиков нигде не собраны, а договорённости живут в головах, первые недели уйдут на то, чтобы система накопила память. Зато дальше каждый новый счёт будет попадать в уже выстроенный контекст.
С чего начать
Если поток счетов у вас уже перерос ручной режим — счета теряются, оплаты задерживаются, а бухгалтер занят перебиванием цифр вместо анализа, — посмотрите, как это работает вживую. Прикиньте, сколько часов в месяц уходит на ручную обработку, на калькуляторе экономии, загляните в ответы на частые вопросы или запросите демо на главной странице HORUVIA — покажем путь «письмо → черновик платёжки → подтверждение» на ваших собственных счетах.