AI-агент для сверки регистров и первички на n8n: конвейер без разработчика

Я потратила три года на то, чтобы понять одну простую вещь: сверка регистров — это не про интеллект, а про терпение. И именно поэтому её проще всего отдать роботу.

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

Если вы уже читали мою статью про сверку в ChatGPT Code Interpreter, это следующий шаг — от разовой сессии к автоматическому конвейеру, который работает без вас.

Что такое AI-агент для сверки и чем он отличается от обычной автоматизации

AI-агент для сверки — это узел в сценарии n8n, который получает на входе два массива данных (регистр и первичку), инструменты для их обработки и цель, а не жёсткий список команд. Он сам решает, как обработать нестандартную строку.

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

Разница особенно заметна на “грязных” данных: сканы под углом, PDF с нестандартной версткой, накладные без единого шаблона от разных поставщиков. Жёсткий скрипт на таких файлах просто падает с ошибкой. Агент подбирает способ распознать текст и идёт дальше.

Для финансиста это значит одно: конвейер не требует “чистых” входных данных. Вы отдаёте ему то, что реально присылают контрагенты и склад — а не идеальный экспорт из учётной системы.

Зачем сверку регистров вообще выносить в n8n, а не делать в Excel или чате

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

n8n решает три проблемы одновременно. Во-первых, конвейер запускается сам по расписанию или по событию — новый файл в папке, новое письмо с накладной. Во-вторых, один раз настроенное правило сопоставления работает стабильно, не меняется от вашего настроения или усталости в конце месяца. В-третьих, конвейер масштабируется: добавить вторую пару документов для сверки — это скопировать существующий блок нод, а не переписывать процесс заново.

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

Сравню три подхода к сверке по ключевым параметрам:

Таблица актуальна на июль 2026 года. Если сверка у вас разовая — на разовый аудит или due diligence — Code Interpreter в чате быстрее настроить. Если сверка регулярная — n8n окупает время настройки с первого же повторного запуска.

Из каких нод состоит конвейер сверки: разбор архитектуры

Базовый конвейер строится из шести блоков, каждый решает одну задачу. Разберу их по порядку прохождения данных.

Нода 1: приём документов

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

Для регистра источником обычно служит выгрузка из учётной системы в Excel или CSV, для первички — папка со сканами, PDF-счетами или Excel-реестром от контрагента.

Нода 2: обезличивание

Прежде чем данные уйдут в любой вызов нейросети, код в этой ноде заменяет реальные ИНН, названия компаний и ФИО на условные маски: “Контрагент 1”, “К01”, “XXX-1234”. Соответствия хранятся в отдельной защищённой таблице внутри вашего контура, не покидающей сервер.

Это обязательный шаг, а не рекомендация. Подробный разбор правил обезличивания я разбирала в статье про сверку в Code Interpreter — те же принципы применимы здесь один в один.

Нода 3: распознавание через AI Agent

Здесь работает модель с хорошим распознаванием текста — GPT-5.5 или Claude Sonnet 4.6. Задача ноды: превратить неструктурированный документ (скан, PDF, фото) в таблицу с чёткими полями — номер, дата, сумма, контрагент, позиции.

Нода 4: сопоставление по ключу

Код на Python или JavaScript сравнивает два массива данных по ключевому полю. Результат — три списка: совпало, есть в регистре но нет в первичке, есть в первичке но нет в регистре.

Нода 5: классификация расхождений через AI Agent

Вторая нода AI Agent берёт список несовпадений и объясняет каждое по-русски: техническая задержка проведения, реальная недостача, задвоение документа, ошибка в ключе сопоставления (например, опечатка в номере).

Нода 6: отчёт и уведомление

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

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

Прямой ответ: обезличивание — это отдельная нода Code в самом начале сценария, работающая по справочнику замен, который не покидает ваш контур.

