ChatGPT для распознавания первички: кейс и подводные камни

В 2026 году большие языковые модели с возможностью обработки изображений (vision) — ChatGPT-4o, ChatGPT-5, Claude 3.5 Sonnet, Claude 4 — устойчиво справляются с типовыми бухгалтерскими документами в печатном виде. Это сценарий, где экономия времени самая ощутимая и риск минимальный.

Что ИИ закрывает в 2026:

• Печатные акты выполненных работ и УПД от типовых российских контрагентов
• Счета-фактуры с разбивкой по ставкам НДС (0%, 10%, 20%)
• Товарные накладные (ТОРГ-12) и универсальные передаточные документы (УПД)
• Транспортные накладные (ТТН) — структурированные поля
• Кассовые чеки и Z-отчеты с четкими реквизитами
• Простые договоры с типовыми реквизитами шапки

Что ИИ закрывает с ограничениями:

• Рукописные накладные и кассовые ордера — точность падает до 50-70%, требуется визуальная сверка по каждой строке
• Документы с дополнительной разметкой, печатями поверх текста — точность 70-85%
• Старые сканы низкого качества (200 dpi и ниже) — точность 60-80%
• Многостраничные документы с таблицами на нескольких листах — нужно разбивать на части

Что ИИ НЕ закрывает в 2026:

• Автоматический перенос в 1С без участия человека — точность 95% означает 5 ошибок на 100 документов, что недопустимо без проверки
• Распознавание подписи и решение, подписан документ уполномоченным лицом или нет
• Юридическая квалификация документа (является ли это первичкой по ст. 9 402-ФЗ)
• Решение о том, к какой проводке отнести операцию в 1С

Юридический статус ИИ-распознавания: первичный документ остается бумажным или электронным с ЭЦП, ИИ только ускоряет ввод данных. При налоговой проверке предъявляется оригинал, а не результат распознавания.

Ключ к стабильному результату — четкое описание роли модели, явное перечисление полей и фиксированный формат ответа. Возврат строго в JSON упрощает дальнейший перенос в 1С через автоматизацию.

Готовый промпт:

• Роль: «Ты помощник бухгалтера. Извлекай данные из первичных бухгалтерских документов в строго заданном формате.»
• Задача: «Распознай прикрепленный акт выполненных работ. Верни ответ строго в формате JSON без комментариев и пояснений.»
• Поля: «contractor_name (юрлицо или ИП), contractor_inn (10 или 12 цифр), contractor_kpp (если есть), doc_number, doc_date (ДД.ММ.ГГГГ), service_description (полное наименование услуги), amount_total (число без пробелов, рубли и копейки через точку), vat_rate (0, 10 или 20), vat_amount (число с копейками), amount_without_vat (число с копейками).»
• Правила: «Если поле не читается, верни null. Не выдумывай данные. Если документ не похож на акт, верни {error: пояснение}.»

Пример ожидаемого ответа от модели:

• contractor_name: ООО Ромашка
• contractor_inn: 7701234567
• contractor_kpp: 770101001
• doc_number: 247
• doc_date: 15.05.2026
• service_description: Консультационные услуги по договору № 12 от 01.03.2026
• amount_total: 60000.00
• vat_rate: 20
• vat_amount: 10000.00
• amount_without_vat: 50000.00

Что повышает точность: 1) фото с прямого ракурса без перспективных искажений; 2) разрешение от 1500 пикселей по короткой стороне; 3) равномерное освещение без бликов на печати; 4) формат JPG или PNG (PDF тоже работает, но медленнее).

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

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

Расширенный промпт:

• Задача: «Распознай прикрепленный счет-фактуру по форме, утвержденной Постановлением Правительства РФ № 1137. Верни данные в JSON.»
• Поля: «seller_name, seller_inn, seller_kpp, seller_address, buyer_name, buyer_inn, buyer_kpp, document_number, document_date, currency (код по ОКВ), table_items — массив строк с полями: name, unit, quantity, price_without_vat, amount_without_vat, vat_rate (0, 10, 20, освобождено), vat_amount, amount_total. Итоговые поля: total_without_vat, total_vat, total_with_vat.»
• Правила: «Если в документе несколько ставок НДС, разбей строки по ставкам. Если есть корректировочный счет-фактура (КСФ), укажи is_correction: true и номер исходного документа. Не интерпретируй данные, копируй буквально.»

