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

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

Учёт взаиморасчётов и бухгалтерская программа: одно и то же?

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

Основа: сальдо это журнал, а не поле

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

type LedgerEntry = {
  accountId: string;
  kind: 'invoice' | 'payment' | 'credit_note' | 'adjustment';
  amountMinor: number; // долг положительный, оплата отрицательная (копейки)
  dueDate?: Date;
  postedAt: Date;
};

export function summarize(entries: LedgerEntry[], today: Date) {
  const balance = entries.reduce((sum, e) => sum + e.amountMinor, 0);

  // Оплаты сначала закрывают самый старый счёт (FIFO).
  let credit = -entries
    .filter(e => e.amountMinor < 0)
    .reduce((sum, e) => sum + e.amountMinor, 0);

  let overdueMinor = 0;
  const invoices = entries
    .filter(e => e.amountMinor > 0)
    .sort((a, b) => (a.dueDate?.getTime() ?? 0) - (b.dueDate?.getTime() ?? 0));

  for (const inv of invoices) {
    const covered = Math.min(credit, inv.amountMinor);
    credit -= covered;
    const open = inv.amountMinor - covered;
    if (open > 0 && inv.dueDate && inv.dueDate < today) overdueMinor += open;
  }

  return { balance, overdueMinor };
}

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

Сроки оплаты и отчёт о старении долга

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

• У каждого счёта свой срок оплаты; он берётся из стандартных условий клиента, но может меняться в конкретном счёте.
• Оплата знает, какой счёт она закрывает. Если пользователь не выбрал, закрывается самый старый счёт.
• Интервалы фиксированы (срок не наступил, 1-30, 31-60, 61-90, более 90 дней) и одинаковы во всех отчётах.
• Валютные расчёты ведутся в своей валюте; курсовая разница проводится отдельной записью.
• Отчёт можно построить на любую дату; положение на конец прошлого месяца задним числом не меняется.

Напоминания об оплате и процесс взыскания

Большая часть оплат приходит после напоминаний, и напоминания должны быть регулярными. Плановая задача каждое утро находит счета с наступающим и просроченным сроком, отправляет клиенту письмо или сообщение в WhatsApp и отмечает отправку в карточке; по одному счёту в один день второе сообщение не уходит. Как надёжно запускать такую задачу, описано в статье про cron, канал сообщений в статье интеграция WhatsApp Business API. Оплата по ссылке из сообщения проводится автоматически, когда приходит уведомление платёжного провайдера; проверка этого уведомления разобрана в статье про webhook. Клиенты с долгой просрочкой выходят из автоматической цепочки и становятся задачей конкретного сотрудника.

Акт сверки и кредитный лимит

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

Готовая программа или заказная разработка?

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

Итог

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