Логика простая: код проходит по всем полям регистра и первички, находит ИНН (по формату — 10 или 12 цифр), названия организаций (по стоп-словам “ООО”, “ИП”, “АО”) и ФИО, заменяет их на условные метки, сохраняя соответствие в отдельной таблице. После обработки нейросетью коды присваиваются обратно, реальные значения возвращаются в финальный отчёт.

Вот промпт для генерации такого кода:

Напиши код на JavaScript для ноды Code в n8n. Задача: обезличить
финансовые данные перед отправкой в нейросеть.

На входе — массив объектов с полями: ИНН, название_контрагента,
сумма, номер_документа, дата, ФИО_подписанта.

Требования:
1. ИНН заменить на маску вида "ИНН-001", "ИНН-002" по порядку
   первого появления
2. название_контрагента заменить на "Контрагент 1", "Контрагент 2"
3. ФИО заменить на "Сотрудник A", "Сотрудник B"
4. Сумму и номер документа оставить без изменений
5. Сохранить таблицу соответствий "маска -> реальное значение"
   в отдельную переменную для обратной замены в конце сценария
6. Вернуть обезличенный массив и таблицу соответствий отдельно

Код должен работать в контексте ноды Code n8n (item.json доступен
через $input.all()).

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

Как AI-агент распознаёт первичку любого формата

Прямой ответ: агент получает файл и открытую инструкцию “извлеки поля X, Y, Z”, а не жёсткий шаблон под конкретную форму документа — это и позволяет ему работать с разными поставщиками без перенастройки.

Ключевая разница с обычным OCR: классическое распознавание текста требует точного шаблона документа и падает при малейшем отклонении верстки. AI Agent в n8n получает не координаты полей на странице, а смысловую задачу — и справляется даже когда накладная от нового поставщика выглядит совсем иначе, чем предыдущая.

Вот промпт для ноды распознавания:

Ты — агент распознавания первичных документов для финансового отдела.

На входе — текст документа (акт, накладная или счёт), извлечённый
из PDF или скана.

Извлеки следующие поля в формате JSON:
- номер_документа
- дата_документа (формат ДД.ММ.ГГГГ)
- контрагент_ИНН (если указан)
- контрагент_название
- сумма_с_НДС
- сумма_без_НДС
- перечень_позиций (массив: наименование, количество, цена)

Правила:
1. Если поле отсутствует в документе — верни null, не придумывай
   значение
2. Если сумма указана словами — переведи в число
3. Если найдено несколько дат — бери дату составления документа,
   не дату отгрузки
4. При неуверенности в распознавании конкретного поля добавь
   поле "confidence_flags" со списком сомнительных полей

Не добавляй пояснений вне JSON-структуры.

Флаг confidence_flags — это то, что превращает агента из чёрного ящика в инструмент, которому можно доверять. Строки с низкой уверенностью распознавания уходят в отдельный список на ручную проверку, а не смешиваются с надёжными данными.

Как построить логику сопоставления по ключу без ошибок

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

Частая ошибка новичков — доверить само сопоставление AI Agent ноде. На объёме больше сотни строк модели начинают путать похожие суммы или пропускать строки. Правильная архитектура: нейросеть готовит данные и предлагает ключ, а детерминированный код на Python или JavaScript выполняет само сравнение.

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

Напиши код на Python для ноды Code в n8n. Задача: сопоставить два
массива финансовых документов — "регистр" и "первичка".

Структура каждого элемента: {номер_документа, дата, сумма, контрагент}

Правила сопоставления:
1. Основной ключ — номер_документа (точное совпадение после
   удаления пробелов и приведения к верхнему регистру)
2. Если по номеру не нашлось совпадения — пробуем составной ключ:
   контрагент + сумма (округление до рубля) + дата с допуском
   ±3 дня
3. Если сумма отличается меньше чем на 1 рубль — считать совпадением
   (защита от округления НДС)
