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

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

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

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

1. счета и ожидаемые оплаты лежат в таблице `invoices`;
2. фактические поступления лежат в таблице `payments`;
3. n8n запускается утром по расписанию;
4. workflow сопоставляет оплаты со счетами по ИНН, сумме, номеру счета и назначению платежа;
5. агент считает статус: `paid`, `partial`, `overdue`, `due_soon`, `unmatched`;
6. спорные совпадения попадают в `needs_review`;
7. LLM готовит короткое объяснение и черновик задачи менеджеру;
8. бухгалтер или руководитель ставит `approved`;
9. approved-задачи уходят в CRM или Telegram;
10. все решения записываются в журнал `ar_log`.

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

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

• n8n Cloud или self-hosted n8n.
• Google Sheets для первого прототипа.
• Реестр выставленных счетов.
• Реестр оплат из банка, YooKassa, CRM, 1С или CSV-выгрузки.
• CRM или Telegram для задач менеджерам.
• Ответственный бухгалтер или финменеджер для approval.
• 1-2 часа на первый запуск.

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

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

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

1. один отдел продаж;
2. одну валюту, например RUB;
3. счета за последние 30 дней;
4. оплаты за последние 30 дней;
5. только юридических лиц и ИП;
6. без частичных возвратов и корректировок.

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

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

Создайте Google Sheet:

Payments and AR AI agent

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

invoices
payments
ar_status
match_candidates
action_queue
ar_log
settings

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

Шаг 3. Создайте реестр счетов

В листе `invoices` сделайте колонки:

invoice_id
invoice_number
invoice_date
due_date
customer_name
customer_inn
customer_kpp
deal_id
manager
amount
currency
vat_amount
payment_purpose_expected
status
created_at

Пример строки:

INV-1001
1001
2026-05-10
2026-05-20
ООО Север
7700000000
770001001
D-450
Иван
120000
RUB
20000
Оплата по счету №1001 от 10.05.2026
issued
2026-05-10

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

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

В листе `payments` сделайте колонки:

payment_id
payment_date
payer_name
payer_inn
amount
currency
payment_purpose
source
external_payment_id
matched_invoice_id
match_status
created_at

Пример:

PAY-9001
2026-05-21
ООО Север
7700000000
120000
RUB
Оплата по счету 1001 от 10.05.2026
bank_csv
bank-123

new
2026-05-21

Проверка: платежи можно сопоставлять хотя бы по ИНН, сумме и назначению.

Шаг 5. Создайте лист настроек

В листе `settings` добавьте:

key
value
comment

Заполните:

due_soon_days | 3 | за сколько дней предупреждать о сроке оплаты
partial_payment_tolerance | 0.01 | допустимое расхождение округления
exact_match_amount_tolerance | 1 | допустимое расхождение суммы в рублях
auto_match_min_score | 0.90 | порог автоматического совпадения
review_match_min_score | 0.65 | порог отправки на ручную сверку
default_currency | RUB | валюта первой версии

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

Шаг 6. Создайте таблицу итоговых статусов

В листе `ar_status` сделайте колонки:

status_id
invoice_id
invoice_number
customer_name
customer_inn
manager
amount
paid_amount
remaining_amount
due_date
days_overdue
status
matched_payment_ids
risk_level
ai_summary
next_action
created_at
updated_at

Статусы:

• `paid` - оплачено полностью;
• `partial` - оплачено частично;
• `due_soon` - скоро срок оплаты;
• `overdue` - просрочка;
• `unmatched` - есть платеж, но счет не найден;
• `needs_review` - сопоставление неуверенное.

Проверка: финансовый статус счета хранится отдельно от сырых данных.

Шаг 7. Создайте журнал действий

В листе `ar_log` сделайте колонки:

log_id
run_id
invoice_id
payment_id
step
event
details
created_at

Проверка: любое автоматическое решение можно потом объяснить.

Шаг 8. Создайте очередь действий

В листе `action_queue` сделайте колонки:

action_id
invoice_id
customer_name
manager
action_type
message_draft
reason
risk_level
review_status
approved_by
crm_task_id
sent_at
error
created_at

Статусы `review_status`:

• `draft`;
• `approved`;
• `rejected`;
• `done`;
• `error`.

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

Шаг 9. Подготовьте тестовые данные

Добавьте 5 счетов:

1. счет оплачен полностью;
2. счет оплачен частично;
3. счет просрочен на 5 дней;
4. счет со сроком оплаты через 2 дня;
5. счет без оплаты.

Добавьте 4 платежа:

1. точное совпадение по ИНН и сумме;
2. частичная оплата;
3. платеж с ошибкой в назначении;
4. платеж без счета.

Проверка: тестовый набор покрывает не только идеальные платежи.

Шаг 10. Создайте workflow сверки

