Ваша 1С видит долг, но не может его собрать: где проходит граница между отчётом и агентом

Отчёт «кто нам должен» есть в каждой учётной системе. В 1С, в МойСкладе, в Битриксе, в любой CRM. Он открывается за три клика, показывает список должников с суммами и сортируется по просрочке.

По нему почти никто не работает.

Это не лень и не разгильдяйство. Это следствие того, что отчёт отвечает не на тот вопрос. Он говорит «Иванов должен 340 тысяч, 47 дней». А человеку, чтобы сделать хоть что-то, нужно знать другое: правда ли просрочка, кому из семидесяти строк писать сегодня, и что этот клиент отвечал в прошлый раз.

Между этими двумя вопросами лежит примерно час работы на каждого должника. Поэтому по отчёту и не работают: он не экономит время, он его назначает.

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

Сначала — что ИИ здесь не нужен

Начну с того, за что не надо платить, потому что вокруг дебиторки много продают лишнего.

Сложить долги и разложить по срокам — это арифметика. Любая учётка умеет: сумма отгрузок минус сумма оплат, разбивка по корзинам 0–30, 30–60, 60–90. Оборачиваемость дебиторки считается формулой в две строки. Если вам предлагают нейросеть, которая «анализирует дебиторскую задолженность» и на выходе даёт вам эти же корзины, — вам предлагают отчёт по цене агента.

Напомнить по календарю — это планировщик. Задача в CRM на дату, письмо по расписанию, уведомление за три дня до срока. Это делается настройкой, а не моделью.

Всё, что дальше, — начинается там, где эти два инструмента заканчиваются.

Три причины, по которым цифра в отчёте неверна

Первая: 47 дней просрочки — чаще всего выдумка.

Отчёт считает просрочку от даты отгрузки плюс какой-то срок, который стоит в настройках. А настоящий срок отсрочки лежит в договоре. У каждого клиента он свой: тридцать дней, шестьдесят, «десять банковских дней с даты подписания акта», а у одного — «по факту реализации», что означает, что срок вообще не начал течь.

Договор при этом — не поле в базе. Это PDF. В ЭДО он лежит как неформализованный документ, у которого даже имя файла хранится не в структуре, а в метаданных строкой: FileName: Договор.pdf. Машина видит вложение, а не условие. До того как модель научилась читать документ и вытаскивать оттуда срок и порядок расчётов, эти сорок семь дней просто никто не проверял.

Вторая: часть суммы — не долг, а расхождение.

Из 340 тысяч 120 могут быть спорными: мы отгрузили, клиент не принял или принял частично, и это видно только в акте сверки. Акт сверки — отдельный тип документа в ЭДО (АктСверИсх и АктСверВх у СБИСа, свой у Диадока), с периодом, который надо запрашивать явно.

А сама сверка — это сопоставление двух списков операций, где названия не совпадают: у нас «Отгрузка №112 от 14.05», у клиента «УПД 000112». Все, кто пробовал автоматизировать это правилами, знают, чем кончается: правило работает на одном контрагенте и ломается на следующем. Это ровно та задача, на которой правила бессильны, а модель — нет.

Третья: обещание клиента нигде не хранится.

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

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

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

Всё, что выше, — про то, кому писать раньше. Есть отдельная строка, где вопрос стоит иначе: писать ли вообще или уже идти в суд.

Клиент, у которого началась процедура банкротства, у которого висят исполнительные производства или который месяц назад проиграл три арбитражных дела подряд, — это не «должник с просрочкой 47 дней». Это должник, у которого выстроилась очередь, и место в ней определяется датой, а не вежливостью вашего письма.

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

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

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

Отчёт этого не различает вообще: для него долг на 47 дней и долг на 1 040 дней — две строки, отсортированные по убыванию. Разница между ними — в том, что второй скоро перестанет существовать.

Что делает агент

Разница между отчётом и агентом здесь не в интеллекте. Она в том, из скольких мест собирается одна строка.

Он берёт долг из первички, а не из отчёта. Это менее очевидно, чем кажется. В МойСкладе, например, есть готовый отчёт «Контрагенты» — и брать долги из него нельзя: там показатели продаж, а не взаиморасчёты, и он ещё и требует отдельного права в роли сотрудника. Долг считается из неоплаченных отгрузок: по каждому клиенту сумма разниц между суммой документа и оплаченной частью. Со своими ловушками — суммы приходят в копейках и переводить в рубли надо до сложения, а не после; у аккаунтов, которые не делают отгрузок, надо идти в счета и заказы; непривязанный платёж, который бухгалтер провёл, но не сопоставил с отгрузкой, завышает долг и выглядит как просрочка.

Ни одна из этих ловушек не про ИИ. Но каждая — про то, почему «просто выгрузить долги» не работает, и почему цифра в первом же письме клиенту оказывается неправильной.

Он читает договор и вынимает оттуда срок. Не «ищет по ключевым словам», а отвечает на вопрос: с какого события считается отсрочка, сколько дней, есть ли неустойка и с какого дня. Дальше просрочка пересчитывается по-настоящему — и список сокращается, иногда вдвое.

Он сводит акт сверки и отделяет спорное от бесспорного. Потому что писать клиенту про 340 тысяч, когда бесспорных из них 220, — это подарить ему повод не платить вообще ничего и месяц выяснять.

Он подтягивает переписку и помнит, что было обещано. Клиент, который две недели назад написал «оплатим в пятницу», и клиент, который молчит с мая, — это два разных разговора, и разница между ними не в сумме.

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

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

Где агент обязан остановиться

Теперь неприятная часть, которую в анонсах обычно пропускают.

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

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

Отдельно про то, что кажется соблазнительным и работает плохо: обзвон должников автоматом. Технически он делается — телефония подключается, синтез речи есть. На практике первый же нестандартный ответ («у нас акт не подписан, разберитесь и перезвоните») превращает звонок в раздражение, а раздражение конвертируется в неоплату надёжнее любого напоминания. Дебиторка — это отношения с клиентом, у которого вы хотите взять деньги и при этом продолжить работать. Массовая рассылка одинаковых требований веером здесь ломает ровно то, что собиралась починить.

Как это выглядит в работе

Рутина, которую мы обычно ставим первой, звучит буднично: каждое утро в девять.

Агент забирает неоплаченные отгрузки, считает долг по клиентам, идёт в ЭДО за договорами тех, у кого просрочка формально наступила, пересчитывает сроки по-настоящему, отделяет спорные суммы по актам сверки, подтягивает последнюю переписку и складывает всё в один список. Список приходит в чат.

Дальше человек смотрит на пять строк вместо семидесяти и говорит: этим двоим пиши, этому позвоню сам, у этого спор — готовь акт.

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

Что из этого следует

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

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

Третье, и оно шире дебиторки. Граница между «отчёт» и «агент» проходит не по сложности вычислений. Она проходит по тому, лежат ли исходные данные в таблице. Всё, что в таблице, автоматизировали двадцать лет назад, и языковая модель там не нужна. Всё, что в договоре, в письме, в скане и в чате, до недавнего времени обрабатывал только человек — и именно там сейчас лежит вся невыбранная выгода. Дебиторка — просто самый наглядный случай, потому что у неё есть цена в рублях и срок.