4. Разбить результат на три списка:
   - matched: строки, найденные в обоих массивах
   - only_in_registry: есть в регистре, нет в первичке
   - only_in_primary: есть в первичке, нет в регистре
5. Для каждой строки в matched указать, по какому правилу
   найдено совпадение (по номеру или по составному ключу)

Верни результат в формате JSON с тремя массивами и статистикой:
всего строк, совпало, расхождений.

По моим наблюдениям, сопоставление по точному номеру документа даёт 100% точность там, где номер вообще указан правильно. Составной ключ (контрагент + сумма + дата) добавляет ещё 5-12% совпадений, но с точностью 85-92% — эти строки стоит проверять глазами при первом внедрении конвейера, пока не убедитесь в стабильности правила.

Как классифицировать расхождения и не утонуть в списке несовпадений

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

После сопоставления у вас обычно остаётся 5-15% строк без пары. Не все они одинаково важны. Пропущенная накладная на 300 рублей из-за опечатки в номере — не то же самое, что реальная недостача товара на 200 000 рублей.

Промпт для ноды классификации:

Ты — финансовый аналитик, который разбирает расхождения после
сверки регистра и первичных документов.

На входе — список расхождений в формате:
{тип: "только_в_регистре" или "только_в_первичке", документ: {...}}

Для каждого расхождения определи категорию и присвой флаг:
- ТЕХНИЧЕСКАЯ_ЗАДЕРЖКА: документ близок по дате к концу периода,
  вероятно попадёт в сверку следующего месяца
- ОШИБКА_КЛЮЧА: похожий документ есть в другом массиве, но номер
  отличается на 1-2 символа (вероятная опечатка)
- ДУБЛИРОВАНИЕ: два похожих документа с одинаковой суммой
  и близкой датой в одном массиве
- ТРЕБУЕТ_ПРОВЕРКИ: реальное расхождение без очевидного объяснения,
  нужна проверка человеком

Для каждого флага добавь короткое объяснение на русском (одно
предложение) и приоритет проверки: высокий/средний/низкий.

Приоритет высокий — для сумм больше 50 000 рублей без объяснения.
Приоритет низкий — для технических задержек с суммой до 5 000 рублей.

Верни результат отсортированным по приоритету, высокий сначала.

Такая классификация сокращает время разбора расхождений в разы: вместо 40 строк без объяснения вы получаете 3-5 строк с высоким приоритетом, на которые действительно стоит потратить время, и остальные — с понятной причиной, не требующей вашего вмешательства.

Три готовых сценария сверки, которые можно собрать за вечер

Разберу три конкретных пары “регистр — первичка”, под которые уже готова архитектура выше — меняются только источник данных и ключ сопоставления.

Сценарий 1: акты выполненных работ против реестра поступлений

Ключ сопоставления — номер акта плюс сумма. Источник первички — папка с PDF-актами от подрядчиков, источник регистра — выгрузка из учётной системы по счёту “20” или аналогичному.

Сценарий 2: счета поставщиков против реестра оплат

Ключ — номер счёта плюс ИНН поставщика (после обезличивания — маска ИНН) плюс сумма с допуском на частичную оплату. Источник первички — почтовый ящик, куда поставщики присылают счета, источник регистра — банковская выписка или реестр платежей.

Сценарий 3: накладные против оборотно-сальдовой ведомости по товару

Ключ — номер накладной плюс артикул плюс количество. Здесь важно сопоставлять не только сумму целиком, но и позиции внутри документа — для этого промпт распознавания уже включает извлечение массива позиций.

Каждый из трёх сценариев использует одну и ту же архитектуру из шести нод — меняются только источники и правило ключа во второй ноде сопоставления. Это и есть главное преимущество n8n перед разовым промптом в чате: один раз построенный каркас переиспользуется под разные пары документов.

Кейс 1: сверка актов подрядчиков в строительной компании