Особенности для счета-фактуры:

• Проверяем ИНН продавца через открытое API ФНС: длина 10 цифр для юрлица, 12 для ИП, контрольная сумма
• Если ставка НДС в документе указана как «Без НДС» при общей системе налогообложения у продавца — это сигнал к проверке (возможно, ошибка контрагента)
• При суммах свыше 100 000 ₽ за месяц по одному контрагенту сверяем КПП — частая ошибка при переезде юрлица
• Номер счета-фактуры должен быть уникальным в пределах календарного года у продавца

Сценарий с УПД: универсальный передаточный документ совмещает функции счета-фактуры и накладной. Промпт расширяем полями ТОРГ-12 (склад, кладовщик, грузоотправитель). Документу присваивается статус: «1» — полная замена накладной + счета-фактуры, «2» — только товарная накладная.

Товарные накладные сложнее актов из-за табличной части с множеством позиций. Здесь ChatGPT и Claude иногда теряют последние строки или путают графы цены и количества.

Промпт для ТОРГ-12 / УПД статуса 2:

• Задача: «Распознай товарную накладную ТОРГ-12. Верни данные в JSON, каждая строка таблицы — отдельный объект в массиве items.»
• Поля шапки: «supplier_name, supplier_inn, consignee_name, consignee_inn, doc_number, doc_date, basis_doc (договор-основание), shipper, payer.»
• Поля строки: «row_number, product_name, product_code (артикул), unit_of_measure (наименование и код по ОКЕИ), quantity, price (без НДС), amount_without_vat, vat_rate, vat_amount, amount_with_vat.»
• Поля подвала: «total_pieces, total_amount_without_vat, total_vat, total_amount_with_vat, signature_director, signature_chief_accountant.»

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

• Сумма по всем строкам без НДС должна равняться total_amount_without_vat в подвале — если расхождение, ИИ пропустил строку или ошибся в цифре
• Количество строк, выданное моделью, должно совпадать с визуально подсчитанным числом строк в документе
• На последней странице многостраничной накладной ИИ часто теряет 1-2 нижние строки — отдельно проверяем хвост
• Если артикулы товаров уникальные (длинные коды), частая ошибка — потеря последних 1-2 символов кода

ТТН (транспортная накладная) — отдельная форма с разделами «Грузоотправитель», «Грузополучатель», «Транспорт», «Маршрут». Распознавать рекомендуется по разделам отдельно, не одним промптом — точность выше.

Данные собраны из практики бухгалтерских аутсорсинговых компаний за 2025-2026 годы при использовании ChatGPT-4o и Claude 3.5 Sonnet. Точность измерялась как доля документов, в которых все ключевые реквизиты (контрагент, ИНН, дата, сумма, НДС) распознаны верно.

Вывод: для печатных документов от юрлиц с приемлемым качеством фото — точность достаточна для рабочего использования с обязательной выборочной проверкой. Для рукописной первички ИИ ускоряет ввод, но проверка нужна по каждому документу, поэтому выигрыш по времени меньше — 30-40% против 60-70% на печатных.

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

• Шаг 1. Прием документов. Клиент отправляет фото/PDF документов через мессенджер, ЭДО или почту. Документы складываются в папку входящих с привязкой к клиенту.
• Шаг 2. Запуск распознавания. Бухгалтер открывает ChatGPT/Claude, прикрепляет документ, вставляет готовый промпт. Время на одну операцию — 5-10 секунд.
• Шаг 3. Визуальная сверка. Бухгалтер сравнивает JSON-ответ модели с оригиналом документа. Проверяет минимум: контрагент, ИНН, сумма, дата, ставка НДС. Время — 15-30 секунд.
• Шаг 4. Перенос в 1С. JSON копируется через буфер или загружается через интеграцию. Создается документ соответствующего типа (поступление товаров, услуг, акт). Время — 30-60 секунд.
• Шаг 5. Проверка контрагента в 1С. Если контрагента нет в базе — создается новый по данным из JSON. Проверяется через ФНС-API (статус, актуальность реквизитов).
• Шаг 6. Сверка с банком. После переноса в 1С документ сверяется с движением по расчетному счету. Несоответствия — повод вернуться к документу.

Итого: 1-2 минуты на документ против 2-3 минут ручного ввода. Экономия 30-50% времени при стабильной точности 90%+.

