Как сделать ИИ-агента для счетов, актов и первички

Что получится в результате

Соберем ИИ-агента, который разбирает входящие счета, акты и УПД, проверяет реквизиты и готовит документы к загрузке в учет.

Первая рабочая версия будет делать так:

1. поставщик присылает PDF, скан или файл из ЭДО;
2. файл попадает в папку `incoming_docs`;
3. n8n забирает новый файл;
4. OCR или PDF-парсер извлекает текст;
5. LLM превращает текст в строгий JSON;
6. workflow проверяет обязательные реквизиты, ИНН, КПП, суммы, НДС и тип документа;
7. результат попадает в Google Sheets со статусом `draft`;
8. бухгалтер проверяет строку и ставит `approved`, `needs_fix` или `rejected`;
9. approved-документы уходят в экспорт для 1С или другую учетную систему;
10. ошибки сохраняются в журнале `doc_errors`.

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

Что понадобится

• n8n Cloud или self-hosted n8n.
• Google Drive или другая папка для входящих документов.
• Google Sheets для approval и журнала.
• OCR-сервис для сканов, например Google Cloud Vision API.
• LLM API для извлечения реквизитов в JSON.
• Доступ к 1С, МойСклад, Контур, Диадок или другой системе учета, если нужен экспорт.
• Тестовые документы: счет, акт, УПД, документ с ошибкой.
• Бухгалтер, который проверит правила и первый набор результатов.

Шаг 1. Определите документы первой версии

Не пытайтесь сразу разобрать все виды первички.

Для первого прототипа возьмите:

1. счет на оплату;
2. акт выполненных работ;
3. УПД;
4. счет-фактуру, если она приходит отдельно.

Исключите из первой версии:

• авансовые отчеты;
• кассовые чеки;
• кадровые документы;
• договоры;
• документы с несколькими валютами;
• исправительные и корректировочные документы.

Проверка: вы можете перечислить, какие документы агент принимает, а какие отправляет в `needs_review`.

Шаг 2. Создайте папки для файлов

В Google Drive создайте структуру:

Accounting AI agent
  incoming_docs
  processed_docs
  needs_review_docs
  rejected_docs
  archive

Правило:

новый файл кладем только в incoming_docs
workflow после обработки переносит файл в нужную папку

Проверка: у n8n есть доступ к папке `incoming_docs`, а тестовый PDF виден в списке файлов.

Шаг 3. Создайте таблицу для обработки

Создайте Google Sheet:

Primary docs AI agent

Добавьте лист `doc_queue`.

Колонки:

doc_id
file_id
file_name
file_url
doc_type
seller_name
seller_inn
seller_kpp
buyer_name
buyer_inn
buyer_kpp
doc_number
doc_date
contract_number
total_amount
vat_amount
currency
operation_description
required_fields_missing
validation_errors
confidence
review_status
review_comment
export_status
export_id
created_at
processed_at
approved_at

Статусы `review_status`:

• `draft` - агент извлек реквизиты;
• `approved` - бухгалтер разрешил экспорт;
• `needs_fix` - нужно исправить данные или запросить документ;
• `rejected` - документ не принимаем;
• `error` - workflow не смог обработать файл.

Проверка: таблица готова принять одну строку на один документ.

Шаг 4. Создайте лист для правил проверки

Добавьте лист `validation_rules`.

Колонки:

rule_id
doc_type
field
required
check_type
error_text
severity

Заполните базовые правила:

R-001 | act | doc_number | yes | not_empty | Нет номера акта | high
R-002 | act | doc_date | yes | date | Некорректная дата акта | high
R-003 | act | seller_inn | yes | inn | Некорректный ИНН продавца | high
R-004 | act | buyer_inn | yes | inn | Некорректный ИНН покупателя | high
R-005 | act | total_amount | yes | positive_number | Сумма должна быть больше нуля | high
R-006 | upd | doc_number | yes | not_empty | Нет номера УПД | high
R-007 | upd | doc_date | yes | date | Некорректная дата УПД | high
R-008 | invoice | payment_details | yes | not_empty | Нет платежных реквизитов | medium
R-009 | any | currency | yes | enum:RUB,USD,EUR | Некорректная валюта | medium

Проверка: правила лежат в таблице, их можно менять без редактирования workflow.

