ИИ для проверки бухгалтерских документов: что умеет и как применять

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

ИИ для проверки бухгалтерских документов: рамка-сканер сверяет листы и выделяет дубликат

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

Какие ошибки в первичке находит ИИ

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

Формальные дефекты реквизитов машина находит практически безошибочно, если у неё есть доступ к внешним справочникам.

  • ИНН и КПП, которые проходят проверку контрольного разряда, но принадлежат другой организации, чем указана в шапке
  • Контрагент, находящийся в процессе ликвидации или уже исключённый из ЕГРЮЛ на дату документа
  • Расхождение наименования организации с выпиской, включая смену формы с АО на ООО
  • Отсутствие обязательных реквизитов первичного документа по статье 9 закона о бухгалтерском учёте
  • Подпись без расшифровки, без указания должности или без действующей доверенности
  • Номер и дата, не соответствующие сквозной нумерации поставщика, что часто указывает на переделанный документ

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

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

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

  • Цена выше согласованной спецификацией или прайс-листа в приложении
  • Поставка номенклатуры, отсутствующей в перечне по договору
  • Акт, датированный раньше даты заключения договора или позже окончания его срока
  • Отсутствие ссылки на договор и заявку, из-за чего документ невозможно связать с обязательством
  • Условия оплаты в счёте, противоречащие согласованной отсрочке

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

  • Один и тот же документ, загруженный дважды с разными номерами или через разные каналы
  • Накладная без счёта-фактуры при общей системе налогообложения
  • Закрывающие документы, не поступившие по оплаченному авансу
  • Документ, полученный после закрытия периода, по которому уже сдана отчётность
  • Неподписанный со стороны организации документ в системе электронного документооборота, формально считающийся неполученным

Почему эти ошибки обычно находят поздно

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

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

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

Чего ИИ в документах не увидит

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

  • Деловую цель операции и её экономическую обоснованность машина не оценивает, это зона ответственности руководителя и главного бухгалтера
  • Реальность поставки подтверждается складскими документами и людьми, а не формальной корректностью накладной
  • Признаки искусственного дробления бизнеса или технического характера контрагента видны по совокупности данных вне документооборота
  • Устные договорённости, не зафиксированные ни в договоре, ни в переписке, для системы не существуют
  • Правомерность применения конкретной льготы требует профессионального суждения, модель лишь подсвечивает основание для сомнения

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

Форматы документов: бумага, скан, PDF, ЭДО

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

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

  1. Файл в формате ФНС, то есть структурированный универсальный передаточный документ или счёт-фактура в виде XML. Все реквизиты уже разложены по полям, распознавание не требуется вообще, остаётся смысловая сверка
  2. PDF с текстовым слоем, выгруженный из учётной системы поставщика. Текст извлекается без потерь, структура восстанавливается с высокой точностью
  3. Скан бумажного документа на плоском сканере при разрешении от трёхсот точек на дюйм. Распознавание устойчивое, проблемы появляются на печатях и рукописных пометках
  4. Фотография документа с мобильного телефона. Перспективные искажения, тени, блики и неравномерная резкость заметно снижают точность
  5. Бумага без оцифровки. До появления файла автоматическая проверка невозможна в принципе

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

Как ИИ работает с плохими сканами и фото

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

  • Выравнивание перекоса и коррекция перспективы, из-за которых строки таблицы перестают распознаваться как единое целое
  • Повышение контраста для документов на термобумаге, где текст выцветает за несколько месяцев
  • Разделение слипшихся страниц многостраничного файла на отдельные документы по реквизитам, а не по номеру листа
  • Отделение печати и подписи от текста, который они перекрывают
  • Распознавание рукописных правок и дописанных от руки количеств, где точность принципиально ниже машинописного текста

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

Отдельно стоит договориться с поставщиками и собственными подразделениями о гигиене файлов. Простые требования дают прирост точности, сопоставимый со сменой программного решения.

  • Один документ в одном файле, без склеивания разных накладных в общий PDF
  • Сканирование без скрепок и загибов, с полным попаданием краёв документа в кадр
  • Отказ от пересъёмки экрана и от повторного фотографирования распечатанного скана
  • Осмысленные имена файлов с номером и датой, помогающие сопоставлению при сбоях распознавания

Что меняет машиночитаемая первичка

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

Параллельно появляются новые объекты контроля, о которых стоит знать заранее.

  • Машиночитаемая доверенность, у которой нужно проверять срок, объём полномочий и факт отзыва на дату подписания
  • Соответствие версии формата требованиям налоговой службы, поскольку устаревшие версии перестают приниматься
  • Расхождения между данными XML и его визуализацией в PDF, которые встречаются при доработках печатных форм на стороне поставщика
  • Корректность применения универсального корректировочного документа вместо исправленного экземпляра и наоборот