Для команд от 10 бухгалтеров имеет смысл подключать API ChatGPT/Claude к собственному внутреннему интерфейсу — бухгалтер не уходит из 1С, а распознавание идет фоновым процессом. Стоимость разработки такого инструмента — 200-500 тысяч ₽ для самого простого MVP. Окупается на больших объемах.

Принцип «доверяй, но проверяй» обязателен. Никакая точность 95% не отменяет ответственности бухгалтера за документ, попавший в учет.

Типовые ошибки и способы их ловить:

• Ошибка в копейках суммы. Чаще всего модель округляет, теряя 1-2 копейки. Контроль: пересчет «amount_total = amount_without_vat + vat_amount», расхождение копейка-две — корректируем.
• Перепутанные ИНН и КПП. Возникает, когда документ от юрлица распознается как от ИП или наоборот. Контроль: проверка длины ИНН (10 цифр для юрлица, 12 для ИП) и наличие КПП (только у юрлиц).
• Потеря строк в длинной накладной. Контроль: сравнение «сумма строк = итоговая сумма в подвале», расхождение — пересчитываем строки вручную.
• Дата в неверном формате. Модель может выдать 05.15.2026 вместо 15.05.2026 при американском формате на исходнике. Контроль: явно прописывать в промпте «формат ДД.ММ.ГГГГ».
• Выдуманный КПП. Если в документе КПП отсутствует, модель иногда «придумывает» правдоподобный. Контроль: явно требовать null для отсутствующих полей.
• Ставка НДС перепутана с льготным режимом. Если контрагент на УСН, модель может ошибочно проставить 20% НДС. Контроль: знание системы налогообложения контрагента в базе 1С.

Что делать, если ошибка прошла в учет:

• Ошибка обнаружена в течение квартала, отчетность не сдана — правим первичку и проводку в 1С, повторно проводим сверку с банком
• Ошибка обнаружена после сдачи декларации НДС — подаем уточненную декларацию по ст. 81 НК РФ, доплачиваем налог и пени до подачи уточненки. Штраф 20% применяется только при выявлении ошибки самой ФНС
• Ошибка повлекла отказ контрагенту в вычете НДС — приносим извинения, выставляем корректировочный счет-фактуру, проводим в обоих учетах

Уровень допустимых ошибок: для команды на бухгалтерском аутсорсинге целевой показатель — не более 1 ошибки в распознавании на 100 документов после сверки. Если модель устойчиво дает больше — стоит поменять промпт, улучшить качество фото на стороне клиента или вернуться к ручному вводу для проблемных типов документов.

Главный риск распознавания первички через публичные ChatGPT и Claude — нарушение требований 152-ФЗ о персональных данных, если документ содержит данные физических лиц.

Можно отправлять в публичные сервисы:

• Акты, счета-фактуры, накладные между юрлицами (ИНН и КПП юрлиц — открытые данные ФНС)
• Договоры между юрлицами без приложений с персональными данными сотрудников
• Кассовые чеки от юрлиц-продавцов
• Типовые формы документов, не содержащие реальных данных

Нельзя отправлять в публичные сервисы:

• Любые документы с паспортными данными физлиц (договоры с физлицами, заявления, расписки)
• Зарплатные ведомости, штатные расписания с ФИО сотрудников и суммами
• Выписки по расчетным счетам с указанием контрагентов-физлиц
• Документы с СНИЛС, ИНН физических лиц
• Медицинские документы (больничные листы)
• Документы, защищенные коммерческой тайной по договору с клиентом

Решения для чувствительных данных:

• Локальные модели на сервере компании (LLaMA, Mistral, GigaChat on-premise) — данные не покидают периметр, разовая стоимость инфраструктуры 300-800 тысяч ₽
• Корпоративные тарифы ChatGPT Team/Enterprise или Claude Team — данные не используются для обучения, но физически уходят на серверы за пределы РФ (для 152-ФЗ этого недостаточно)
• YandexGPT 4 через Yandex Cloud в режиме обработки в РФ — данные физически в стране
• Ручной ввод для документов с персональными данными — самый дорогой по времени, но юридически безопасный вариант

Юридическая защита: перед массовым внедрением ИИ-распознавания имеет смысл добавить в типовой договор обслуживания с клиентом пункт о праве использовать ИИ-инструменты для обработки документов с указанием категорий данных и применяемых мер защиты. Это снимает риск претензий клиента и упрощает диалог с проверяющими органами.