Шаг 5. Создайте журнал ошибок

Добавьте лист `doc_errors`.

Колонки:

error_id
doc_id
file_name
step
error_type
error_text
raw_fragment
created_at
resolved_at

Проверка: если OCR, LLM или валидация упадут, ошибка будет видна бухгалтеру.

Шаг 6. Подготовьте тестовые файлы

Положите в `incoming_docs` 4 файла:

1. нормальный счет на оплату;
2. нормальный акт;
3. УПД;
4. документ с ошибкой, например без ИНН или с несовпадающей суммой.

Названия файлов:

test-invoice-ok.pdf
test-act-ok.pdf
test-upd-ok.pdf
test-act-missing-inn.pdf

Проверка: файлы открываются, текст читаемый или скан достаточно четкий.

Шаг 7. Создайте workflow в n8n

Назовите workflow:

Primary docs extract

Добавьте узлы:

1. `Schedule Trigger`;
2. `Google Drive` - поиск новых файлов в `incoming_docs`;
3. `Split In Batches`;
4. `Google Drive` - скачать файл;
5. `Code` - определить тип файла;
6. `OCR` или `HTTP Request` к Google Vision;
7. `LLM` или `HTTP Request` к LLM API;
8. `Code` - JSON validation;
9. `Google Sheets` - чтение `validation_rules`;
10. `Code` - business validation;
11. `Google Sheets` - запись `doc_queue`;
12. `Google Sheets` - запись `doc_errors`, если ошибка;
13. `Google Drive` - перенос файла в нужную папку.

Проверка: workflow создан, но пока запускается вручную.

Шаг 8. Настройте поиск новых файлов

В узле `Google Drive` укажите папку:

Accounting AI agent/incoming_docs

Фильтр:

mimeType = application/pdf
или image/png
или image/jpeg

Для первой версии обрабатывайте не больше 20 файлов за запуск.

Проверка: workflow видит тестовые файлы и возвращает `file_id`, `file_name`, `webViewLink`.

Шаг 9. Извлеките текст из PDF или изображения

Если PDF текстовый, используйте PDF parser.

Если это скан, отправьте файл в OCR.

Минимальный результат после OCR:

{
  "file_id": "abc123",
  "file_name": "test-act-ok.pdf",
  "raw_text": "Акт № 15 от 20.05.2026 Исполнитель ООО Ромашка ИНН..."
}

Проверка: `raw_text` содержит номер, дату, ИНН, сумму и название контрагента.

Шаг 10. Отправьте текст в LLM для извлечения реквизитов

System prompt:

Ты извлекаешь реквизиты из российских бухгалтерских документов.
Верни только валидный JSON.
Не придумывай данные.
Если поле не найдено, верни null.
Не делай бухгалтерских и налоговых выводов.

User prompt:

Текст документа:
{{raw_text}}

Верни JSON строго по схеме:
{
  "doc_type": "invoice|act|upd|invoice_factura|unknown",
  "seller_name": "string|null",
  "seller_inn": "string|null",
  "seller_kpp": "string|null",
  "buyer_name": "string|null",
  "buyer_inn": "string|null",
  "buyer_kpp": "string|null",
  "doc_number": "string|null",
  "doc_date": "YYYY-MM-DD|null",
  "contract_number": "string|null",
  "total_amount": "number|null",
  "vat_amount": "number|null",
  "currency": "RUB|USD|EUR|null",
  "operation_description": "string|null",
  "payment_details": "string|null",
  "confidence": 0.0,
  "warnings": ["string"]
}

Проверка: LLM возвращает JSON без Markdown и без пояснений.

Шаг 11. Проверьте JSON технически

Добавьте узел `Code`.

Проверки:

• JSON парсится;
• `doc_type` входит в разрешенный список;
• `total_amount` число или null;
• `vat_amount` число или null;
• `confidence` от `0` до `1`;
• дата в формате `YYYY-MM-DD`.

Если проверка не прошла, запишите в `doc_errors`:

step: json_validation
error_type: invalid_json
error_text: текст ошибки

Проверка: сломанный ответ модели не попадает в `doc_queue` как нормальный документ.

Шаг 12. Проверьте ИНН

Добавьте функцию проверки длины:

