Не «ИИ вместо бухгалтерии», а управляемая очередь счетов

Счета от поставщиков редко приходят в одном удобном шаблоне. Меняются расположение реквизитов, качество скана, количество строк, язык и формат приложений. Если автоматизация держится на наборе правил для каждого макета, новый поставщик означает очередную настройку. Именно эту операционную проблему описывает австралийская Ellby, поставщик систем документооборота и обработки счетов для более чем 400 организаций.

В опубликованном AWS кейсе Ellby сообщает, что прежде автоматизировала менее 60% счетов, на настройку профилей крупных поставщиков для одного клиента уходило от 24 часов, а поддержка шаблонов требовала более 300 часов в месяц. После внедрения обработки через модели Claude Sonnet и Haiku в Amazon Bedrock компания заявляет об автоматизации более 94% счетов и сокращении времени подключения клиента более чем на 55%. Это результаты конкретного поставщика на его потоке и в его определении «автоматизации», а не обещание для российской бухгалтерии.

Что в этом кейсе действительно работает

Ellby не поручила модели безусловно проводить документы. По описанию AWS, модель извлекает данные из счетов разного вида; затем собственный движок правил проверяет результат. Документы с низкой уверенностью направляются человеку. Такой порядок важнее выбора названия модели: генерация предлагает структурированные поля, а принятие документа зависит от бизнес-правил и ответственного сотрудника.

Для небольшой компании это можно представить как четыре последовательных этапа:

  • Входящий счет попадает из почты, ЭДО или сканирования в единый реестр с исходным файлом и идентификатором.
  • Распознавание и модель выделяют поставщика, ИНН, номер и дату, валюту, позиции, суммы и налоговые поля — только те данные, которые нужны конкретному процессу.
  • Проверка сопоставляет поля с карточкой контрагента, заказом, договором, арифметикой и правилами дубликатов. Отсутствующее или противоречивое поле не подставляется «по смыслу».
  • Ответственный видит источник каждого спорного значения, исправляет или отклоняет счет. В учетную систему попадает только принятый результат; все действия сохраняются в журнале.

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

Какие данные и интеграции понадобятся

Для пилота достаточно выгрузки 100–200 недавних счетов от разных поставщиков вместе с итоговыми исправлениями бухгалтерии. Выборка должна включать не только аккуратные PDF, но и сканы, многостраничные документы, корректировки, новые формы и дубликаты. Иначе тест покажет качество на «лёгкой» части потока.

Минимальные интеграции — источник документов, справочник контрагентов, при необходимости заказы или договоры, тестовый контур учётной системы и очередь ручной проверки. Часто именно нормализация карточек поставщиков и правила сопоставления занимают больше времени, чем вызов модели. Для российского бизнеса нужно заранее проверить, какие реквизиты обязательны в его учете, как устроен обмен с 1С или другой системой и где допустимо обрабатывать финансовые данные. Австралийская инфраструктура из кейса не является готовым ответом на эти вопросы.

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

Как считать результат без самообмана

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

Для стартовой модели можно взять 1 000 счетов в месяц. Пусть ручная первичная обработка занимает 6 минут на счет — это 100 часов. Если 70% документов после автоматической проверки действительно проходят без исправлений, а оставшиеся 30% требуют тех же 6 минут, экономия первичной работы составит около 70 часов до учета выборочного контроля и сопровождения. Это примерный расчет с явными допущениями, не результат Ellby и не прогноз для читателя. Измерения на реальном потоке могут дать другую цифру.

Особенно важно разделять «извлечено поле», «пройдено правило» и «документ проведен без ошибки». Считайте точность по критичным полям, число возвратов и исправлений, время до принятия, долю исключений и стоимость каждого исхода. Метрики Ellby опубликованы в кейсе ее технологического партнера AWS и не сопровождаются открытой независимой методикой проверки. Использовать их как ориентир для вопросов можно; переносить как норматив эффективности — нельзя.

Где оставить человека в цепочке

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

Разумный первый шаг — двухнедельный «теневой» прогон: ИИ заполняет поля, но ничего не проводит. Бухгалтер сравнивает результат с обычной обработкой, отмечает причины расхождений и собирает базовые метрики. После этого можно решить, стоит ли автоматизировать узкую группу поставщиков, менять правила или вообще отказаться от модели. Ценность кейса Ellby не в магических 94%, а в связке гибкого извлечения с проверяемыми правилами и управляемыми исключениями.