Финансовый директор небольшой строительной компании (12 подрядчиков, около 80 актов в месяц) тратила на сверку актов с реестром поступлений почти день в конце каждого месяца.

Проблема была не в объёме, а в разнородности: каждый подрядчик присылал акты в своём формате — кто-то сканом, кто-то PDF с печатью, кто-то фото с телефона. Единого шаблона не было.

После настройки конвейера с распознаванием через AI Agent (промпт из раздела выше, с полем confidence_flags) время сверки сократилось до 25 минут машинной обработки плюс 20 минут на проверку строк с низкой уверенностью распознавания. Итог: с 7-8 часов в месяц до 45 минут, экономия около 7 часов ежемесячно.

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

Кейс 2: сверка счетов поставщиков в оптовой торговле

Бухгалтер оптовой компании с оборотом около 400 счетов в месяц от 60 постоянных поставщиков собирала сверку оплат вручную в Excel, тратя на это 2 полных рабочих дня в конце месяца.

После внедрения конвейера с составным ключом (контрагент + сумма + дата с допуском 3 дня) автоматическое сопоставление закрыло 91% строк без ручного вмешательства. Оставшиеся 9% — это счета с частичной оплатой и авансовые платежи, которые заведомо требуют ручной логики и были вынесены в отдельный флаг “частичная оплата, проверить остаток”.

Итог: время сверки сократилось с 16 часов до 3 часов в месяц (2 часа проверка флагов + 1 час финальная выгрузка). В моей практике экономия в пересчёте на ставку бухгалтера обычно измеряется тысячами рублей в месяц, а затраты на API нейросети при таком объёме документов остаются в пределах нескольких сотен рублей.

Кейс 3: сверка накладных со складским учётом в дистрибуции

Финансист дистрибьюторской компании с товарооборотом 15-20 накладных в день столкнулась с проблемой расхождений по количеству, а не только по сумме — товар мог прийти в другом объёме, чем заявлено.

Конвейер с извлечением позиций накладной (не только суммы целиком, а каждой строки товара отдельно) позволил сопоставлять не только документы, но и артикулы внутри них. Это выявило систематическую проблему с одним поставщиком: расхождение по количеству в 4-7% почти в каждой поставке за квартал — в накопленном итоге за три месяца сумма набегает заметная, хотя по отдельности каждое расхождение выглядело незначительным.

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

Как протестировать конвейер перед тем, как доверить ему регулярную работу

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

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

Если конвейер нашёл расхождение, которого не было в ручной сверке — разберитесь, ошибся код сопоставления или человек пропустил строку раньше. Часто оказывается второе.

Если конвейер, наоборот, не нашёл расхождение, которое было найдено вручную — проверьте логику ключа сопоставления, вероятно она слишком широкая и “склеивает” разные документы в одно совпадение.

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

Частые ошибки при сборке AI-агента для сверки

Разберу пять ошибок, которые встречаю у финансистов на курсе чаще всего.

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

Пропустить обезличивание. Даже “для теста” нельзя гонять реальные ИНН и суммы через публичный API без масок. Тестовые данные тоже обезличивайте, привычка формируется на любых данных.

Не тестировать на исторических периодах. Запуск конвейера сразу в бой без сверки с ручным результатом за прошлые месяцы — риск пропустить системную ошибку в логике ключа.

Слишком жёсткий ключ сопоставления. Требование точного совпадения по всем полям сразу даёт много ложных “расхождений” там, где документы на самом деле совпадают, просто с разницей в форматировании даты.

Забыть про уведомление о завершении. Конвейер, который работает молча, легко забыть проверить. Настройте уведомление в Telegram сразу при сборке, а не “потом добавлю”.

Что делать, если первичка приходит в нестандартных форматах каждый раз

Прямой ответ: используйте открытую инструкцию распознавания (промпт из раздела про AI Agent), а не жёсткий шаблон под конкретный формат — тогда разнородность форматов перестаёт быть проблемой архитектуры.