function isValidInn(value) {
  const inn = String(value || '').replace(/\D/g, '');
  return inn.length === 10 || inn.length === 12;
}

Для первой версии этого достаточно, чтобы ловить пустые и явно сломанные значения.

Правило:

seller_inn и buyer_inn обязательны для акта и УПД
если ИНН пустой или не 10/12 цифр -> needs_fix

Проверка: файл `test-act-missing-inn.pdf` получает ошибку по ИНН.

Шаг 13. Проверьте обязательные реквизиты первички

Для актов и УПД проверьте минимум:

• наименование документа;
• дата составления;
• продавец или исполнитель;
• покупатель или заказчик;
• содержание операции;
• сумма или натуральный измеритель;
• должности/подписи ответственных лиц, если они есть в форме;
• реквизиты сторон.

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

Проверка: документ без даты, номера, ИНН или суммы не получает `approved` автоматически.

Шаг 14. Проверьте суммы и НДС

В узле `Code` добавьте правила:

total_amount > 0
vat_amount >= 0
vat_amount <= total_amount
если vat_amount = null, добавить warning: НДС не найден
если валюта пустая, поставить RUB только если в документе есть рубли или символ ₽

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

Проверка: документ с НДС больше суммы получает `needs_fix`.

Шаг 15. Проверьте контрагента

Создайте лист `counterparties`.

Колонки:

name
inn
kpp
status
comment

Статусы:

• `approved`;
• `new`;
• `blocked`;
• `needs_check`.

Правило:

если seller_inn есть в counterparties и status = blocked -> rejected
если seller_inn отсутствует -> needs_review
если seller_inn approved -> продолжаем

Проверка: новый поставщик не проходит в экспорт без проверки.

Шаг 16. Найдите дубли

Перед записью в `doc_queue` проверьте, нет ли уже документа с той же комбинацией:

seller_inn + doc_type + doc_number + doc_date + total_amount

Если дубль найден:

review_status: needs_fix
validation_errors: Возможный дубль документа

Проверка: повторная загрузка того же PDF не создает второй approved-документ.

Шаг 17. Запишите черновик в doc_queue

После извлечения и проверок добавьте строку.

Если ошибок нет:

review_status: draft
validation_errors: пусто
confidence: значение модели

Если есть ошибки:

review_status: needs_fix
validation_errors: список ошибок

Если тип документа неизвестен:

doc_type: unknown
review_status: needs_fix
validation_errors: Не удалось определить тип документа

Проверка: каждый файл из `incoming_docs` получил строку в `doc_queue`.

Шаг 18. Перенесите файл после обработки

Правила переноса:

draft -> processed_docs
needs_fix -> needs_review_docs
rejected -> rejected_docs
error -> needs_review_docs

Проверка: в `incoming_docs` не остаются уже обработанные файлы.

Шаг 19. Проверьте документ бухгалтером

Бухгалтер открывает строку `draft` или `needs_fix`, сверяет файл и реквизиты.

Проверить вручную:

• правильный тип документа;
• дата и номер;
• ИНН/КПП сторон;
• сумма и НДС;
• договор;
• описание операции;
• подписи или ЭДО-статус;
• не дубль ли это;
• можно ли принимать документ в учет.

После проверки поставить:

review_status: approved
approved_at: текущая дата
review_comment: при необходимости

Или:

review_status: needs_fix
review_comment: запросить у поставщика корректный УПД

Проверка: без `approved` документ не уходит в экспорт.

Шаг 20. Создайте workflow для экспорта

Назовите workflow:

Primary docs export approved

Добавьте узлы:

1. `Schedule Trigger`;
2. `Google Sheets` - чтение `doc_queue`;
3. `Filter` по `review_status = approved` и `export_status` пусто;
4. `Code` - подготовка export JSON;
5. `HTTP Request` к учетной системе или запись CSV;
6. `Google Sheets` - обновление `export_status`;
7. `Google Sheets` - запись ошибки, если экспорт упал.

Проверка: workflow видит только approved-документы.

Шаг 21. Подготовьте JSON для 1С или учета

Минимальный export JSON:

