Автоматизация обработки счетов и актов с OCR: пайплайн и контроль

Что болит в обработке счетов и актов и зачем OCR

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

Типичный день выглядит так: бухгалтерия получает пачку сканов и PDF от поставщиков, заносит БИН/ИИН, номер и дату, сумму и НДС, затем сравнивает документ с договором и заявкой. Стоит ошибиться в одной цифре, и документ уходит на возврат. Цепочка согласования растягивается, а оплата сдвигается.

Самые неприятные риски почти всегда связаны с мелкими полями, которые легко перепутать: сумма и НДС (ошибка в разряде или неверная ставка), дата документа и период оказания услуг (особенно в актах), реквизиты поставщика и покупателя (БИН, ИИК, банк), а также номер договора или заявки, по которым документ потом ищут.

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

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

Успех проще измерять не общими словами, а показателями: сколько минут занимает обработка одного документа, какой процент проходит без ручной правки, сколько возвратов происходит из-за реквизитов, сколько ошибок удалось поймать до проведения.

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

Какие данные вы хотите получить: минимальный набор полей

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

Обычно в потоке встречаются счет на оплату, акт выполненных работ (оказанных услуг), счет-фактура и приложения (спецификации, допсоглашения, реестры). У каждого типа документов свои правила: в акте важнее период и основание, а в счете-фактуре критичны данные по НДС.

Минимальный набор полей, который чаще всего дает ощутимый эффект:

• поставщик: наименование и БИН/ИИН (лучше хранить оба);
• номер и дата документа (и дата выставления, если она отдельная);
• итоговая сумма и валюта;
• НДС: ставка и сумма (или признак "без НДС");
• основание: номер договора или заказа, если он есть в документе.

Дальше почти всегда упираются в справочники. Даже если строка распознана верно, системе нужно понять, кто это и куда отнести документ. Минимально полезно заранее подготовить справочники контрагентов (с БИН/ИИН и вариантами названий), договоров и допсоглашений (номера, даты, привязка к контрагенту), статьи затрат или счета учета для маршрутизации, а также ставки НДС и правила для формулировок "без НДС".

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

Пример из практики: бухгалтерия получает акт и счет от одного поставщика, но в одном документе название сокращено, а в другом полное. Если опираться только на название, появятся дубли. Если ключом сделать БИН, система сведет документы правильно, а человеку останется проверить только редкие случаи.

Подготовка сканов и фото: что влияет на качество распознавания

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

Для сканов важны три вещи: детализация, читаемость и геометрия. Сканируйте так, чтобы мелкий текст (БИН, банковские реквизиты, номер договора) был четким, а линии таблиц не распадались. Часто достаточно 300 DPI для печатных документов, а если шрифт мелкий или много таблиц - 400 DPI. Следите за контрастом: текст должен быть темнее фона, но без "зажима", когда светлые участки пропадают, а буквы слипаются.

Перед загрузкой в систему стоит быстро проверить:

• страница ровная, без перекоса, обрезанных углов и "волны";
• фон чистый, без узоров, полос и лишних теней;
• текст не перекрыт печатями и подписями в критичных местах;
• файл без сильного JPEG-сжатия и заметного "мыла";
• таблицы читаемы, границы и колонки различимы (частая проблема в актах).

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

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

Как выбрать подход к OCR и извлечению полей

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

Языки, шрифты и смешанные реквизиты

Для счетов и актов часто нужна поддержка нескольких вариантов текста: русский, казахский, а в реквизитах - латиница (например, названия банков, SWIFT, домены в e-mail). Проверьте, умеет ли OCR уверенно работать с кириллицей и казахскими символами и не ломается ли на строках, где латиница и цифры идут рядом. На практике это особенно влияет на БИН/ИИН, номера счетов, БИК, IBAN и адреса.

Быстрый тест перед выбором:

• возьмите 30-50 реальных сканов из разных подразделений;
• отдельно отметьте документы с казахским текстом и смешанной латиницей;
• посмотрите, где чаще всего ошибки: цифры, даты, аббревиатуры, ФИО;
• проверьте, сохраняется ли структура таблиц или все превращается в "простыню".

Шаблоны vs извлечение по ключам и смыслу

Если у вас 3-10 типовых форм от одних и тех же поставщиков, шаблонный подход обычно дает лучшую точность. Вы фиксируете зоны на странице (где номер, дата, сумма), и система извлекает поля предсказуемо. Минус очевидный: любой редизайн счета или новый поставщик требует настройки.

