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 (open-source OCR) дают сырой текст без структуры. Дальше этот текст надо парсить: искать ИНН, номер счёта, сумму, дату. Это пишется regex-ами и быстро превращается в неподдерживаемый зоопарк правил.

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

{
  "doc_type": "Акт выполненных работ",
  "number": "АВ-2026-004",
  "date": "2026-03-28",
  "supplier": {
    "name": "ООО Ромашка",
    "inn": "7708123456",
    "kpp": "770801001"
  },
  "customer": {
    "name": "ООО Клиент",
    "inn": "7709876543"
  },
  "lines": [
    { "description": "Настройка CRM", "qty": 1, "price": 85000, "total": 85000 }
  ],
  "total": 85000,
  "vat": 0,
  "confidence": 0.94
}

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

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

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

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

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

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

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

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

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

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

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

Результаты

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

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

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

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

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