Смешанный документооборот надолго останется нормой. Разумная цель не в том, чтобы перевести всех контрагентов на электронные документы, а в том, чтобы каждый канал поступления имел описанный маршрут обработки и известный уровень доверия к данным.

От входящего документа до проверенной проводки в 1С

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

  1. Сбор документов из всех каналов в единую точку, включая операторов электронного документооборота, корпоративную почту, выгрузки из клиентских кабинетов и папку сканов
  2. Первичная классификация по типу документа, потому что проверки для акта, накладной, счёта-фактуры и платёжного документа различаются
  3. Извлечение реквизитов из структурированных данных или распознавание изображения с оценкой уверенности по каждому полю
  4. Идентификация контрагента по ИНН с обращением к реестру и подтверждением статуса на дату документа
  5. Привязка к договору, спецификации, заявке или заказу поставщику
  6. Сопоставление с ожидаемым событием в учёте, то есть с поступлением, оплатой или ранее выданным авансом
  7. Прогон арифметических и налоговых правил, включая ставки, итоги и округления
  8. Проверка на дубли по сочетанию поставщика, номера, даты, суммы и состава строк
  9. Формирование документа в учётной системе в виде черновика с заполненными реквизитами и предложенным счётом учёта
  10. Маршрутизация на подтверждение человеком в зависимости от уровня замечаний
  11. Фиксация следа проверки с указанием того, какие правила применялись и кто принял решение

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

Сверка с учётной системой и реестром ЭДО

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

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

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

Что делать с документами, по которым ИИ дал замечания

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

  1. Чистые документы с высокой уверенностью распознавания и без срабатывания правил проводятся автоматически, человек видит их только в сводном отчёте
  2. Документы с мелкими замечаниями вроде неуверенно распознанного поля или отсутствующей ссылки на договор отправляются оператору на подтверждение в один клик с подсветкой спорного места
  3. Документы с существенными расхождениями по сумме, налогу, контрагенту или условиям договора уходят к бухгалтеру участка и при необходимости формируют запрос поставщику

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

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

ИИ для проверки бухгалтерских документов: специалист снимает ложный маркер и расширяет автоматический поток

Сервисы ИИ для проверки бухгалтерских документов

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

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

Группа решений Где встраивается Сильная сторона Что остаётся за кадром
ИИ-модули учётных систем Внутри 1С или аналогичной платформы Готовое проведение документа и доступ к справочникам Сбор документов из внешних каналов
Специализированные сервисы по первичке Между каналом поступления и учётом Глубина распознавания и правил контроля Требуется интеграция с учётной системой
Платформы документооборота с ИИ На уровне всего потока документов компании Маршруты согласования и хранение Узкие бухгалтерские проверки нужно настраивать
Универсальные языковые модели Рядом с бухгалтером, вручную Разбор текста и нетиповые задачи Нет связи с учётными данными и воспроизводимости

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

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

  • Набор поддерживаемых типов документов, включая универсальный передаточный документ, корректировочные документы, акты сверки и путевые листы, если они у вас в обороте
  • Наличие готовой двусторонней интеграции с вашей версией учётной системы, а не просто выгрузки в табличный файл
  • Возможность редактировать правила контроля самостоятельно, без обращения к разработчику за каждую проверку

Платформы корпоративного документооборота с искусственным интеллектом подходят компаниям, где бухгалтерия — лишь один из участников согласования. Такие системы изначально построены вокруг маршрутов, прав доступа, хранения и юридической значимости, а распознавание и классификация добавлены как слой обработки. В эту группу входят отечественные платформы класса ECM и BPM, представленные в реестре российского программного обеспечения. Логика выбора здесь другая. Платформу берут под весь контур работы с документами, а бухгалтерские проверки настраивают внутри неё как один из сценариев, и окупается это при больших объёмах и множестве согласующих.

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

  • Нет доступа к учётным данным, поэтому сверка с 1С и реестром электронного документооборота невозможна
  • Арифметику модель считает текстом, а не калькулятором, и на длинных таблицах ошибается
  • Результат не воспроизводится дословно при повторном запросе, что мешает выстроить контроль
  • Нет следа проверки, пригодного для внутреннего аудита
  • Загрузка документов с персональными данными и коммерческой тайной в публичный сервис требует отдельного правового решения
Полезное разделение труда выглядит так. Правила и сверки отдают детерминированным механизмам, которые считают одинаково каждый раз. Понимание текста и неоднозначные формулировки отдают языковой модели. Решение по спорной операции оставляют человеку. Попытка решить все три задачи одним инструментом даёт худший результат на каждой.

Чат-ассистент или исполнительный агент