Назовите workflow:

Payments AR reconciliation

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

1. `Schedule Trigger`;
2. `Google Sheets` - чтение `settings`;
3. `Google Sheets` - чтение `invoices`;
4. `Google Sheets` - чтение `payments`;
5. `Code` - нормализация данных;
6. `Code` - matching invoices/payments;
7. `Code` - расчет AR статусов;
8. `LLM` - summary и next action;
9. `Google Sheets` - запись `ar_status`;
10. `Google Sheets` - запись `match_candidates`;
11. `Google Sheets` - запись `action_queue`;
12. `Google Sheets` - запись `ar_log`.

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

Шаг 11. Настройте расписание

В `Schedule Trigger` поставьте:

Mode: Every Day
Hour: 08
Minute: 15
Timezone: Europe/Moscow

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

Шаг 12. Нормализуйте ИНН, суммы и даты

В узле `Code` приведите данные к одному виду.

function cleanInn(value) {
  return String(value || '').replace(/\D/g, '');
}

function money(value) {
  return Math.round(Number(String(value || '0').replace(',', '.')) * 100) / 100;
}

function dateOnly(value) {
  return String(value || '').slice(0, 10);
}

return items.map(item => ({
  json: {
    ...item.json,
    customer_inn_norm: cleanInn(item.json.customer_inn || item.json.payer_inn),
    amount_norm: money(item.json.amount),
    date_norm: dateOnly(item.json.invoice_date || item.json.payment_date)
  }
}));

Проверка: `7700000000`, `7 700 000 000` и `7700000000.0` не превращаются в разные ИНН.

Шаг 13. Сделайте точное сопоставление

Первое правило matching:

invoice.customer_inn = payment.payer_inn
invoice.amount = payment.amount с учетом tolerance
invoice.currency = payment.currency
payment_purpose содержит invoice_number или invoice_id

Если все совпало:

match_score = 1.0
match_status = exact

Проверка: платеж `PAY-9001` автоматически сопоставляется со счетом `INV-1001`.

Шаг 14. Сделайте частичное сопоставление

Если ИНН совпадает, а сумма меньше счета:

match_status = partial_candidate
match_score = 0.75

Условие:

payment.amount < invoice.amount
payment.amount > 0
invoice.status != paid

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

Шаг 15. Сделайте fuzzy matching назначения платежа

Если номер счета написан с ошибкой, используйте простое правило:

payment_purpose содержит хотя бы 4 цифры из invoice_number
или payment_purpose содержит дату счета
или payment_purpose содержит название клиента

Для первой версии не надо делать сложный ML. Лучше отправить сомнительное совпадение в `needs_review`.

Проверка: платеж с ошибкой в назначении попадает в `match_candidates`, а не теряется.

Шаг 16. Запишите кандидатов на сверку

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

Колонки:

candidate_id
payment_id
invoice_id
match_score
match_status
reason
review_decision
review_comment
created_at

Если `match_score >= auto_match_min_score`, можно сопоставить автоматически.

Если `review_match_min_score <= match_score < auto_match_min_score`, пишите в `match_candidates`.

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

Шаг 17. Посчитайте paid_amount и remaining_amount

Для каждого счета:

paid_amount = сумма всех matched payments
remaining_amount = invoice.amount - paid_amount

Правила:

remaining_amount <= tolerance -> paid
paid_amount > 0 и remaining_amount > tolerance -> partial
paid_amount = 0 и сегодня > due_date -> overdue
paid_amount = 0 и до due_date <= due_soon_days -> due_soon
иначе issued

Проверка: полностью оплаченный счет получает `paid`, частичный - `partial`, просроченный - `overdue`.

Шаг 18. Посчитайте aging дебиторки

Для просрочек добавьте bucket:

0-7 дней
8-30 дней
31-60 дней
61+ дней

Правило риска:

0-7 -> low
8-30 -> medium
31-60 -> high
61+ -> critical

Проверка: старые долги подсвечиваются сильнее свежих.

Шаг 19. Добавьте LLM summary

LLM нужен не для арифметики, а для короткого объяснения и следующего действия.

System prompt:

Ты помощник финансового менеджера.
Пиши только по переданным данным.
Не придумывай оплаты, договоренности и причины просрочки.
Не угрожай клиенту и не формулируй претензии.
Верни только JSON.

User prompt:

Счет и статус:
{{ JSON.stringify($json.ar_item) }}

Верни JSON:
{
  "ai_summary": "1-2 предложения о статусе оплаты",
  "next_action": "что сделать менеджеру",
  "action_type": "none|check_payment|contact_manager|contact_client|review_match",
  "message_draft": "черновик внутренней задачи менеджеру, не клиенту",
  "risk_level": "low|medium|high|critical"
}

