Контроль дебиторской задолженности: как следить за оплатой

За следующими разборами автоматизации можно следить через подписку под заголовком статьи.

Как устроен контроль дебиторской задолженности?

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

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

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

Отдельно смотрите всю ожидаемую оплату и ту часть, у которой прошел согласованный срок. В материале 1С для 1С:УНФ описан анализ общей и просроченной задолженности, а также сроков долга. Смешав эти суммы, легко поставить в одну очередь клиента с будущей датой оплаты и запись, которую уже пора разбирать.

Где вы сейчас

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

1. Соберите открытые документы

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

2. Свяжите поступления с документами

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

3. Рассчитайте остатки и назначьте действия

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

4. Проверьте и согласуйте напоминание

   Перед отправкой проверьте свежесть сверки, текущий остаток, адресата и последнее общение; получите согласование ответственного.

Что записать в реестр до первого напоминания?

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

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

Срок оплаты и обещание клиента храните раздельно. В справке Zoho Billing для напоминаний различаются срок счета и ожидаемая дата поступления. В своем реестре можно использовать тот же принцип: обещание «оплатим в пятницу» сохраняется рядом с исходным сроком. Само обещание остаток не уменьшает.

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

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

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

Выполняйте сверку в одном порядке:

1. Проверьте, что получены данные за нужный период и по нужной организации.
2. Найдите платеж и документ, к которому он относится. Уточните назначение, если клиент объединил несколько счетов.
3. Проверьте, не был ли этот платеж учтен раньше и не относится ли он к другой записи.
4. Зафиксируйте подтвержденную сумму и пересчитайте остаток по принятым правилам.
5. Сохраните время сверки, ее результат и следующее действие по незакрытым вопросам.

В документации Microsoft Dynamics 365 отдельно показаны полученные платежи, еще не сопоставленные со счетами. Такая ситуация не требует немедленно писать клиенту о неоплате. Сотруднику сначала нужно разобраться, какой документ закрывает перевод.

При автоматическом обмене проверьте, какие события вообще передаются между программами. Создание счета, изменение его суммы и подтверждение поступления могут обновляться в разное время. Подробнее о выборе данных для такого обмена - в разборе интеграции ИИ с 1С. Название интеграции само по себе не говорит, что в CRM уже попадают все нужные платежи.

Что делать с частичной оплатой и спорной суммой?

У счета на 100 условных единиц после подтвержденного поступления 40 остается 60. Метка «оплачен» скроет остаток. Метка «не оплачен» без расшифровки не покажет уже поступившую часть. В рабочем списке полезнее видеть обе суммы вместе с датой сверки.

В документации Stripe для частичных оплат предусмотрено отображение оставшейся суммы.

Если клиент оспаривает сумму документа, обычное напоминание потребует пересмотра. Укажите, что именно оспаривается, кто проверяет вопрос и когда ожидается ответ. В Microsoft Dynamics 365 спорные счета выделены в отдельное представление; такой же принцип можно применить в простой таблице.

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

Как выглядит проверка на учебных данных?

Дата проверки - 16 сентября 2026 года. В этом примере срок считается прошедшим, если он раньше даты проверки, а подтвержденный остаток больше нуля. Платеж уменьшает остаток только после привязки к документу. Корректировок, возвратов, переплат и разных валют в этих данных нет.

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

По документам сумма составляет 400 условных единиц. К ним уже привязано 100: это 40 по документу А и 60 по документу В. Непогашенный остаток по строкам равен 300. Внутри него 80 относятся к будущему сроку, а 220 - к прошедшим срокам А, Г и Д. Эти 220 нельзя без проверки превращать в общую сумму напоминаний: по Г есть спор, по Д ожидается сверка перевода.

Теперь изменим ровно один факт. Сотрудник подтвердил, что отдельный перевод на 70 относится к документу Д, и сохранил привязку. Остаток Д стал нулевым. Всего к документам теперь отнесено 170, открытый остаток уменьшился до 230, а часть с прошедшим сроком - до 150. Новых денег на этом шаге не поступило: изменилось распределение уже полученного платежа.