{
  "external_id": "doc_id",
  "document_type": "act",
  "number": "15",
  "date": "2026-05-20",
  "seller": {
    "name": "ООО Ромашка",
    "inn": "7700000000",
    "kpp": "770001001"
  },
  "buyer": {
    "name": "ООО Покупатель",
    "inn": "7800000000",
    "kpp": "780001001"
  },
  "amount": 120000,
  "vat_amount": 20000,
  "currency": "RUB",
  "description": "Услуги по договору"
}

Проверка: JSON содержит только проверенные поля, а не сырой OCR-текст.

Шаг 22. Настройте CSV-экспорт, если API учета пока нет

Если 1С или учетная система пока не подключены, сделайте CSV.

Колонки:

external_id
doc_type
doc_number
doc_date
seller_inn
seller_kpp
seller_name
buyer_inn
buyer_kpp
buyer_name
total_amount
vat_amount
currency
operation_description
file_url

Проверка: бухгалтер может импортировать или вручную сверить CSV без доступа к n8n.

Шаг 23. Обновите статус экспорта

После успешной передачи:

export_status: exported
export_id: id документа в учетной системе или имя CSV
processed_at: текущая дата

Если экспорт упал:

export_status: error
validation_errors: текст ошибки экспорта

Проверка: по строке понятно, ушел документ в учет или нет.

Шаг 24. Добавьте уведомления бухгалтеру

Если в `doc_queue` есть больше 10 строк `needs_fix`, отправьте сообщение.

Текст:

В очереди первички 12 документов требуют проверки.
Откройте doc_queue и проверьте needs_fix.

Канал:

• Telegram;
• email;
• задача в Bitrix24;
• комментарий в 1С, если есть интеграция.

Проверка: документы с ошибками не лежат без реакции.

Шаг 25. Сделайте regression test

Создайте лист `test_cases`.

Колонки:

case_id
file_name
expected_doc_type
expected_status
expected_error
enabled

Добавьте тесты:

• нормальный счет;
• нормальный акт;
• нормальный УПД;
• документ без ИНН;
• документ без суммы;
• документ с неверной датой;
• дубль документа;
• новый контрагент;
• заблокированный контрагент;
• плохой скан.

Создайте workflow:

Primary docs regression test

Он прогоняет тестовые файлы и сравнивает фактический статус с ожидаемым.

Проверка: после изменения prompt или правил можно увидеть, что сломалось.

Шаг 26. Утвердите правила перед запуском

Перед регулярной обработкой бухгалтер должен подтвердить:

• список типов документов;
• обязательные поля;
• правила проверки ИНН/КПП;
• правила по НДС;
• правила по новым контрагентам;
• правила по дублям;
• формат экспорта;
• кто ставит `approved`.

Минимальное правило запуска:

нет approved без бухгалтера
нет экспорта без approved
нет автоматической оплаты счета
нет удаления исходного файла

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

Минимальная проверка результата

Прототип работает, если выполняются все пункты:

• файл из `incoming_docs` попадает в workflow;
• OCR или PDF parser извлекает текст;
• LLM возвращает строгий JSON;
• ИНН, дата, сумма и тип документа проверяются;
• ошибки попадают в `doc_errors`;
• результат появляется в `doc_queue`;
• без `approved` документ не экспортируется;
• approved-документ попадает в export JSON или CSV;
• дубли не проходят как новые документы;
• исходный файл не удаляется и остается доступен по ссылке.

Что нельзя автоматизировать в первой версии

• оплату счета;
• проведение документа в учете без бухгалтера;
• налоговые выводы по НДС;
• принятие документов с критичными ошибками;
• удаление исходников;
• обработку персональных данных без правил доступа;
• автосогласование новых или заблокированных контрагентов;
• массовый экспорт старой первички без regression test.

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

Можно ли сразу подключить 1С?

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

Нужно ли использовать OCR для всех документов?

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

Почему нельзя автоматически проводить документы?

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

Что делать с плохими сканами?

Отправлять в `needs_fix` с причиной `плохое качество распознавания`. Не пытайтесь восстанавливать суммы и ИНН догадками.

Какой минимум нужен для запуска?

Папка `incoming_docs`, таблицы `doc_queue`, `validation_rules`, `doc_errors`, n8n workflow, OCR/PDF extraction, LLM JSON extraction, бухгалтерский approval и экспорт только approved-документов.