AI-агенты для финансиста
AI-агент для кредиторки и счетов поставщиков: закрываем участок за 20 минут
Счёт поставщика на крупную сумму уходит в просрочку задолго до платежа, на этапе приёма и разноса бумаг. Документ дважды переложили, и никто его не открыл. О деньгах в этот момент речь вообще не шла.
Я Натали Васильева, эксперт по нейросетям и продюсер онлайн-школы «Финансовый директор | Мастер CFO» (основатель школы Софья Бурцева). Через курс «AI-навыки финансиста» в этой школе прошло 800+ человек, и участок кредиторки стабильно в тройке самых частых запросов на автоматизацию вместе с дебиторкой и сверкой первички. Цифры, которые я привожу ниже без пометки «из реестра», это замеры по участкам учеников: я не выдаю их за отраслевую статистику. В статье разберу, как из этого участка собрать AI-агента, который проходит весь цикл за 20 минут: от письма со счётом до готового проекта платежа с цветовым статусом.
Дам 11 готовых промптов, три кейса с часами и рублями, сравнительную таблицу моделей и чек-лист из девяти шагов. Актуально на 21 сентября 2026 года, рабочие модели: GPT-5.5, Claude Sonnet 4.6, Gemini 2.5, DeepSeek V3.2. Сайт chatgpt.com из России без средств обхода доступа не открывается. Это ограничение конкретного сервиса: пользоваться нейросетями из России закон не запрещает.
С чего начать чтение
Ключевые тезисы статьи собраны в блоке выше, в самом начале. Если у вас мало времени, вот маршрут по тексту.
Двадцать минут. Прочитайте «Как собрать агента для кредиторки: архитектуру» и блок промптов: пункты 1, 3 и 5. Этого достаточно, чтобы понять, из чего состоит агент и что он делает с конкретным счётом.
Час. Добавьте к этому раздел про расчёт срока оплаты и красную зону и разбор ReAct-цикла: там объясняется, почему агент не падает на исключениях, а задаёт вопрос человеку.
Полдня или проект на своём участке. Читайте подряд, начиная с раздела про данные. Кейсы ниже дают ориентир по эффекту, раздел про ошибки внедрения сэкономит больше всего времени: там собраны грабли, на которые наступают почти все.
Ниже разберу каждый пункт: как устроен участок сегодня, чем агент отличается от чата, где проходит граница между автоматизацией и ответственностью, как выглядит полный цикл и что ломается на внедрении чаще всего.
Что такое кредиторская задолженность и почему участок считают аварийным?
Кредиторская задолженность это сумма, которую компания должна поставщикам, подрядчикам и другим контрагентам за поставленные товары, работы и услуги. Аварийным участок делает плотность ошибок: документы приходят по десятку каналов, сроки оплаты у каждого договора свои, а цена ошибки видна сразу.
Я работаю с финансистами с февраля 2023 года и вижу один и тот же набор болей. Документ теряется между почтой и папкой. Счёт приходит дважды, и второй раз его проводят. Условия отсрочки лежат в договоре, который никто не открывает, потому что он на 40 страниц. Закрывающий документ не пришёл, а платёж уже ушёл. Платёж уходит в пятницу, а у поставщика расчётный день понедельник.
Из этого набора и складывается представление об участке как об аварийном. Причина не в людях и не в квалификации: на единицу времени здесь приходится больше ручных решений, чем на любом другом участке финотдела.
Есть и вторая причина. Кредиторка это единственный участок, где ваша ошибка немедленно превращается во внешний конфликт. Дебиторка болит внутри компании, налоги болят раз в квартал. А просроченный счёт поставщику болит в тот же день, когда поставщик звонит вашему коммерческому директору.
Хочу сразу отсечь одно заблуждение, с которым я сталкиваюсь на консультациях постоянно. Размер долга ничего не говорит о состоянии участка. Компания с долгом в 300 миллионов может вести участок спокойно, если у неё есть реестр условий и понятный график. Компания с долгом в 4 миллиона живёт в режиме пожара, когда каждая оплата это переписка в мессенджере и поиск договора в почте. Аварийность задаёт плотность ручных решений на единицу времени.
Отсюда же следует и то, зачем вообще считать время на участке. Пока участок не измерен в часах, разговор о нём идёт в оценках: «много работы», «постоянно дёргают», «некогда заняться». Оценку нельзя проверить, поэтому такой разговор невозможно закончить. Разговор в часах заканчивается за одну встречу, потому что дальше либо часы есть, либо их нет.
Что такое AI-агент и чем он отличается от чата с моделью?
AI-агент это модель, которая сама решает, какие шаги сделать, с какими инструментами и в каком порядке, пока не получит результат. Чат ждёт вашего сообщения и возвращает текст. Агент запускается сам, открывает документ, обращается к базе, пишет строку в таблицу и отчитывается о результате.
Разница видна на одном примере. Вы просите чат разобрать счёт. Он разберёт ровно тот файл, который вы прикрепили, и вернёт ответ текстом, который вы руками перенесёте в реестр. Агент в понедельник в 8:40 сам забирает из почты двадцать три письма со счетами, читает каждое, сверяет с реестром договоров, отмечает три дубля, красит четыре счёта в красный и присылает вам сводку. Вы открываете её с кофе.
Технически агент это три части. Модель, которая понимает содержание документа. Инструменты, которыми модель действует: чтение почты, запись в таблицу, отправка сообщения. Память, в которой лежит реестр договоров, история платежей и прошлые решения по каждому поставщику.
Есть и четвёртая часть, про которую обычно забывают в презентациях: цикл. Модель смотрит на результат своего шага и решает, что делать дальше. Если сумма в счёте не бьётся с договором, она не останавливается и идёт искать причину: приложение к договору, дополнительное соглашение, прошлый акт.
Практическая разница между чатом и агентом измеряется в том, сколько раз вам нужно вспомнить о задаче. Чат работает только в те минуты, когда вы его открыли, и после закрытия окна задача возвращается к вам целиком. Агент работает по расписанию и возвращается с готовым результатом: сводка, реестр, проект платежа. Основной эффект по часам даёт эта разница, а не скорость чтения документа.
Из этого следует ещё один практический вывод, который я обычно произношу на первой консультации. Не пытайтесь сделать идеального агента с первого раза. Соберите сценарий, который закрывает 70% типовых счетов и делает это стабильно каждый день. Оставшиеся 30% останутся у человека, и это нормально, потому что они как раз и требуют суждения. Агент, который пытается закрыть 100% и ошибается в 15% случаев, хуже агента, который закрывает 70% и не ошибается вообще.
Шесть сюжетов, которые повторяются на каждом участке
Это не выборка из чужих обсуждений, а шесть ситуаций, которые я вижу на разборах участка у учеников и на консультациях с февраля 2023 года. Сюжеты повторяются с такой регулярностью, что по ним удобно проверять свой участок. Если узнаёте три и больше, проект даст эффект.
Первый сюжет: счёт потерялся между людьми. Документ пришёл на общую почту, его переслали менеджеру, менеджер уехал на встречу, письмо осталось в его ящике. Через три недели поставщик звонит и спрашивает, где деньги. Виноватого ищут долго, потому что формально каждый сделал свою часть работы.
Второй сюжет: двойная оплата одного счёта. Один экземпляр пришёл по почте, второй принёс курьер, третий прислали в мессенджере. Два разных человека провели два платежа, потому что ни у кого нет единого реестра, где видно, что счёт уже в работе.
Третий сюжет: условия договора существуют отдельно от работы. Бухгалтер уверен, что у поставщика отсрочка 30 дней, потому что так было всегда. В договоре, подписанном в этом году, стоит 14 дней и штраф за каждый день просрочки. Узнают об этом из претензии.
Четвёртый сюжет: участок держится на одном человеке. Пока он на месте, всё работает, потому что порядок живёт у него в голове. На второй неделе отпуска начинается пожар, а после увольнения участок пересобирают с нуля несколько месяцев.
Пятый сюжет, самый частый: у компании нет одной версии договоров. Реестр есть у юристов, у закупки и в бухгалтерии, и во всех трёх версиях условия отсрочки разные. Из этого сюжета напрямую вырастает задача для агента: машина не умеет работать с тремя правдами одновременно.
Шестой сюжет, который встречается реже остальных и стоит внимания: люди, которые участок перестроили и довольны. Их объединяет одно: они перестали быть посредниками между документом и системой. Вместо «я перекидываю счёт в 1С» звучит «я принимаю решение по счёту, а перекидывает машина». Про этот переход и будет практическая часть ниже.
Отдельно про эмоции на разборах, потому что они точнее всего описывают суть проблемы. Раздражение появляется не там, где человек ленится. Оно появляется там, где никто не может назвать, чья это задача. Счёт пришёл на общую почту, значит он ничей. Менеджер переслал его не тому, значит виноват менеджер. Бухгалтерия не увидела письмо, значит виновата бухгалтерия. В системе без точки ответственности виноватым оказывается последний, кто держал документ в руках, а это почти всегда случайный человек.
Ключевое наблюдение здесь такое: почти все сюжеты выше рассказывают про отсутствие процесса, который не зависит от памяти конкретных людей. Счёт теряется не потому, что бухгалтер забыл, а потому что ни у кого в компании нет списка, по которому можно проверить, все ли документы на месте.
Поэтому разговор о нейросети на этом участке стоит начинать с инвентаризации процесса, а не с выбора модели. Что происходит со счётом с момента, когда он пришёл, до момента, когда деньги ушли. Сколько в этом пути ручных решений. Какой из шагов выполняется по одному правилу, а какой требует головы.
| Сюжет | Корневая причина | Что это стоит компании | Что чинит агент |
|---|---|---|---|
| Счёт потерялся между людьми | Нет единой точки сбора | Штраф, остановка отгрузок, простой | Сбор из всех каналов в одно место |
| Двойная оплата | Нет проверки на дубль | Возврат денег, разрыв с поставщиком | Проверка по номеру, сумме, дате |
| Условия договора не в работе | Реестр договоров не ведётся | Штрафы, потеря скидок | Сверка счёта с условиями договора |
| Участок держится на одном человеке | Знание не оцифровано | Риск при отпуске и увольнении | Правило решений описано и работает |
| Три версии реестра | Нет владельца данных | Спор внутри компании при каждой сверке | Один источник условий для всех |
Почему аварийность участка выгодна и кому?
Участок счетов поставщиков выглядит аварийным, потому что в нём сходятся интересы закупки, бухгалтерии и казначейства. Закупка хочет отгрузку сегодня, бухгалтерия ждёт закрывающие документы, казначейство смотрит на остаток на счёте. Пока эти три взгляда живут в разных таблицах, участок не может быть спокойным по устройству.
Но у этого есть вторая сторона, про которую на презентациях про автоматизацию говорить не принято. Непрозрачный участок кому-то в компании удобен. Не потому, что кто-то злой умысел имеет, а потому, что прозрачность создаёт неудобные вопросы, на которые нет хорошего ответа.
Вот четыре позиции, где я чаще всего вижу тихое сопротивление на старте проекта.
Закупка. Ей нужно, чтобы этап закупки не был виден как отдельное звено со своим сроком. Если реестр покажет, что счёт пришёл на почту закупки 3-го числа, а в бухгалтерию попал 12-го, то девять дней простоя получат конкретный адрес. Раньше эти девять дней растворялись в общем «документ где-то ходит». Человек, у которого и так сорок задач и план по отгрузке, не заинтересован, чтобы его этап начали измерять.
Руководитель отдела, который «держит всё в голове». Его ценность в компании частично держится на том, что только он знает, где лежат договоры и какие условия с какими поставщиками. Агент с реестром эту монополию снимает. Сопротивление здесь почти никогда не звучит как «я против автоматизации». Оно звучит как «давайте сначала наведём порядок, а потом уже автоматизировать» или «у нас слишком специфичный участок, шаблон не подойдёт».
Сотрудник, чью работу упростят. Звучит контринтуитивно, но это самый частый случай. Если участок занимал 38 часов, а станет занимать 8, человек справедливо спрашивает: а что с моей ставкой и моими тридцатью часами. Если на этот вопрос нет ответа до запуска, вы получите не союзника, а тихое саботаже: данные будут попадать в агент неполными, а ошибки разбираться медленно.
Сам финдиректор. Здесь сопротивление другого рода. Автоматизированный участок показывает финдиректору больше, чем он, возможно, хотел знать. Например, что систематическая просрочка по трём поставщикам тянется четвёртый квартал, а внутри компании об этом никто не поднимал вопрос. Пока картина размазана по таблицам, её можно не замечать.
Что с этим делать на практике, если вы запускаете проект. Четыре хода, которые я советую сделать до технической части.
Первое: решите заранее, что вы показываете в отчёте, а что нет. Реестр может показывать сроки по зонам без разбивки по отделам. Тогда вы получаете управляемость, но не превращаете проект в инструмент персональной ответственности. Определите это до запуска, а не после первого конфликта.
Второе: снимайте метрику по процессу, а не по человеку. Пока агент отвечает на вопрос «сколько дней документ идёт от поставщика до платежа», спорить с ним некому. Как только он начнёт отвечать на вопрос «кто задержал», у проекта появятся враги в первый же месяц.
Третье: ответьте на вопрос про освободившиеся часы до того, как их освободите. Публично и с руководителем. Это может быть сверка с поставщиками, которую никогда не успевали делать, или автоматизация соседнего участка. Человек, который знает, куда денутся его тридцать часов, относится к проекту спокойно.
Четвёртое: начинайте с одного отдела, где есть союзник. Обычно это бухгалтерия: ей участок больше всех надоел. Если первым в проект войдёт отдел, который сопротивляется, вы потратите месяц на споры вместо калибровки.
Второй источник аварийности это распределение ответственности. В большинстве компаний, где я разбирала участок, счёт проходит через четыре пары рук, и на каждой передаче есть шанс, что документ задержится. Закупка получила счёт от поставщика и передала в бухгалтерию, бухгалтерия проверила и передала казначейству, казначейство согласовало у финдиректора, финдиректор утвердил реестр. Четыре передачи это четыре точки, где документ может пролежать день-два без движения и без виноватого.
Когда счёт стоит в очереди, никто не переживает: очередь это норма. Проблема в том, что очередь невидима. Никто в компании не может сказать, сколько счетов сейчас в работе и на какой стадии каждый. Эту невидимость агент убирает в первую очередь, ещё до всякой экономии часов.
Какие данные нужны агенту для работы с кредиторкой?
Агенту нужны четыре набора данных, и без любого из них он будет ошибаться предсказуемо и регулярно. Первый это сами счета: файл или письмо с номером, датой, суммой, реквизитами и назначением платежа. Второй это реестр договоров с условиями отсрочки, скидок и штрафов. Третий это история платежей по каждому контрагенту за последние 6-12 месяцев. Четвёртый это справочник лимитов и уровней согласования внутри компании.
Самый дефицитный из четырёх это реестр договоров. Его почти никогда нет в готовом виде, и его приходится собирать руками один раз. Я обычно предлагаю делать это не по всем контрагентам сразу, а по ABC-принципу: двадцать поставщиков, которые дают восемьдесят процентов суммы долга, покрывают почти весь эффект.
| Данные | Где взять | Кто отвечает | Обновление |
|---|---|---|---|
| Счета и накладные | Почта, папка, мессенджеры, ЭДО | Бухгалтерия | По мере поступления |
| Условия договоров | Договоры, допсоглашения, спецификации | Юрист и закупка | При подписании нового договора |
| История платежей | Банковская выписка, учётная система | Казначейство | Ежедневно |
| Лимиты и уровни согласования | Внутренний регламент, приказ | Финдиректор | Раз в квартал |
Отдельная история это качество распознавания. Скан с плохой печатью, где сумму 178 000 можно прочитать как 118 000, опаснее отсутствующего счёта: цифра выглядит правдоподобно, ничем не выделяется и уходит в платёж. Поэтому в промптах ниже у модели всегда есть право вернуть пустое поле, но нет права угадать.
Про сбор данных скажу отдельно, потому что это место, где проекты чаще всего буксуют. В компаниях, с которыми я работаю на курсе (в основном 200-500 человек), картина повторяется: счета приходят на общий ящик бухгалтерии, часть на ящик менеджера, часть в мессенджер, часть в ЭДО, а ещё часть привозит курьер в бумаге. Единого реестра нет, потому что его никогда не заводили. Пока вы не сведёте все каналы в одну точку, любая автоматизация строится на песке.
Наводя порядок, не пытайтесь решить всё сразу. Начните с одного канала, который даёт больше всего документов, обычно это общая почта. Настройте правило: всё, что похоже на счёт, автоматически попадает в одну папку. Имя файла строится по шаблону с датой и номером. Через неделю такой практики у вас появится то, чего не было никогда: список всех документов, пришедших за период.
И ещё одна вещь, которую я советую делать до всякой технической работы. Возьмите один закрытый месяц и вручную пройдите по всем счетам, которые были оплачены. Посчитайте, сколько времени прошло от поступления документа до ухода денег, и найдите пять счетов с самым долгим сроком. Причина задержки в этих пяти счетах и есть настоящая задача проекта. Она не всегда совпадает с тем, что кажется проблемой на первый взгляд.
Как выглядит полный цикл агента по кредиторке от счёта до платежа?
Цикл состоит из пяти блоков, и каждый из них можно собирать и отлаживать отдельно. Первый блок это сбор: агент забирает документы из почты, из сетевой папки, из мессенджеров, при необходимости из ЭДО. Второй блок это извлечение: модель превращает счёт в строгую структуру с полями.
Третий блок это сверка. Агент сопоставляет счёт с договором и с историей: соответствует ли цена, есть ли лимит на отгрузку без предоплаты, приходил ли этот счёт раньше, есть ли закрывающие документы по предыдущим поставкам.
Четвёртый блок это классификация по сроку. Тут работает обычная арифметика, а не модель: дата договорной отсрочки минус сегодняшняя дата. Модель нужна для объяснения, а не для счёта дней. Это принципиальный момент, который экономит много нервов при отладке.
Пятый блок это действие. Сводка в Telegram, строка в реестре, проект платёжного поручения для зелёной зоны, напоминание ответственному за жёлтую и красную.
Важная деталь про время. Двадцать минут это не время на один счёт, а время на весь прогон по участку. Типовой счёт обрабатывается за секунды: модель прочитала, сверила с реестром, вернула строку. Двадцать минут уходит на счета, где модель останавливается и идёт проверять: сумма не бьётся, поставщик новый, договор не найден, документ похож на дубль. Таких счетов обычно 10-15% от потока, и именно на них тратится основной бюджет времени прогона.
Именно поэтому я не советую оценивать агента по средней скорости обработки одного документа. Средняя скорость почти не зависит от качества сборки. Ошибки видны на исключениях: если агент не умеет корректно останавливаться и помечать сложный счёт, он будет уверенно выдавать неверный результат, и вы потеряете к нему доверие в первую же неделю.
Как считается срок оплаты и что попадает в красную зону?
Срок считается от даты исполнения обязательства, а не от даты получения счёта, и это первая ошибка в самодельных таблицах. По умолчанию для большинства договоров поставки отсчёт идёт от даты поставки или от даты подписания закрывающего документа. Если в договоре стоит другая привязка, она должна быть в реестре явно.
Вторая ошибка это календарные и рабочие дни. Договор говорит «14 календарных дней», а платёжный день в компании вторник и четверг. Формально вы в сроке, фактически платёж уходит на два дня позже.
Категории я предлагаю держать простыми. Красная зона это меньше двух рабочих дней до крайнего срока или прямое условие штрафа. Жёлтая это от двух до семи дней. Зелёная это больше недели запаса. Четыре цвета не нужны, три категории человек удерживает в голове без шпаргалки.
Скажу отдельно про базу отсчёта, потому что это источник половины спорных ситуаций с поставщиками. В договорах поставки встречаются четыре варианта привязки: от даты поставки, от даты подписания накладной, от даты получения счёта, от даты приёмки по качеству. Разница между ними в реальности может составлять две недели, и если в реестре стоит неверная привязка, вы будете систематически ошибаться по этому контрагенту, причём в одну сторону.
Поэтому в реестр договоров я прошу заносить не только количество дней, но и поле «база отсчёта» с номером пункта договора. Когда поставщик присылает претензию, вы открываете реестр и видите не «мы думали, что 30 дней», а «пункт 5.3, отсчёт от даты подписания накладной». Это разные по силе аргументы в разговоре.
Что такое ReAct-цикл и как агент сам находит проблемы в счёте?
ReAct это схема работы агента, в которой модель чередует рассуждение и действие: подумала, сделала шаг, посмотрела на результат, подумала снова. Этот цикл и отличает агента от обычного сценария с жёсткой последовательностью шагов.
Сценарий идёт по рельсам: если документа нет в папке, он просто останавливается и пишет ошибку. Агент идёт искать. Документ не найден в почте, значит нужно посмотреть в папке. Файл есть, но сумма не бьётся с договором, значит нужно найти приложение к договору. В приложении указана другая цена, значит нужно поднять историю и понять, когда условие менялось.
Ровно так же работает и человек, который давно ведёт участок. Разница в объёме: человек проделывает этот путь для одного счёта, агент для двадцати трёх за один прогон.
Название схемы пришло из научной статьи 2022 года, но применяют её сегодня почти все агентские инструменты. Вам для сборки агента знать детали не нужно. Достаточно понимать одно: модель должна получать результат своего предыдущего шага и принимать следующее решение на его основе, а не идти по заранее прописанному списку действий.
Практическая ценность ReAct-цикла в том, что он позволяет агенту не врать, когда данных не хватает. Сценарий с жёсткой последовательностью шагов в такой ситуации падает с ошибкой, а разбираться с ошибкой всё равно человеку. Агент с циклом возвращает не «ошибка», а «в счёте нет номера договора, я не смог сверить условия, вот что нашлось в истории по этому ИНН». Первое сообщение требует от вас расследования, второе требует решения.
Есть у этого подхода и цена: агент тратит больше токенов, потому что каждый шаг рассуждения тоже оплачивается. На типовом счёте разница незаметна, на потоке из двухсот документов она видна в счёте за месяц. Поэтому на массовой обработке однотипных счетов я обычно ограничиваю глубину цикла: два-три шага на документ, дальше остановка с вопросом к человеку.
Как собрать агента для кредиторки: архитектура
Архитектура укладывается в четыре слоя, и я советую собирать их строго по порядку, а не все сразу.
Слой данных. Единая папка или таблица, куда попадает каждый счёт. Плюс реестр договоров, плюс выгрузка истории платежей. Этот слой не содержит никакого AI, и он определяет, будет ли работать всё остальное.
Слой инструментов. Чтение почты, чтение файлов, запись в Google Таблицы или базу, отправка сообщения в Telegram, обращение к API модели.
Слой решений. Промпты и правила: извлечение полей, сверка с договором, классификация, формулировка рекомендации.
Слой действий. Что происходит с результатом: сводка, проект платежа, напоминание, запись в историю.
Про порядок сборки скажу отдельно, потому что на этом ломается большинство проектов. Люди начинают со слоя решений, потому что он самый интересный, и пишут красивый промпт для разбора счёта. Потом выясняется, что документы лежат в четырёх местах, реестра договоров нет, а история платежей не выгружается. Промпт при этом отличный и абсолютно бесполезный.
Начинать правильнее с последнего слоя и идти назад. Сначала решите, что должно происходить с результатом: кто утром открывает сводку, где лежит реестр, кто подписывает платёж. Потом опишите решения, которые приводят к этому результату. И только потом собирайте данные и инструменты под эти решения. Такой порядок кажется медленнее, но он экономит недели, потому что вы не строите то, чем никто не будет пользоваться.
Технически всё это собирается в любом конструкторе, где есть расписание, чтение файлов, вызов модели и отправка сообщения. На курсе мы разбираем n8n, но подойдёт и другой инструмент. Что действительно важно: в конструкторе должны быть три вещи. Триггер по расписанию, HTTP-запрос к модели и запись в таблицу. Если чего-то из этого нет, лучше выбрать другой инструмент сразу, чем потом дописывать костыли.
Пошаговая настройка: от пустого холста до рабочего прогона
Ниже девять шагов, за которые участок переезжает на агента. Первые пять не требуют никаких технических знаний, и именно они занимают больше всего времени.
- Замерьте участок в часах. Возьмите один закрытый месяц и посчитайте трудозатраты на приём, разнос, сверку и согласование счетов. По замерам в компаниях на курсе это 30-45 часов на 120-180 счетов.
- Опишите правило решений одним абзацем. Что делаем со счётом в пределах лимита, что при превышении, что при отсутствии договора, что при дубле.
- Соберите реестр договоров. Срок отсрочки, скидка за раннюю оплату, штраф за просрочку, условие приостановки отгрузок, лимит отгрузки без предоплаты. Начните с двадцати ключевых поставщиков.
- Наведите порядок в точке сбора. Один канал, одно место, понятная структура имён файлов. Это самая скучная часть проекта и самая полезная.
- Опишите, что считается дублем. Совпадение номера и суммы, совпадение суммы и даты, совпадение реквизитов при разных номерах. Правило должно быть записано, иначе агент будет ошибаться в обе стороны.
- Соберите извлечение данных. Модель возвращает строгий JSON по счёту с правом вернуть пустое поле, но без права угадать.
- Добавьте сверку с договором и историей. Сравнение суммы с лимитом, проверка отсрочки, поиск предыдущих поставок и закрывающих документов.
- Реализуйте классификацию и доставку. Три цветовые зоны по сроку, сводка в Telegram, строка в реестре, проект платежа для зелёной зоны.
- Прогоните на закрытом месяце. Сверьте выводы с тем, что уже проведено руками. Расхождения разделите на две группы: правило не описано и правило описано неверно.
Обычно на шаги 1-5 уходит неделя при занятости час в день, на шаги 6-8 ещё три-четыре дня, на девятый шаг и калибровку около недели. Итог: 2-3 недели от идеи до боевого режима.
Три кейса: что изменилось на участке
Кейсы ниже из практики школы, цифры приведены округлённо, названия компаний не раскрываю.
Напоминаю: это опыт школы на небольших и средних компаниях, а не статистика отрасли. Часы до и после мы замеряли по закрытым месяцам. Суммы называю округлённо и с оговоркой: точные цифры из платёжек учеников я не раскрываю, но масштаб они показывают.
Кейс первый: оптовая торговля, 150 счетов в месяц. Точка А: участок ведёт один бухгалтер, 35-40 часов в месяц, просрочки почти каждый квартал, одна из них привела к приостановке отгрузок на несколько дней. Что дал агент: прогон занимает 20-25 минут, бухгалтер разбирает только красную зону, то есть единицы счетов вместо всех ста пятидесяти. Освободилось около 30 часов в месяц, просрочек за следующий квартал ноль. Отдельный эффект, которого не ждали: агент нашёл дубль прошлого периода на сумму около 1 миллиона рублей, который ушёл бы вторым платежом. Компания вернула эти деньги из переплаты поставщику зачётом через три недели. Проверяемая часть здесь простая: 150 счетов и 35-40 часов до, 8-10 часов после, остальное бухгалтер делает головой.
Кейс второй: строительный подряд, 60 счетов и много актов. Точка А: проблема не в объёме, а в сверке актов с договорами. Каждый акт сверялся руками с приложением к договору, где цена менялась несколько раз за год. На сверку уходило 6-8 часов в неделю, то есть почти полная рабочая неделя в месяц. Что дал агент: он читает акт, поднимает нужное приложение и отмечает расхождение. Сверка занимает минуты вместо часов, и она больше не зависит от того, помнит ли конкретный человек, что подписывали во втором квартале. Экономия здесь измеряется не в рублях, а в снятой зависимости от памяти одного сотрудника: 6-8 часов в неделю против примерно одного часа.
Кейс третий: производство, 90 счетов и жёсткий платёжный календарь. Точка А: просрочек нет, зато теряются скидки. Четыре поставщика давали скидку 2-5% за оплату в течение семи дней от поставки, окно открывалось и закрывалось внутри недели, и регулярно проходило мимо. Что дал агент: он считает окно скидки отдельно от крайнего срока оплаты и подсвечивает его за два дня до закрытия. За квартал по этим четырём поставщикам вернулось около 340 тысяч рублей скидок при объёме закупок по ним порядка 11 миллионов рублей за квартал. Оговорюсь сразу: доля эффекта зависит от того, сколько поставщиков у вас вообще дают скидку и какой у них порог. Если скидок в договорах нет, этот источник не появится, зато заработают первые два.
| Показатель | Кейс 1: опт | Кейс 2: подряд | Кейс 3: производство |
|---|---|---|---|
| Счетов в месяц | около 150 | 60 | 90 |
| Было часов в месяц | 35-40 | около 25 | около 20 |
| Стало часов в месяц | 8-10 | 4-6 | 3-5 |
| Экономия часов | около 30 | 20 | 15-17 |
| Эффект в деньгах | Возвращён дубль около 1 млн ₽ | Сверка не зависит от человека | Возвращено около 340 тыс. ₽ скидок |
| Срок сборки | 2-3 недели | 2 недели | 2-3 недели |
Что общего у этих трёх кейсов, кроме цифр. Во всех трёх участок вёл один человек, и во всех трёх он не жаловался на объём как таковой. Жалоба была на другое: приходится держать в голове слишком много условий сразу, а голова не таблица. Именно это и есть настоящая причина, по которой участок кредиторки считают аварийным.
Сравнительная таблица моделей для участка кредиторки
Выбор модели зависит от того, что именно вы делаете на участке. Для длинного договора важно окно контекста, для массовой обработки важна цена токена, для сложной сверки важно качество рассуждения.
| Модель | Где сильнее | Слабое место | Когда брать |
|---|---|---|---|
| GPT-5.5 | Классификация, диалог, стабильный JSON | Длинный договор целиком читает неохотно | Массовая обработка счетов и сводки |
| Claude Sonnet 4.6 | Длинные документы, акты, договоры с приложениями | Дороже на больших объёмах | Сверка договоров и спорных поставок |
| Gemini 2.5 | Табличные сверки, работа с большими выгрузками | Формат ответа иногда приходится чинить | Сверка реестра платежей с выпиской |
| DeepSeek V3.2 | Стоимость обработки, типовые счета | Требует аккуратности в проверке | Большие объёмы однотипных документов |
Актуально на 21 сентября 2026 года. Я не советую выбирать одну модель навсегда: связка из двух, где одна читает длинные документы, а вторая обрабатывает массовые счета, обычно выходит и точнее, и дешевле, чем попытка решить всё одной.
Как это выглядит на практике. Раз в сутки агент прогоняет весь поток счетов через недорогую модель: она извлекает поля, проверяет дубли и считает сроки. Счета, где что-то не сошлось, попадают в отдельный список, и уже по ним работает модель с большим контекстом: она читает договор целиком, ищет дополнительное соглашение и объясняет расхождение. Такой двухступенчатый прогон стоит заметно меньше, чем попытка прогнать весь объём через самую дорогую модель.
Отдельно скажу про локальные модели, потому что этот вопрос мне задают на каждой консультации. Локальная модель на своём сервере решает вопрос с конфиденциальностью целиком: данные не покидают вашу инфраструктуру. Платите вы за это необходимостью держать железо, обновлять модель и мириться с тем, что качество рассуждений у открытых моделей ниже, чем у топовых облачных. Мой практический совет: локальная модель для договоров с ценами, облачная для типового потока по обезличенным контрагентам.
11 готовых промптов для участка кредиторки
Промпты ниже рабочие, я использую их с учениками на курсе. Подставляйте свои поля и не сокращайте блоки с запретами: именно они удерживают модель от правдоподобных выдумок.
Два правила, общих для всех одиннадцати. Первое: там, где есть выбор, модель должна возвращать значение из закрытого списка, а не свободный текст. «Красная», «жёлтая», «зелёная» лучше, чем «высокий риск оплаты в ближайшее время». Закрытый список потом легко считается формулой, свободный текст приходится разбирать человеку.
Второе: у модели всегда должно быть право сказать «не знаю». Это звучит странно, но именно это право отличает рабочего агента от опасного. Модель, которой запрещено оставлять пустое поле, заполнит его правдоподобным значением, и вы получите счёт, свёрстанный с придуманным номером договора. Модель, которой разрешено промолчать, вернёт пустоту, и вы увидите её сразу.
1. Извлечение данных из счёта поставщика
Ты помощник по первичке финансового отдела.
Прочитай счёт поставщика и верни СТРОГО JSON, без пояснений и без markdown-обёртки:
{
"номер": "",
"дата": "ГГГГ-ММ-ДД",
"поставщик": "",
"инн": "",
"сумма_итого": 0,
"ндс": 0,
"назначение": "",
"номер_договора": "",
"дата_договора": ""
}
Правила:
- Если поле не читается или его нет в документе, оставь пустую строку или 0.
- НЕ угадывай номер договора: если в счёте есть только фраза "по договору", оставь пусто.
- Сумму бери из строки "Всего к оплате", а не из строки с НДС.
- Дату приводи к формату ГГГГ-ММ-ДД.Что должно прийти на выходе. Хороший счёт:
{"номер": "ЦБ-4471", "дата": "2026-09-04", "поставщик": "ООО «Вектор-Снаб»", "инн": "7712345678", "сумма_итого": 178000, "ндс": 29667, "назначение": "За кабель по счёту", "номер_договора": "17/П-25", "дата_договора": "2025-11-12"}Счёт со сработавшим запретом на выдумывание:
{"номер": "б/н от 02.09", "дата": "2026-09-02", "поставщик": "ИП Логинов А.С.", "инн": "502345678901", "сумма_итого": 0, "ндс": 0, "назначение": "Транспортные услуги", "номер_договора": "", "дата_договора": ""}Вторая карточка выглядит хуже, но она честная: сумма не прочиталась, номер договора в документе отсутствует. Такой счёт уходит на разбор человеку. Если бы модель «догадалась» подставить сюда сумму из строки с НДС или номер похожего договора, вы получили бы правдоподобную строку в реестре и ошибку в платеже через неделю.
2. Проверка счёта на дубль
Ты контролируешь дубли счетов поставщиков.
Вот новый счёт: {данные нового счёта}
Вот история счетов этого поставщика за последние 90 дней: {список: номер, дата, сумма}
Определи, есть ли дубль. Верни:
1) Вердикт: дубль / не дубль / возможный дубль
2) Основание: какие поля совпали
3) Если это возможный дубль, что нужно проверить человеку
Считай дублем совпадение номера и суммы. Совпадение только суммы при разных номерах
это "возможный дубль", а не дубль.3. Сверка счёта с условиями договора
Ты сверяешь счёт поставщика с условиями договора.
Счёт: {данные счёта}
Условия договора из реестра: {срок отсрочки, лимит, скидка, штраф, база отсчёта}
Проверь:
- не превышает ли сумма счёта договорный лимит отгрузки без предоплаты;
- соответствует ли цена позиции условиям договора или спецификации;
- от какой даты считается отсрочка по этому договору.
Верни список расхождений. Если расхождений нет, напиши "расхождений нет" одной строкой.
Не выдумывай условия, которых нет в переданном реестре.4. Расчёт крайнего срока оплаты
Рассчитай крайний срок оплаты счёта.
Дано:
- дата исполнения обязательства: {дата}
- договорная отсрочка: {N} календарных дней
- база отсчёта по договору: {дата поставки / дата акта / дата счёта}
- платёжные дни компании: {список дней недели}
- сегодняшняя дата: {дата}
Шаги:
1) Определи дату, от которой считается отсрочка, по базе отсчёта.
2) Прибавь отсрочку в календарных днях.
3) Если крайний срок попадает на нерабочий или неплатёжный день,
перенеси платёж на ближайший предыдущий платёжный день.
Покажи цепочку: дата отсчёта -> плюс отсрочка -> перенос -> итоговый день.5. Классификация счёта по зоне риска
Определи зону риска для счёта.
Данные: крайний срок оплаты {дата}, сегодня {дата}, число рабочих дней между ними {N},
есть ли штраф по договору {да/нет}, есть ли скидка за раннюю оплату {условие}.
Правила:
- КРАСНАЯ: менее двух рабочих дней до крайнего срока ИЛИ прямое условие штрафа.
- ЖЁЛТАЯ: от двух до семи рабочих дней.
- ЗЕЛЁНАЯ: более семи рабочих дней и нет штрафных условий.
Верни зону, число оставшихся рабочих дней и одну строку объяснения,
почему счёт попал в эту зону. Объяснение пиши так, чтобы его можно было
показать руководителю без переписывания.Вот как выглядит ответ на тихом счёте:
ЗОНА: жёлтая
Рабочих дней до срока: 4
Объяснение: крайний срок 25 сентября, платёжные дни вторник и четверг, ближайший подходящий день 22 сентября. Штрафных условий в договоре нет, скидка за раннюю оплату не предусмотрена.А так — на счёте, где сработало правило про штраф:
ЗОНА: красная
Рабочих дней до срока: 9
Объяснение: по договору 41/П срок оплаты 30 сентября, но за просрочку начисляется 0,1% в день. Штрафное условие переводит счёт в красную зону независимо от запаса дней.Разница между этими двумя ответами и есть главный аргумент за жёсткие правила классификации: счёт с девятью днями запаса может быть опаснее счёта с четырьмя. Формула «чем меньше дней, тем краснее» этого не увидит, а модель, которой передан признак штрафа, увидит.
6. Подготовка сводки по участку на утро
Собери утреннюю сводку по кредиторке.
Входные данные: список счетов со статусами {зелёные, жёлтые, красные},
сумма к оплате по каждой зоне, поставщики с приближающимся сроком.
Структура сводки:
1) Строка итога: сколько счетов и на какую сумму требуют решения сегодня.
2) КРАСНАЯ ЗОНА: по каждому счёту поставщик, сумма, крайний срок, что произойдёт при просрочке.
3) ЖЁЛТАЯ ЗОНА: сжатый список, по одной строке на счёт.
4) Зелёная зона: только итог, без перечисления.
5) Один вопрос, на который мне нужно ответить сегодня.
Пиши короткими строками, без вводных фраз и без итоговых благодарностей.7. Разбор спорного счёта: чего не хватает для оплаты
Ты разбираешь спорный счёт поставщика.
Счёт: {данные}
История по контрагенту: {платежи, закрывающие документы, переписка}
Нужно ответить на три вопроса:
1) Каких документов не хватает, чтобы оплатить этот счёт.
2) Все ли предыдущие поставки закрыты документами, или есть висящий аванс.
3) Какие есть варианты действий и чем каждый заканчивается для отношений с поставщиком.
Пиши варианты без рекомендации: решение принимает финансист.8. Письмо поставщику про отсрочку платежа
Составь письмо поставщику о переносе срока оплаты.
Факты: сумма {сумма}, крайний срок по договору {дата}, предлагаемый срок {дата},
причина {кратко}, наша история с этим поставщиком {объём закупок, были ли просрочки}.
Требования к письму:
- 5-7 предложений, деловой тон без извинений в каждом абзаце;
- конкретная новая дата, а не "в ближайшее время";
- одна фраза про то, что мы ценим отношения, без лести;
- в конце конкретный следующий шаг и срок ответа.
Не обещай ничего, чего нет в переданных фактах.9. Реконструкция условий договора из текста
Извлеки условия оплаты из текста договора.
Текст договора: {текст}
Верни СТРОГО JSON:
{
"срок_отсрочки_дней": 0,
"база_отсчёта": "",
"тип_дней": "календарные | рабочие",
"скидка_за_раннюю_оплату": "",
"штраф_за_просрочку": "",
"лимит_отгрузки_без_предоплаты": "",
"условие_приостановки_отгрузок": ""
}
Правила:
- Если условие в договоре не указано, оставь пустую строку. Это важнее, чем заполнить поле.
- Обязательно укажи номер пункта договора, из которого взято каждое условие.
- Если условия противоречат друг другу в разных пунктах, перечисли оба и укажи номера.10. Акт сверки: поиск расхождений
Сравни наш реестр платежей с актом сверки поставщика.
Наш реестр: {дата, номер документа, сумма}
Акт поставщика: {дата, номер документа, сумма}
Найди:
1) Позиции, которые есть у нас и нет у поставщика.
2) Позиции, которые есть у поставщика и нет у нас.
3) Позиции, где суммы расходятся, с разницей по каждой.
4) Итоговое сальдо по нашему реестру и по акту.
Верни таблицу расхождений и одну строку вывода: подтверждаем акт или нет.
Не сглаживай расхождения округлением: показывай разницу в рублях и копейках.Что приходит на выходе, когда расхождения есть:
| Документ | Дата | У нас | У поставщика | Разница |
|---|---|---|---|---|
| ТОРГ-12 №1187 | 12.08.2026 | 84 300,00 | нет | +84 300,00 |
| Акт №КС-44 | 30.07.2026 | 61 200,00 | 61 200,00 | 0,00 |
| Счёт №904 | 05.08.2026 | 22 500,00 | 22 050,00 | +450,00 |
Сальдо: у нас 4 218 640,00, у поставщика 4 133 890,00.
ВЫВОД: акт не подтверждаем, расхождение 84 750,00 руб.А так выглядит ответ, когда сверять нечего и модель не стала достраивать картину:
ВХОДНЫЕ ДАННЫЕ НЕПОЛНЫЕ: в акте поставщика отсутствуют позиции за июль, в нашем реестре за тот же период 14 строк. Сверка по июлю невозможна.
ВЫВОД: подтвердить можно только август, по июлю нужны данные от поставщика.Второй ответ короче и неприятнее, но именно он экономит вам вечер: сверка по неполным данным всегда даёт ложное расхождение, и найти его потом дороже, чем запросить выгрузку сразу.
11. Разбор реестра кредиторки: где узкое место
Проанализируй реестр кредиторки за месяц.
Реестр: {поставщик, сумма, дата счёта, крайний срок, дата фактической оплаты, зона}
Найди:
1) Топ-5 поставщиков по сумме долга и по сумме просрочки отдельно.
2) Счета, где отклонение между крайним сроком и фактической оплатой больше трёх дней.
3) Поставщиков, у которых систематически теряется скидка за раннюю оплату.
4) Изменение средней просрочки по месяцам, если данных хватает.
По каждому пункту дай цифру и вывод одной строкой. Без общих советов
вроде "улучшить процесс контроля": только то, что видно в данных.Восемь ошибок, которые ломают проект внедрения
Ошибки на таких проектах повторяются, и почти все они управленческие. Технических среди них меньше, потому что технику как раз проверяют на тестовом прогоне, а договорённости с людьми никто не проверяет.
Первая: агенту отдают право нажать «оплатить». Формально это выглядит как полная автоматизация, а на практике первая же ошибка в реквизитах превращается в реальный перевод не туда. Агент готовит проект платежа, подписывает человек.
Вторая: начинают со сложных случаев. Самый интересный счёт это тот, где цена менялась трижды и поставщик спорит. Именно его нельзя ставить в первую версию агента, потому что вы будете отлаживать не логику, а исключения. Первая версия должна работать на типовых счетах, где решение однозначно.
Третья: не описывают правило для дублей. Если правило не сформулировано словами, агент будет считать дублем всё, что похоже, и вы получите вал ложных срабатываний.
Четвёртая: не замеряют базовую линию. Через месяц никто не помнит, сколько часов уходило до внедрения, и доказать эффект нечем.
Пятая: пытаются решить всё одной моделью. Длинный договор и массовая обработка счетов предъявляют разные требования, и связка двух моделей часто дешевле и точнее.
Шестая: не следят за качеством входных сканов. Плохо распознанная сумма опаснее отсутствующей, потому что выглядит правдоподобно.
Седьмая: забывают про исходящую сторону. Агент полезен не только на приёме счетов, но и на письмах поставщикам: уведомление о переносе срока, ответ на претензию, акт сверки. Здесь он экономит часы, которые обычно уходят на согласование формулировок.
Восьмая: масштабируют раньше, чем откалибровали. Агент, работающий на 20 счетах с ошибкой в правиле, на 200 счетах даст в десять раз больше ошибок и потеряет доверие команды навсегда.
| Ошибка | Как выглядит | Чем заканчивается | Как правильно |
|---|---|---|---|
| Право подписи у агента | Автоплатёж без человека | Перевод по неверным реквизитам | Агент готовит, человек подписывает |
| Старт со сложных случаев | Первые счета самые спорные | Отладка исключений вместо логики | Начинать с типовых счетов |
| Нет правила для дублей | Агент красит всё похожее | Вал ложных срабатываний | Правило записано словами до запуска |
| Нет базовой линии | Часы до внедрения не посчитаны | Эффект нечем доказать | Замер закрытого месяца до старта |
| Масштаб раньше калибровки | Сразу весь поток счетов | Потеря доверия команды | 20 счетов, калибровка, потом всё остальное |
Как считать экономику проекта по трём величинам
Эффект от такого проекта считается в трёх величинах, и только одна из них про деньги напрямую.
Первая: освобождённые часы. Самая надёжная цифра, потому что считается из замеров до и после. Тридцать часов в месяц это примерно две десятых ставки бухгалтера, и это можно направить на то, что раньше не делалось никогда: сверку с каждым поставщиком ежеквартально, работу с отсрочками, анализ структуры закупок.
Вторая: предотвращённые потери. Штрафы за просрочку, потерянные скидки за раннюю оплату, дубли. Эти цифры считаются по факту: сколько случаев поймали за период.
Третья: управленческая скорость. Сколько дней проходит от получения счёта до решения по нему. Эта цифра не переводится в рубли напрямую, но именно она снижает нервозность в отношениях с поставщиками и внутри финотдела.
| Статья | Типичная величина | Как проверить |
|---|---|---|
| Освобождённые часы | 15-30 часов в месяц | Замер закрытого месяца до и после |
| Предотвращённые штрафы | 0-200 тыс. руб. в квартал | Реестр пойманных просрочек |
| Возвращённые скидки | 100-400 тыс. руб. в квартал | Сверка окон скидок до и после |
| Найденные дубли | Разово, от 0 до нескольких млн | История возвратов и корректировок |
| Стоимость содержания | Десятки долларов в месяц | Токены модели и хостинг сценария |
Отдельно про то, как считать освобождённые часы, потому что тут чаще всего завышают. Если участок занимал 38 часов, а после внедрения 8, экономия не равна 30 часам в деньгах. Часть освободившегося времени уйдёт на работу с агентом: разбор красной зоны, пополнение реестра, разбор ложных срабатываний. Реальная экономия обычно составляет две трети от разницы, и это честная цифра, которую можно защищать.
Куда направить освобождённые часы, решайте заранее, до внедрения. Если этого не сделать, время утечёт в текучку и через два месяца никто не вспомнит, что участок стал быстрее. Варианты, которые я видела у учеников: ежеквартальная сверка с каждым ключевым поставщиком, работа с отсрочками и переговорными позициями, разбор структуры закупок, наконец, автоматизация соседнего участка.
Как обезличить данные перед отправкой в модель
Счета поставщиков содержат реквизиты, суммы и условия сделок. Персональных данных там обычно нет, но коммерческий риск есть: контрагент не согласовывал передачу условий сделки третьей стороне, а на условиях сделки строится ваша переговорная позиция.
Практическая схема, которую я применяю с учениками, такая. Для договоров, коммерческих предложений и всего, где есть цены и условия, используется локальная модель на своём сервере. Для типовых счетов и актов сверки допустима облачная модель, но с двумя условиями: контрагент в выгрузке заменён на код, а суммы оставлены в реальном размере, иначе теряется смысл сверки.
Замена контрагента на код делается автоматически: таблица соответствия хранится у вас, в модель уходит только код. Суммы, номера счетов и даты можно оставить, они не идентифицируют контрагента сами по себе.
Есть ещё два правила, которые я советую закрепить в регламенте. Первое: в облачную модель не уходит назначение платежа целиком, если в нём есть названия объектов, адресов или фамилий. Формулировка «услуги по договору, код К-17» работает для сверки не хуже полной расшифровки. Второе: перед первым запуском стоит показать регламент юристу и получить письменный ответ, какие категории данных допустимо обрабатывать во внешнем сервисе, а какие нет. Это занимает час, но снимает весь спор внутри компании на годы вперёд.
Если поставщик прямо запрещает передачу условий сделки третьим лицам в договоре, будьте аккуратны и работайте по такому контрагенту только локально. На практике такое встречается редко, но если встречается, лучше узнать об этом на этапе чтения договора, а не из письма от юриста поставщика.
Как вести реестр договоров, чтобы он не устарел
Реестр договоров это единственный артефакт, который придётся поддерживать постоянно. Если он устареет, агент начнёт считать сроки по прошлогодним условиям и вы потеряете к нему доверие быстрее, чем к любому другому инструменту.
Три правила, которые делают реестр живым. Первое: реестр обновляет тот, кто подписывает договор, а не тот, кто им пользуется. Пока обновление висит на бухгалтерии, оно всегда будет запаздывать. Второе: в реестре есть дата последнего изменения и ссылка на файл договора. Третье: раз в квартал реестр сверяется с фактическими договорами по десяти поставщикам с наибольшим оборотом.
Про структуру реестра дам конкретный совет из практики. Не делайте его красивым, делайте его полным. Достаточно таблицы с восемью колонками: контрагент, ИНН, номер договора, дата договора, срок отсрочки, база отсчёта, скидка за раннюю оплату, штраф за просрочку. Всё остальное можно добавить позже, а вот эти восемь полей должны быть заполнены по каждому ключевому поставщику, иначе агент не сможет посчитать срок.
И ещё одно наблюдение, которое стоит денег. Заполнение реестра почти всегда вскрывает расхождения, о которых в компании не знали. По одному поставщику в бухгалтерии считают отсрочку 30 дней, в закупке уверены, что 45, а в договоре стоит 21. Такие расхождения всплывают в первом же проходе по документам, и их устранение само по себе окупает время, потраченное на реестр.
Как поддерживать рабочий процесс на участке
Агент ускоряет процедуры, но не отменяет их. Поэтому до запуска стоит договориться о четырёх вещах и записать их.
Кто отвечает за реестр договоров и в какой момент обновляет его. Что считается критическим сроком и что происходит при попадании в красную зону: звонок, письмо, частичная оплата. Кто и когда пересматривает лимиты отгрузки без предоплаты. Как часто сверяются данные агента с фактическими платежами: раз в неделю по десяти счетам достаточно, чтобы вовремя заметить сбой.
Самый недооценённый пункт здесь второй. Что именно делает человек, когда счёт попал в красную зону. Пока ответ звучит как «разбираемся по ситуации», участок будет жить в режиме пожара независимо от того, насколько хорош агент. Я прошу описывать три сценария: счёт подошёл к сроку и деньги есть, счёт подошёл к сроку и денег нет, счёт подошёл к сроку и выяснилось расхождение с поставщиком. На каждый сценарий нужен один понятный шаг, а не список вариантов.
Отдельно про переходный период. Первые две-три недели после запуска агента участок работает в двойном режиме: агент считает, человек проверяет всё подряд. Это нормально и это утомительно, потому что нагрузка временно растёт. Чтобы не бросить проект на этом этапе, назначьте дату, когда двойной режим заканчивается: обычно это конец второго месяца закрытия, если расхождений по красной зоне не было ни разу.
Год назад и сегодня: что изменилось в работе с кредиторкой
Ещё в 2024 году разговор про автоматизацию участка кредиторки сводился к макросам в таблицах и роботам, которые переносят строку из одной учётной системы в другую. Модель приходила в проект только для распознавания скана.
Сейчас три вещи изменились одновременно. Модели научились держать в контексте договор целиком и не терять условие на семнадцатой странице. Появились конструкторы, где агент собирается без программиста. И появился канал доставки результата, который финансист реально читает каждое утро, а не таблица, которую надо помнить открыть.
Практический вывод простой: участок, который два года назад автоматизировался максимум до половины, сейчас автоматизируется до конца. Оговорюсь честно: цифры и сроки в кейсах выше это опыт школы на небольших и средних компаниях. На потоке в тысячи счетов в месяц архитектура та же, но потребуется батчирование и, скорее всего, локальная модель.
Чего я жду в ближайший год, чтобы вы могли готовиться заранее. Первое: агент начнёт сам писать поставщикам типовые письма, и это станет нормой, а не экспериментом. Второе: реестр договоров перестанет быть отдельной таблицей, которую кто-то ведёт руками, и будет собираться автоматически при чтении каждого подписанного договора. Третье: счета будут приходить в структурированном виде всё чаще, потому что крупные поставщики уже переводят документооборот на ЭДО, и это снимет значительную часть проблем с распознаванием сканов.
Что из этого не изменится, так это роль человека. Пока решение о выплате денег принимает человек, участок кредиторки останется местом, где нужна голова. Меняется только то, на что эта голова тратится: раньше на поиск документа и арифметику, теперь на переговоры с поставщиком и выбор приоритетов в платежном графике.
Чек-лист запуска агента на участке кредиторки
Пройдите по списку перед стартом. Ответ «не знаю» означает, что этот шаг не сделан, и агент будет ошибаться именно здесь.
- Посчитал ли я часы на участке за закрытый месяц? Без замеров вы не докажете эффект ни себе, ни руководителю.
- Описано ли правило решений словами? Что с счётом в пределах лимита, что при превышении, что без договора, что с дублем.
- Собран ли реестр договоров с условиями отсрочки и скидок? Минимум по двадцати поставщикам, дающим основную часть долга.
- Есть ли одна точка сбора документов? Один канал, одно место, понятная структура имён файлов.
- Закреплено ли правило для дублей? До запуска, а не после первого вала ложных срабатываний.
- Разделены ли расчёт срока и объяснение? Срок считается арифметикой, модель объясняет и рекомендует.
- Осталось ли право подписи у человека? Агент готовит проект платежа, подписывает финансист.
- Настроены ли уведомления о сбоях? Если сценарий упал или не нашёл договор, вы должны узнать в то же утро.
- Проверено ли на закрытом месяце? Совпадение статусов и сумм с тем, что уже проведено руками.
- Назначен ли владелец реестра договоров? Тот, кто подписывает договор, а не тот, кто им пользуется.
FAQ: частые вопросы про кредиторку и AI-агентов
Что такое кредиторская задолженность и почему участок считают аварийным? Кредиторская задолженность это сумма, которую компания должна поставщикам и подрядчикам за поставленные товары, работы и услуги. Участок называют аварийным из-за плотности ошибок: документы приходят по десятку каналов, сроки у каждого договора свои, а ошибка стоит денег сразу. Пропустили счёт на 800 тысяч с отсрочкой 14 дней, получили штраф или приостановку отгрузок.
AI-агент это отдельная программа или надстройка над привычными сервисами? Собирается из того, что уже есть: сценарий в конструкторе плюс модель для чтения документов. Почта, папка на диске, выгрузка из учётной системы дают входные данные, таблицы и Telegram принимают результат. Отдельных лицензий на «агента» не существует, платить нужно за токены модели и, при желании, за хостинг.
Хватит ли обычного чата, чтобы разгрузить участок? Нет. Чат решает задачу, пока вы вручную перетаскиваете файлы и переносите ответ обратно. Агент добавляет к модели инструменты: сам забирает документ, читает договор, ищет дубли, пишет строку в реестр и отправляет сводку. Разница в том, кто запускает работу: вы или расписание. Подробный разбор различий есть в статье про AI-агентов для финотдела.
Безопасно ли загружать счета поставщиков в облачную модель? Реквизиты, суммы и номера договоров не относятся к персональным данным, прямого запрета на них нет. Риск коммерческий: контрагент не согласовывал передачу условий сделки третьей стороне. Рабочая схема: локальная модель для договоров и КП с ценами, облачная для типовых счетов и акта сверки по обезличенным контрагентам.
Какие модели подходят для участка кредиторки в сентябре 2026 года? По состоянию на сентябрь 2026 года: ChatGPT на GPT-5.5, Claude Sonnet 4.6, Gemini 2.5, DeepSeek V3.2. Для длинных договоров и актов сверки удобнее Claude с большим контекстом, для расчётов и табличных сверок Gemini, для массовой обработки и сводок ChatGPT. DeepSeek работает без ограничений по доступу, но в России только с обезличенными данными.
Что делать, если единой учётной системы нет, а документы приходят в почту и мессенджеры? Начинайте не с агента, а с точки сбора. Правило: у каждого канала поступления есть ровно одно место, куда попадает документ. Пока счёт может лежать в двух местах, агент будет считать дубли, а вы будете разбирать его ошибки. Наведение порядка в точке сбора занимает около недели и экономит больше, чем сам агент.
Что делать, если поставщик требует оплату, а денег нет? Агент не увеличивает деньги, он даёт время на решение. Реестр показывает, у кого наступает критический срок на этой неделе, где есть договорная возможность отсрочки, а где цена вопроса это штраф. Дальше вы выбираете: переговоры, частичная оплата, пересмотр графика. Картина на пять дней вперёд меняет разговор с поставщиком сильнее любых формулировок.
Когда агент ошибётся, кто отвечает перед налоговой и контрагентом? Ответственность остаётся на компании и на человеке, который подписал платёж. Поэтому в схеме обязательны две вещи: агент не инициирует переводы самостоятельно, а каждое решение в красной зоне проверяет финансист. Это условие, при котором проект вообще имеет смысл запускать.
Сколько стоит содержание агента для участка в 150 счетов? Три строки. Токены модели: при 150 счетах с вложениями обычно несколько долларов в месяц, точную цену берите на официальной странице тарифов вендора, потому что она меняется. Хостинг сценария: от 5 долларов в месяц или бесплатно на своём сервере. Ваше время: первые три недели около часа в день на калибровку.
Нужен ли программист, чтобы всё это собрать? Для типового сценария нет. Конструкторы вроде n8n работают на визуальных блоках, код нужен в одном-двух местах: расчёт срока и нормализация дат. Разобраться в базовой логике «если-то» достаточно. Если сценарий сложный, разумнее потратить неделю на обучение, чем платить подрядчику за каждую правку потом.
Что делать дальше
Участок счетов поставщиков ломается не на платеже, а на входе: где документ лежит, кто его увидел, какое правило к нему применили. Агент закрывает именно этот разрыв, и поэтому эффект виден не в отчёте, а в первый же спокойный понедельник, когда сводка приходит до того, как вы успели открыть почту.
Мы разобрали полный цикл: сбор документов, извлечение полей, сверку с договором, классификацию по сроку и действие. Девять шагов внедрения, одиннадцать промптов, три кейса с цифрами и сравнительная таблица моделей. Дальше нужна практика на своём участке, потому что реестр договоров и правило решений за вас не соберёт никто.
На курсе «AI-навыки финансиста» онлайн-школы «Финансовый директор | Мастер CFO» 10 модулей: от базовой работы с моделями до настройки агентов под конкретные участки отдела. 800+ выпускников, диплом установленного образца с лицензией, налоговый вычет 13%. Разбираем в том числе кредиторку, платёжный календарь и закрытие месяца на реальных кейсах учеников.
Записаться на курс «AI-навыки финансиста»
Если пока не готовы к курсу, начните с бесплатного разбора схемы: один лист, правило решений и три промпта для первого прогона.
Забрать бесплатный разбор «Участок кредиторки на AI-агенте»
Наши каналы для финансистов
@findir_pro, 45 000 подписчиков. Ежедневные разборы: промпты, кейсы, новости AI для финансиста. Главный канал сообщества.
«АИ с Софьей и Натали», 13 000 подписчиков. Совместный канал с Софьей Бурцевой, основателем школы. Разборы трендов и практика применения моделей в финансах.
MAX «Финансовый директор», 5 000+ участников. Сообщество с разборами кейсов, шаблонами и доступом к экспертным эфирам.
Об авторе
Натали Васильева. Эксперт по нейросетям и продюсер онлайн-школы «Финансовый директор | Мастер CFO». Работаю с нейросетями в финансах с февраля 2023 года. Через курс «AI-навыки финансиста» прошли 800+ финансистов, главбухов и финдиров. Веду Telegram-канал @findir_pro (45 000 подписчиков) и MAX-канал «Финансовый директор» (5 000+). Разбираю, как перевести участки финотдела на AI-агентов без потери контроля над деньгами.
Полезные материалы по теме: AI-агент для скоринга дебиторки на n8n, сверка закрывающих документов с контрагентами, AI для первичных документов: счёта и накладные, ChatGPT для казначея: кэш-флоу и платёжный календарь, обезличивание данных перед отправкой в нейросеть. Для базовой работы с моделями нужен только аккаунт: chatgpt.com.