Это главное технологическое различие, которое стоит понимать до разговора с поставщиками. Чат-ассистент отвечает на вопрос и возвращает текст. Исполнительный агент получает задачу, сам обращается к системам, выполняет последовательность действий и возвращает результат в виде изменённого состояния учёта. Разница не в качестве модели, а в наличии прав и инструментов.

Параметр Чат-ассистент Исполнительный агент
Что делает с документом Разбирает загруженный файл и описывает найденное Забирает документ из канала и доводит до черновика проводки
Доступ к учётным данным Отсутствует или ограничен тем, что вставил человек Читает справочники, договоры, остатки и обороты
Повторяемость результата Варьируется от запроса к запросу Фиксируется регламентом и правилами
След проверки История переписки Журнал действий с указанием сработавших правил
Порог внедрения Начинается в тот же день Нужны интеграция, права доступа и настройка
Основной риск Уверенная ошибка в ответе, принятая на веру Массовое повторение неверно настроенного правила

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

Как выбрать решение под размер бухгалтерии

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

  1. До ста документов в месяц. Отдельная система контроля не окупится. Работают бесплатные проверки контрагентов, встроенные сервисы операторов электронного документооборота и языковая модель для разбора договоров и переписки
  2. От ста до пятисот документов. Имеет смысл ИИ-модуль внутри учётной системы плюс настройка выгрузки структурированных файлов из электронного документооборота. Основной эффект даёт отказ от ручного ввода реквизитов
  3. От пятисот до трёх тысяч документов. Окупается специализированный сервис с правилами контроля и интеграцией. Появляется смысл в разделении потоков по уровню замечаний и в отдельном реестре расхождений
  4. Свыше трёх тысяч документов или несколько юридических лиц. Нужен исполнительный агент или платформа документооборота с ИИ, единая точка сбора всех каналов и персональная ответственность за реестр расхождений

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

  • Доля бумаги и фотографий в общем потоке, потому что распознавание дороже обработки структурированных данных
  • Количество разных форм от разных поставщиков, когда каждая вторая накладная выглядит по-своему
  • Наличие налоговых рисков по вычетам, из-за которых цена пропущенной ошибки измеряется не часами, а суммой доначисления
  • Сезонность, при которой в пиковые недели поток вырастает в три раза и ручная проверка перестаёт справляться физически

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

Промты для проверки документов

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

Общие правила, которые применимы ко всем запросам ниже.

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

Сверка реквизитов и контрагента

Задача этого запроса — вытащить реквизиты в сопоставимом виде и показать расхождения с эталоном. Эталоном служит выписка из реестра, карточка контрагента из учётной системы или данные договора.

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

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

Проверка сумм и НДС

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

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

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

  • Проверка применения пониженной ставки к номенклатуре, которая на неё не похожа
  • Выделенный налог в документе от поставщика, который заявлял упрощённую систему
  • Расхождение между ставкой в основном документе и в счёте-фактуре
  • Округления, из-за которых итог по документу расходится с суммой строк на несколько копеек

Поиск расхождений с договором

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

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

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

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

Внедрение: пошаговый план

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

Общий маршрут укладывается в семь шагов и занимает от шести недель до трёх месяцев в зависимости от объёма.

  1. Инвентаризация каналов поступления и замер объёма по каждому из них
  2. Расчёт текущей трудоёмкости проверки и стоимости ошибок за последний год
  3. Выбор одного участка для пилота с понятной метрикой результата
  4. Техническая настройка сбора документов и интеграции с учётной системой
  5. Пилот в режиме полного контроля человеком, с фиксацией ложных срабатываний
  6. Калибровка правил и перевод части потока в автоматический режим
  7. Закрепление регламента, распределение ответственности и расширение на другие участки

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

Оценка объёма документооборота и узких мест

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

Минимальный набор данных для решения собирается за одну неделю наблюдения.

  • Количество входящих документов за месяц с разбивкой по типам
  • Доля каждого канала поступления, включая электронный документооборот, почту, кабинеты заказчиков, бумагу и фотографии
  • Среднее время от получения документа до его отражения в учёте
  • Фактическое время ручной проверки по замеру, а не по ощущениям сотрудников
  • Доля документов, по которым пришлось обращаться к поставщику за исправлением
  • Количество расхождений, найденных при квартальных сверках
  • Суммы снятых вычетов и доначислений за прошлый год, если такие были

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

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

Пилот на одном участке

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

Критерии пригодного участка для первого запуска.

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

Метрики фиксируются до старта, иначе спор о результате неизбежен. Разумный набор включает четыре показателя.

