OCR-пайплайн для бухгалтерской фирмы: 80 актов в день вместо 20

Задача

Клиент — аутсорсинговая бухгалтерия. Обслуживает 60+ компаний малого и среднего бизнеса, в основном ООО-шки с УСН и ОСН. Основной поток работы — первичка: накладные от поставщиков, акты выполненных работ, счета-фактуры, УПД. Каждый день в фирму приходят сотни документов: часть электронно через ЭДО, часть PDF по почте, часть — сканы и фотографии с телефона, присланные через WhatsApp (да, так тоже бывает).

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

1. Открыть почту, скачать вложение.
2. Открыть документ, посмотреть реквизиты, сумму, назначение.
3. Перепечатать в 1С (или отдельный шаблон акта).
4. Проверить, что ИНН, КПП и дата совпадают с данными в 1С.
5. Провести документ.

На один документ у опытного бухгалтера уходило в среднем 15–20 минут: зависело от качества скана, наличия полей в 1С, необходимости уточнять что-то у клиента. Один бухгалтер за смену обрабатывал 20–25 документов первички, и это был предел. Дальше накапливались усталость, ошибки, пересобранные проводки.

Когда клиент пришёл с запросом «помогите автоматизировать», ожидание было простое: хотим, чтобы бухгалтер проверял готовый документ, а не набивал его с нуля. Ключевая метрика, которую поставили — время на один документ, и она должна была упасть с 15–20 минут до 1–2 минут.

Почему не ABBYY и не Tesseract

Первое, что думает любой инженер в такой задаче — «возьмите ABBYY FlexiCapture и настройте шаблоны». Мы честно попробовали и не пошли этим путём.

У клиента 200+ разных контрагентов, и каждый печатает свои акты по своему макету. Часть работает через популярные сервисы ЭДО — у тех шаблоны стандартизированы. Часть печатает из 1С в своей старой конфигурации, где поля плавают от редакции к редакции. Часть — из Word по шаблону времён 2015 года. И есть те, кто присылает фотографию распечатанного акта с подписью и печатью, сделанную на телефон с плохим освещением.

ABBYY хорошо работает на первых двух типах, терпимо на третьем, и почти не работает на четвёртом. А главное — под каждый шаблон нужно настраивать FlexiCapture вручную, и каждый новый контрагент — это работа.

Tesseract и EasyOCR (OCR с открытым кодом) дают сырой текст без структуры. Дальше этот текст надо парсить: искать ИНН, номер счёта, сумму, дату. Это пишется регулярными выражениями и быстро превращается в неподдерживаемый зоопарк правил.

Claude Sonnet с обработкой изображений читает картинку и возвращает сразу JSON:

{
  "тип_документа": "Акт выполненных работ",
  "номер": "АВ-2026-004",
  "дата": "2026-03-28",
  "поставщик": {
    "название": "ООО Ромашка",
    "инн": "7708123456",
    "кпп": "770801001"
  },
  "заказчик": {
    "название": "ООО Клиент",
    "инн": "7709876543"
  },
  "позиции": [
    { "описание": "Настройка CRM", "кол-во": 1, "цена": 85000, "итого": 85000 }
  ],
  "итого": 85000,
  "ндс": 0,
  "уверенность": 0.94
}

Без настройки шаблонов. На любом макете. На сканах разного качества.

Точность на нашем корпусе из 500 проверенных документов — ~97% против ~98,5% у ABBYY на настроенных шаблонах. Разница в 1,5% компенсируется тем, что нам не нужно настраивать 200 шаблонов, и новый контрагент обрабатывается сразу.

Архитектура пайплайна

┌───────────────────┐
│  Входящие каналы  │
│  ─ почта (IMAP)   │
│  ─ ЭДО            │
│  ─ WhatsApp       │
│  ─ ручная загрузка│
└────────┬──────────┘
         │
         ▼
┌───────────────────┐
│  Препроцессинг    │
│  ─ PDF → PNG      │
│  ─ выравнивание   │
│  ─ нормализация   │
└────────┬──────────┘
         │
         ▼
┌───────────────────┐
│  Мультимодальная  │   Claude Sonnet
│  LLM — JSON       │   структурированный вывод
└────────┬──────────┘
         │
         ▼
┌───────────────────┐
│  Валидация         │
│  ─ ИНН контрольн.  │
│  ─ сумма прописью  │
│  ─ проверка в ЕГРЮЛ│
└────────┬──────────┘
         │
         ▼
┌───────────────────┐
│  Шаблон акта      │
└────────┬──────────┘
         │
         ▼
┌───────────────────┐
│  Бухгалтер        │
│  проверяет минуту │
└────────┬──────────┘
         │
         ▼
┌───────────────────┐
│  1С (REST/XML)    │
└───────────────────┘

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

Валидация: где ловим ошибки

Три уровня автоматической валидации.

ИНН по контрольной сумме. Алгоритм ФНС даёт 100% точность на проверку корректности ИНН, это 10 строчек кода. Если AI распознал ИНН, а контрольная сумма не сходится — помечаем документ как «проверить».

Сумма vs сумма прописью. В российской первичке обычно есть и цифрами, и прописью. Парсим пропись («восемьдесят пять тысяч рублей 00 копеек») через отдельный вызов и сверяем с цифрами. Несовпадение — флаг на проверку.

Проверка контрагента в ЕГРЮЛ. По ИНН дёргаем API ФНС и сверяем название организации. Если ИНН валидный, но название не совпадает — возможно, AI распознал не тот ИНН (например, был КПП перепутан с ИНН). Флаг на проверку.

Документы, где хотя бы один флаг сработал, попадают в очередь «Проверить вручную». Это примерно 6–8% от потока. Остальные 92–94% идут в очередь «Готов к проводке», где бухгалтер тратит минуту на визуальную сверку и нажимает «Провести».

Результаты

Цифра «80 актов в день» — это среднее по команде клиента (4 бухгалтера на первичке). Лучшие сотрудники выдавали 110–120 актов в день. Хуже всего привыкали к новому пайплайну те, кто дольше всех работал «руками»: у них первая неделя ушла на адаптацию.

Отдельный бонус, которого клиент не ждал: снизился срок закрытия месяца. Раньше первичка к 5–7 числу следующего месяца едва обрабатывалась, и бухгалтерия жила в режиме «закрытия вчера». После внедрения первичка закрывается в течение 2–3 дней после окончания месяца, и у команды появилось время на аналитику и консультации.

Что забрать из кейса

Главный вывод: современные мультимодальные LLM вытесняют классический OCR плюс регулярки в задачах, где шаблонов слишком много, чтобы настраивать их руками. Один вызов модели заменяет цепочку «распознавание + парсинг + валидация под каждый шаблон». Это дороже за 1 документ по токенам (около 2–3 ₽ против почти нуля у OCR с открытым кодом), но дешевле в разы по трудозатратам на поддержку пайплайна.

И ещё: бухгалтер не исчезает из процесса, он становится проверяющим. Это принципиально и для точности (живой глаз ловит редкие ошибки AI), и для ответственности (подпись под актом всё равно ставит человек). С самого начала строили пайплайн именно так — не «AI заменяет бухгалтера», а «AI готовит документ, бухгалтер проверяет». И быстрее работает, и клиенты такому варианту доверяют больше.