Расчет можно повторить обычным калькулятором:

До привязки: 400 - 100 = 300
Остаток с прошедшим сроком: 60 + 90 + 70 = 220

После привязки: 400 - 170 = 230
Остаток с прошедшим сроком: 60 + 90 = 150

Проверим другой случай: тот же перевод повторно появился в выгрузке. Если его идентификатор уже учтен, второй раз вычитать 70 нельзя. Остаток должен остаться 230. Изменение суммы при повторной загрузке тех же данных покажет ошибку обработки, которую нужно исправить до работы с реальными счетами.

Кто отвечает за следующий шаг?

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

Формулируйте задачу так, чтобы ее выполнение можно было проверить. Вместо «разобраться с оплатой» подойдет «уточнить назначение перевода и сохранить связь с документом Д». Следующий сотрудник увидит, что нужно получить на выходе. Если ответа нет, он сможет продолжить с последнего подтвержденного действия.

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

Когда отправлять напоминание об оплате?

В документации Odoo 18 прямо советуют сверять банковские операции до начала напоминаний, чтобы не писать по уже оплаченным счетам. Там же описаны ручной и автоматический режимы, ответственный и следующая дата действия. Для своей системы порядок и доступность этих функций нужно проверять отдельно.

Перед отправкой сотрудник открывает документ, смотрит подтвержденный остаток и дату сверки. Затем проверяет адресата и последний ответ. Если клиент уже сообщил об оплате, ближайшим действием становится уточнение платежа. Если он оспаривает сумму, сначала потребуется ответ по предмету спора.

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

Добрый день. Уточняем оплату по документу А со сроком 14 сентября.
По сверенным данным учтено 40 условных единиц, остаток составляет 60.
Подскажите, пожалуйста, ожидаемую дату оплаты остатка. Если вы уже
перевели его, сообщите данные платежа для сверки.

В настоящем сообщении нужны реальные проверенные данные и подходящий адресат. Черновик следует прочитать целиком перед отправкой. При изменении остатка пересмотрите текст до отправки.

Не приравнивайте созданный счет к отправленному. В справке QuickBooks Online автоматические напоминания описаны для счетов, уже отправленных по электронной почте.

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

Какую работу можно поручить ИИ?

Хорошее задание для ИИ содержит уже проверенный контекст: документ А, срок, остаток, последний ответ и разрешенное действие. Тогда можно попросить подготовить спокойное уточнение даты оплаты. Сотрудник сравнит черновик с полями реестра и оценит, подходит ли он к ситуации.

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

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

Доступ тоже следует ограничить задачей. Помощнику для подготовки письма не обязательно разрешать изменение подтвержденных сумм или отправку сообщения. Разделение чтения и действий разобрано в статье про ИИ для CRM. Порядок работы с реальными документами и перепиской нужно согласовать до передачи данных выбранному сервису.

Разбор числовых расхождений и объяснение их сотруднику - разные задачи. В материале «ИИ для бухгалтера» эта граница рассмотрена подробнее. Для контроля оплат начните с того, чтобы любой вычисленный остаток можно было повторно получить из исходных записей.

Как проверить процесс перед автоматизацией?

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

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

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

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

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

Чек-лист

• У документа есть актуальная версия, согласованный срок оплаты и ссылка на его основание.
• Подтвержденные поступления связаны с документом и каждый платеж учтен один раз.
• Остаток воспроизводится по исходным данным; время обновления источника и сверки видно.
• Частичная оплата, спор и ожидание привязки платежа отражены в записи.
• Обещанная дата клиента сохранена отдельно от исходного срока, рядом есть его ответ.
• Назначены исполнитель ближайшего действия и дата следующей проверки.
• Перед отправкой проверены адресат, остаток и последнее общение; отправка разрешена ответственным сотрудником.