Если поставщиков много, а макеты постоянно меняются, лучше подходит извлечение по ключевым словам и контексту: система ищет подписи полей ("Счет-фактура №", "Итого", "Поставщик") и сопоставляет значения рядом. Это гибче, но потребует сильной постобработки: нормализации дат и сумм, проверки БИН/ИИН, сопоставления с вашим справочником контрагентов.

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

По безопасности лучше заложить минимум сразу: где хранятся сканы и распознанные данные, кто имеет доступ, как быстро можно удалить документ по запросу, есть ли журнал действий (кто загрузил, кто исправил поле, кто отправил в учетную систему). Для организаций с повышенными требованиями часто важна обработка внутри контура и понятная схема прав доступа. Здесь полезна консультация системного интегратора, который связывает OCR, хранилище и учетные системы в единый процесс.

Пайплайн шаг за шагом: от скана до проводок

Чтобы OCR-обработка работала стабильно, важно собрать процесс в понятную цепочку. Тогда видно, на каком шаге теряется качество и что именно нужно чинить: входной канал, распознавание или правила проверки.

1) Откуда документ попадает в систему

Документы приходят разными путями: со сканера или МФУ, из почты, из ЭДО, иногда в виде фото от сотрудников. На входе полезно сразу определить тип (счет, акт, накладная) и поставщика. Это можно делать по ключевым словам, шаблонам, штрихкоду или по данным из темы письма.

Дальше процесс обычно выглядит так:

1. Прием и классификация: фиксируем источник, дату, отправителя, тип документа.
2. Предобработка изображения: выравнивание, обрезка, удаление шума, повышение контраста.
3. OCR: получаем текстовый слой и координаты слов (чтобы понимать, где что находится).
4. Извлечение полей: находим БИН/ИИН, номер, дату, сумму, НДС, реквизиты, позиции.
5. Проверки и маршрут: сверяем поля со справочниками, отправляем на согласование, сохраняем версии.

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

Что важно проверить до автопроводок

Даже простые правила заметно снижают ошибки:

• сумма строк сходится с итогом и НДС;
• дата не в будущем и не слишком далеко в прошлом;
• БИН/ИИН проходит контрольную проверку и есть в справочнике;
• валюта и ставка НДС допустимы для вашей компании;
• номер документа не дублируется у этого контрагента.

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

Постобработка и валидация: как превращать текст в данные

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

Автопроверки: что ловить до интеграции

Начните с проверок, которые дают максимум пользы и почти не требуют ручной работы:

• арифметика: сумма строк должна сходиться с итогом, НДС должен считаться по ставке, округления должны быть едиными по документу;
• форматы: дата в допустимом виде (и не "32.13.2025"), номер без лишних пробелов, БИН/ИИН нужной длины, IBAN и БИК по шаблону;
• логика полей: если указан НДС, должна быть ставка и база; наличие печати и подписи не гарантирует корректность, но помогает отличить "черновик".

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

Сверка со справочниками и пороги уверенности

Дальше начинается "приземление" к вашим справочникам. Контрагента надежнее определять по БИН/ИИН, а не по названию: названия пишут по-разному, а цифры уникальны. По найденному контрагенту можно подтянуть договор, условия оплаты, тип НДС, а иногда и счет учета или статью затрат по правилам.

Полезный прием - порог уверенности OCR. Если уверенность по ключевому полю (итог, БИН/ИИН, номер, дата) ниже порога, документ уходит на ручную проверку. При этом править лучше не весь текст, а только сомнительные поля: так оператор тратит минуты, а не десятки минут.

И еще один шаг - обогащение. Если в документе нет нужного атрибута (например, подразделение или проект), добавляйте его по понятным правилам: по контрагенту, договору, назначению платежа или типу документа. Так распознанный файл превращается в набор полей для проводок, а исключений становится меньше.

Типовые ошибки распознавания и как их ловить

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

Что чаще всего идет не так

Самая частая группа ошибок - путаница похожих символов: ноль и буква О, 1 и 7, И и Й, а также смешение кириллицы и латиницы в БИН/ИИН, БИК, номере счета или названии компании. Визуально это почти незаметно, но для системы это разные значения.

Вторая проблема - формат чисел. OCR может перепутать точку и запятую в суммах, потерять разделители тысяч или, наоборот, вставить лишние. В итоге "1 200,50" превращается в "1200.50" или "12 005,0".

Третья - смещение по строкам и колонкам в таблицах. Например, сумма НДС попадает в поле "итого", или номер договора берется из соседней строки. Такое бывает из-за перекоса страницы, бледной таблицы или изменившегося шаблона поставщика.

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

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

Как ловить ошибки до проводок

Лучше всего работает сочетание простых правил и выборочной проверки человеком. Начните с базовых контролей:

• форматы: БИН/ИИН по длине, БИК по длине, номер счета по количеству символов;
• арифметика: сумма без НДС + НДС = итого (с допустимой погрешностью на округления);
• нормализация чисел: единый десятичный разделитель, удаление лишних пробелов;
• подозрительные символы: латинские буквы там, где должны быть только цифры;
• сравнение с историей: если у поставщика обычно 12 строк в акте, а стало 2, это повод отправить на проверку.

Далее подключайте уровень уверенности. Если OCR сомневается в одном символе в БИН/ИИН или в последней цифре суммы, такой документ лучше пометить как риск и отправить на ручное подтверждение.

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

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

Контроль качества: метрики, выборки и мониторинг

Польза от OCR появляется тогда, когда качество можно измерять и удерживать. Иначе легко пропустить, что точность "поплыла" на одном поставщике или после обновления правил.

Метрики, которые стоит считать постоянно

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

• точность по полям: доля документов, где ключевые поля извлечены верно (БИН/ИИН, сумма, НДС, номер и дата);
• доля ручных правок: сколько документов потребовало вмешательства и какие поля правили чаще всего;
• доля "неопределено": сколько раз система не смогла извлечь поле и оставила пустым (это важно отдельно от ошибок);
• скорость обработки: время от загрузки скана до готовых данных плюс время на ручную проверку;
• доля возвратов: сколько документов пришлось переобработать из-за ошибок или спорных распознаваний.

Полезно вести метрики не только в целом, но и по поставщику, типу документа (счет, акт, УПД) и каналу (скан, фото, электронный PDF).

Контрольная выборка (эталон) и мониторинг

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

Собирайте эталон постепенно. Возьмите последние документы от 10-20 самых частых поставщиков, добавьте редкие форматы и пополняйте набор каждый раз, когда появляется новый шаблон или новая ошибка. Важно фиксировать не только картинку, но и контекст: поставщик, дата, тип документа, версия правил.

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

Раз в 2-4 недели делайте короткий разбор примеров: 10-15 реальных ошибок, их причина и что нужно изменить (правило, подсказку оператору, настройку шаблона). Так команда учится на живых документах, а качество становится управляемым, а не случайным.

Пример сценария: компания с регулярными счетами и актами

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

Для первого запуска важно не пытаться извлечь все подряд. Договоритесь о минимальном наборе полей и правилах: номер и дата, БИН/ИИН поставщика, сумма с НДС и без НДС, ставка НДС, валюта, номер договора или заявки, табличная часть (если нужна). Это и есть ядро, на котором строится автоматизация.

Перед включением автозагрузки настройте проверки, которые сразу отсекают рискованные документы:

• формат: PDF с текстовым слоем или скан, наличие всех страниц;
• контроль сумм: итог равен сумме строк, НДС считается по ставке;
• сопоставление поставщика: БИН найден и есть в справочнике;
• проверка дублей: связка номер + дата + БИН уже встречались;
• порог уверенности: если распознавание ниже заданного уровня, документ сразу уходит на ручную проверку.

Дальше картина обычно такая: большинство типовых счетов от 5-7 крупных поставщиков проходит автоматически (например, 60-70%). Остальные попадают в очередь на проверку, но уже с заполненными полями, где сотрудник подтверждает или исправляет 1-2 места. На старте полезно ограничить ручное исправление несколькими полями (дата, номер, суммы), чтобы проверка не превращалась в полноценный ввод.

В первые две недели обычно всплывают одинаковые проблемы: путаются похожие символы (0 и О, 1 и I), дата читается в другом формате, НДС попадает в поле суммы без НДС, табличная часть склеивается при плохом скане. Это закрывается не "магией", а дисциплиной: добавляете шаблоны для частых поставщиков, уточняете правила валидации, вводите список нестандартных форм, которые лучше сразу отправлять на проверку.

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

Если через месяц доля автопрохода выросла хотя бы на 15-20 пунктов, а время на документ упало в 2 раза, пайплайн работает и его можно масштабировать на новых поставщиков и типы документов.

Короткий чеклист и следующие шаги

Перед запуском OCR-процесса чаще всего упираются не в сам движок, а в подготовку: какие поля нужны на выходе и как вы проверяете качество.

Короткий чек перед стартом:

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

После запуска следите не за общим процентом распознавания, а за практическими сигналами: из 100 счетов сколько раз пришлось править сумму или БИН и какие ошибки повторяются чаще всего.

Для еженедельного контроля достаточно нескольких метрик: доля документов с ручными правками и среднее время на правку, топ ошибок по полям (дата, БИН/ИИН, НДС, итоги) и их источники (канал, поставщик, шаблон), доля документов, не прошедших проверки, а также очередь на проверку и сроки проведения.

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

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