Если после трёх месяцев работы конвейера доля строк с флагом confidence_flags остаётся высокой (больше 15-20%) для конкретного поставщика — это сигнал не чинить промпт бесконечно, а договориться с этим поставщиком о едином формате присылки документов. Иногда организационное решение эффективнее технического.

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

Как масштабировать конвейер на несколько юрлиц или отделов

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

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

Финальный отчёт в этом случае группируется по юрлицам автоматически — одна нода сортировки перед выгрузкой в Excel решает задачу без дублирования всей архитектуры.

Что дальше: от разовой сверки к полному циклу закрытия месяца

Сверка регистров с первичкой — это один из блоков более широкого процесса закрытия месяца. Если конвейер сверки уже работает стабильно, следующий логичный шаг — подключить его как один из узлов в более широкую цепочку агентов для полного закрытия.

Я подробно разбирала такую архитектуру из семи специализированных агентов в статье про армию AI-агентов для закрытия месяца — конвейер сверки из этой статьи встраивается туда третьим узлом, между сбором данных и классификацией ДДС.

Если вы только начинаете с n8n и ещё не собирали ни одного сценария, начните с более простых пяти автоматизаций из статьи n8n для финансиста — сверка первички там разобрана в базовом варианте, без полной агентной архитектуры.

Чек-лист: соберите конвейер за 10 шагов

1. Определите пару документов и ключ сопоставления. Возьмите одну понятную пару — например акты против реестра поступлений.
2. Разверните n8n. Облачный триал для теста, self-hosted через Docker для регулярной работы с чувствительными данными.
3. Соберите ноду приёма документов. Папка на Google Диске, почта или ручная загрузка, триггер по расписанию.
4. Добавьте ноду обезличивания. Замена ИНН, названий и ФИО на маски до любого вызова нейросети.
5. Подключите распознавание через AI Agent. Модель GPT-5.5 или Claude Sonnet 4.6, промпт с полем confidence_flags.
6. Соберите ноду сопоставления по ключу. Код на Python или JavaScript, точный ключ плюс запасной составной ключ.
7. Добавьте классификацию расхождений. Вторая AI Agent нода с флагами приоритета: высокий, средний, низкий.
8. Настройте вывод отчёта. Excel или Google Таблица с цветовой разметкой плюс уведомление в Telegram.
9. Протестируйте на трёх исторических периодах. Сравните с известным ручным результатом построчно.
10. Поставьте на расписание. Только после трёх чистых прогонов подряд без расхождений с ручной проверкой.

Итоги: когда конвейер в n8n действительно окупается

AI-агент для сверки в n8n имеет смысл строить, когда сверка регулярная — раз в месяц, раз в неделю или чаще — и объём документов превышает 30-40 штук за период. На меньших объёмах или для разовой задачи быстрее и проще воспользоваться ChatGPT Code Interpreter прямо в чате.

Главная ценность конвейера не в скорости одного прогона (она сопоставима с чатом), а в том, что он повторяется без вашего участия месяц за месяцем, копит историю прогонов и постепенно выявляет системные проблемы — вроде систематической недостачи у конкретного поставщика из третьего кейса выше, которую ручная сверка просто не успевает заметить за рутиной.

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

Три канала, где я и Софья Бурцева разбираем AI для финансистов и делимся рабочими сценариями:

• Telegram-канал @findir_pro — 45 000 подписчиков, ежедневные разборы инструментов и кейсов
• Канал «АИ с Софьей и Натали» — 13 000 подписчиков, углублённые видеоразборы и прямые эфиры
• Сообщество в MAX — 5 000+ участников, живое обсуждение и обмен готовыми сценариями

Курс AI-навыков для финансистов от онлайн-школы «Финансовый директор | Мастер CFO» уже прошли 800+ выпускников. Основатель школы — Софья Бурцева, я отвечаю за экспертизу по нейросетям и продюсирование образовательных программ.