Проверка: модель возвращает JSON и не пишет клиенту напрямую.

Шаг 20. Запишите итог в ar_status

Для каждого счета обновите или создайте строку:

invoice_id
invoice_number
customer_name
customer_inn
manager
amount
paid_amount
remaining_amount
due_date
days_overdue
status
matched_payment_ids
risk_level
ai_summary
next_action
updated_at

Проверка: один счет имеет одну актуальную строку статуса.

Шаг 21. Создайте задачи для менеджеров

В `action_queue` создавайте задачи только для:

• `overdue`;
• `partial`;
• `needs_review`;
• `due_soon` с крупной суммой.

Не создавайте задачу, если:

• счет уже `paid`;
• по этому счету уже есть открытая action с `draft` или `approved`;
• remaining_amount меньше минимального порога, например 100 рублей.

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

Шаг 22. Проверьте задачи человеком

Финменеджер открывает `action_queue`.

Проверяет:

• верно ли найден счет;
• верно ли учтены оплаты;
• нет ли спорного назначения платежа;
• не было ли ручной договоренности с клиентом;
• корректен ли текст задачи.

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

review_status: approved
approved_by: имя

Или:

review_status: rejected
reason: почему отклонено

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

Шаг 23. Создайте workflow отправки approved-задач

Назовите workflow:

AR action send approved

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

1. `Schedule Trigger`;
2. `Google Sheets` - чтение `action_queue`;
3. `Filter` по `review_status = approved`;
4. `HTTP Request` к CRM или `Telegram`;
5. `Google Sheets` - обновление статуса.

Проверка: workflow берет только approved-строки.

Шаг 24. Отправьте задачу в CRM или Telegram

Для Telegram:

curl -X POST "https://api.telegram.org/botBOT_TOKEN/sendMessage" \
  -d "chat_id=CHAT_ID" \
  --data-urlencode "text=Просрочка по счету 1001: ООО Север, остаток 120000 RUB, 5 дней. Связаться с клиентом и уточнить дату оплаты."

Для CRM задача должна содержать:

invoice_number
customer_name
remaining_amount
days_overdue
manager
next_action
link_to_invoice

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

Шаг 25. Подключите реальные источники оплат

Когда прототип на таблицах работает, замените ручной лист `payments` на источник:

• банковская CSV-выгрузка;
• API банка;
• YooKassa payments API;
• Bitrix24 invoices/payments;
• 1С через OData или файловый обмен.

Правило подключения:

любой источник должен привести платеж к единой схеме payments

Минимальные поля:

payment_id
payment_date
payer_name
payer_inn
amount
currency
payment_purpose
source
external_payment_id

Проверка: после замены источника matching workflow не нужно переписывать полностью.

Шаг 26. Настройте контроль качества

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

Колонки:

case_id
invoice_id
payment_id
expected_status
expected_match_status
enabled

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

• точная оплата;
• частичная оплата;
• просрочка без оплаты;
• платеж без счета;
• два платежа на один счет;
• один платеж на несколько счетов;
• ошибка в назначении платежа;
• новый клиент без ИНН;
• расхождение суммы на 1 рубль;
• валюта не RUB.

Создайте workflow:

Payments AR regression test

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

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

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

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

• счета читаются из `invoices`;
• оплаты читаются из `payments`;
• точные оплаты сопоставляются автоматически;
• частичные оплаты получают статус `partial`;
• просрочки получают `overdue`;
• сомнительные совпадения попадают в `match_candidates`;
• задачи создаются только в `action_queue`;
• без `approved` задачи не отправляются;
• менеджер получает только внутреннюю задачу;
• все события записываются в `ar_log`;
• повторный запуск не создает дубли задач.

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

• списание дебиторской задолженности;
• отправку претензий клиенту без человека;
• изменение бухгалтерских проводок;
• закрытие сделки как оплаченной без подтверждения;
• массовую рассылку клиентам;
• начисление штрафов и пеней;
• удаление платежей или счетов;
• принятие решений по юридически спорным долгам.

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

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

Да, если есть готовый API или стабильная выгрузка. Но первую версию лучше собрать на Google Sheets: так проще проверить matching, пороги и логику задач.

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

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

Как обрабатывать частичные оплаты?

Суммируйте все matched payments по счету. Если остаток больше tolerance, ставьте `partial` и создавайте задачу только по оставшейся сумме.

Что делать с платежом без счета?

Отправлять в `match_candidates` или `needs_review`. Не нужно автоматически привязывать платеж к похожему клиенту, если сумма и назначение не дают уверенного совпадения.

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

Листы `invoices`, `payments`, `ar_status`, `match_candidates`, `action_queue`, `ar_log`, n8n workflow сверки, approval финменеджера и отдельный workflow для отправки approved-задач.