Показатель Как измеряется Ориентир после калибровки
Точность извлечения реквизитов Доля полей, совпавших с ручной проверкой От девяноста пяти процентов на структурированных данных
Доля ложных срабатываний Замечания, признанные бухгалтером необоснованными Не выше десяти процентов от всех замечаний
Пропущенные ошибки Расхождения, найденные человеком, но не системой Стремится к нулю по арифметике и реквизитам
Время обработки документа От поступления файла до готового черновика Сокращение в два и более раза

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

Регламент: что проверяет ИИ, что подтверждает человек

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

Что должно быть в регламенте.

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

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

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

Ошибки при внедрении и как их избежать

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

  1. Автоматизация захламлённых справочников. Если номенклатура содержит пять вариантов одного товара и контрагенты заведены дважды, система начнёт предлагать неверную аналитику и дискредитирует себя за первый месяц. Чистка справочников делается до запуска, а не после
  2. Обработка визуализации вместо структурированного файла. Организация платит за распознавание того, что уже приходит в виде готовых данных. Проверьте настройку выгрузки у оператора электронного документооборота прежде, чем покупать распознавание
  3. Включение всех правил сразу. Поток замечаний превышает возможности участка, доверие падает, и систему отключают. Правила вводятся волнами, начиная с арифметики и реквизитов
  4. Отсутствие ответственного за реестр расхождений. Расхождения накапливаются, никто их не закрывает, и реестр становится свалкой. Нужна персональная фамилия напротив каждой строки
  5. Оценка результата по заявлениям поставщика. Демонстрация на идеальных образцах не предсказывает поведение на вашей выборке. Тестируйте на своих худших документах
  6. Молчаливая подстановка неуверенно распознанных значений. Поле заполнено, бухгалтер его не проверяет, ошибка уходит в учёт. Требуйте отображения уровня уверенности и подсветки сомнительных полей
  7. Экономия на обучении сотрудников. Люди продолжают работать по старой схеме параллельно с системой, трудоёмкость растёт вместо снижения
  8. Запуск в период отчётности. Любой сбой в это время воспринимается как катастрофа, и проект закрывают по эмоциональным причинам

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

Безопасность данных и ответственность за результат

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

Три варианта размещения различаются по уровню контроля и по стоимости.

Вариант Контроль над данными Когда подходит
Решение в собственной инфраструктуре Полный, данные не покидают контур Крупные объёмы, строгие требования службы безопасности
Облачный сервис российского поставщика Ограничен договором и настройками Большинство средних организаций
Публичная языковая модель общего назначения Минимальный, условия задаёт сервис Обезличенные фрагменты и методические вопросы

Практические требования, которые стоит проверить при выборе облачного решения.

  • Размещение серверов на территории России и подтверждение этого в договоре
  • Наличие продукта в реестре отечественного программного обеспечения, если это важно для вашей отрасли
  • Условия обработки персональных данных и роль поставщика как оператора или обработчика по поручению
  • Прямой запрет на использование ваших документов для обучения моделей
  • Срок хранения загруженных файлов и порядок их удаления
  • Разграничение прав доступа по участкам и журналирование действий пользователей
  • Порядок уведомления об инцидентах и доступность данных при расторжении договора

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

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

Стоимость и эффект: на чём экономит бухгалтерия

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

Структура затрат на внедрение выглядит так.

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

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

Ориентиры, которые встречаются в практике внедрений и которые стоит проверять на своих данных.

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

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

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

Можно ли доверить ИИ первичку без контроля бухгалтера?

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

Какую долю документов реально проверять автоматически?

Зависит от однородности потока и от формата поступления сильнее, чем от выбранного решения.

  • При преобладании структурированных файлов электронного документооборота и типовых операциях автоматически проходит от семидесяти до девяноста процентов документов
  • На фотографиях бумажных документов с рукописными правками доля автоматического проведения остаётся низкой независимо от инструмента

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

Заменит ли ИИ бухгалтера на проверке документов?

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

С чего начать, если бухгалтерия из одного человека?

С самых дешёвых шагов, не требующих покупки отдельной системы.

  1. Настройте выгрузку структурированных файлов из вашего сервиса электронного документооборота и загружайте в учётную систему их, а не печатные формы
  2. Подключите автоматическую проверку контрагентов на дату документа, большинство операторов даёт её в составе тарифа
  3. Используйте встроенные возможности учётной системы по загрузке документов, прежде чем смотреть на внешние решения
  4. Соберите набор из пяти-шести запросов к языковой модели для разбора договоров, проверки арифметики на обезличенных данных и подготовки писем поставщикам
  5. Завершите месяц коротким реестром расхождений по авансам и незакрытым документам, это десять минут работы и самая частая точка потерь

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

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

Связаться с нами

Оставьте заявку, и мы свяжемся с вами, чтобы обсудить внедрение безопасного ИИ-пространства в вашей компании.

Предпочитаемый способ связи