17 мая 2025 г.·5 мин

Кредитный лимит для B2B‑заказов и условия оплаты по клиенту

Назначьте лимиты и условия по каждому клиенту, затем автоматизируйте кредитный gate для B2B‑заказов: удерживайте рисковые заказы и направляйте их на проверку.

Какую проблему решает кредитный лимит (простыми словами)

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

Кредитный лимит — это простой контроль безопасности перед окончательным принятием заказа. Он сравнивает то, что клиент уже должен (и что он собирается задолжать), с согласованным лимитом. Если новый заказ выводит баланс за пределы лимита, система не отклоняет заказ навсегда. Она приостанавливает его для проверки.

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

Условия оплаты меняют риск, потому что они определяют, как долго ваши деньги «заморожены». Предоплата — низкий риск, потому что деньги приходят заранее. Net 30 может быть приемлемым при соблюдении лимита и своевременной оплате. Net 60 (или индивидуальные условия) увеличивают экспозицию на более длительный срок.

Ворота также уменьшают путаницу между командами, потому что превращают вопрос «можем ли мы отгрузить?» в видимый, согласованный статус для продаж, финансов и операций.

Что хранить в карточке клиента (лимиты, условия, экспозиция)

Ворота работают только если в карточке клиента есть несколько полей, которым можно доверять в бизнес‑правиле бэкенда. Держите список коротким и делайте каждое значение понятным.

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

Далее храните условия оплаты как структурированные данные, а не как свободный текст. Используйте понятный тип (Предоплата, COD, Net 15, Net 30, Net 60) и сохраняйте число «net» дней, когда это уместно. Тогда логика заказа сможет ветвиться без догадок.

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

Сумма кредитного лимита и валюта
Тип условий оплаты и число net‑дней (если применимо)
Временный оверрайд суммы (по желанию) с таймстампом истечения
Примечание о причинах оверрайда и кто его предоставил
Ручной переключатель удержания (кнопка «стоп»)

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

Наконец, держите небольшой набор статусов заказа, чтобы удержания были видимы и по ним можно было действовать. Например: Approved, On hold, Released, Cancelled.

Модель данных для лимитов, условий и удержаний заказов

Ваша модель данных должна делать три вопроса простыми для ответа: кто покупает, на каких условиях и сколько он уже должен.

Начните с сущности Customer, которая содержит входные данные для решения: кредитный лимит, стандартные условия оплаты и политику удержания (например, авто‑удержание при превышении лимита, разрешать с флагом или блокировать оформление).

Заказы должны хранить и триггер, и результат. Сохраняйте метод оплаты, сумму заказа и статус, который может представлять «On hold», не перегружая «Pending». Добавьте причину удержания, чтобы люди могли отличать «превышение лимита» от других проблем (например, проверка адреса).

Минимальная схема часто включает:

Customers: credit_limit, payment_terms_code, hold_policy, credit_status
Orders: total_amount, payment_method, status, hold_reason, held_at
Invoices / AR: invoice_total, open_balance, due_date, status (open/paid/void)
Credit overrides: customer_id, override_amount_or_limit, expires_at, approved_by
Audit log: entity_type, entity_id, changed_fields, changed_by, changed_at, note

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

Держите оверрайды в отдельной таблице. Это предотвращает беспорядочные правки основного кредитного лимита и дает цепочку утверждений.

Как считать кредитную экспозицию и доступный кредит

Математика должна быть зафиксирована письменно и использоваться последовательно в приложении и в финансовых отчетах.

Обычная базовая формула:

Кредитная экспозиция = неоплаченные счета + стоимость открытых заказов

Тогда:

Доступный кредит = кредитный лимит − кредитная экспозиция

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

Несколько корректировок помогут избежать сюрпризов:

Частичные платежи уменьшают неоплаченные счета только при фактическом поступлении средств (не при «инициации» платежа).
Кредит‑ноты и возвраты уменьшают экспозицию только после их выпуска и утверждения.
Отмененные заказы должны сразу исключаться из суммы открытых заказов.
Возвраты обычно уменьшают экспозицию после утверждения кредит‑ноты, а не при самой заявке на возврат.

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

При создании заказа или при его утверждении (выберите одно и придерживайтесь)
При выставлении счета (перевод значения из открытых заказов в неоплаченные счета)
При проведении платежа (освобождение экспозиции)

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

Пошагово: строим бэкенд‑правило для удержания заказов

Сделать удержания видимыми для всех

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

Сделать портал

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

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

Если прогнозная экспозиция в пределах лимита — пометьте заказ как Approved.
Если прогнозная экспозиция превышает лимит — установите статус On hold.

При удержании заказа запишите детали, которые потом объяснят решение:

Причина удержания (например, «Превышение кредитного лимита на $2,450»)
Владелец следующего действия (например, «AR team» или конкретный менеджер)
Аудит‑запись с входными данными (лимит на момент проверки, компоненты экспозиции, кто инициировал проверку, таймстамп)

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

Одобрения и уведомления, чтобы удержанные заказы не застревали

Удержание полезно только если по нему быстро принимают отслеживаемое решение.

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

Что показывать на экране одобрения

Сократите экран до необходимого минимума, но включите числа, которые нужны для решения:

Кредитный лимит, текущая экспозиция, доступный кредит
Сумма заказа и на сколько она превышает лимит
Условия оплаты в карточке и запрошенные условия (если отличаются)
Небольшой набор заметок по аккаунту (например, «новый клиент» или «один раз просрочил»)
Обязательное поле для комментария

После решения запишите запись в журнал одобрений (ID заказа, решение, утверждающий, таймстамп, комментарий). Это становится аудиторским следом и объясняет задержки.

Уведомления и временные лимиты

Уведомляйте нужных людей моментально при удержании заказа через каналы, которыми команда реально пользуется (email, SMS или Telegram). Добавьте напоминания и эскалацию, чтобы удержания не лежали в тишине. Практичная схема — напоминание через 2 часа, эскалация через 24 часа и автo‑отмена через 72 часа, если никто не рассмотрел.

Если полное снятие слишком рискованно, разрешайте условные релизы (частичная отгрузка, требование депозита, сокращенные условия оплаты) и фиксируйте условия, чтобы выполнение и выставление счета следовали одной политике.

Операционный поток: что происходит после удержания заказа

Добавить триггеры повторной проверки

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

Настроить правила

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

Продажи, операции и финансы должны видеть один и тот же сигнал удержания. Используйте статус вроде «On credit hold» плюс поле причины (например, «Экспозиция превышает лимит на $1,240»). Добавьте короткую внутреннюю заметку, чтобы людям не приходилось гадать.

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

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

«Ваш заказ временно приостановлен для плановой проверки аккаунта. Ответьте, чтобы подтвердить сроки оплаты, или запросите частичную отгрузку.»
«Мы можем отгрузить после получения платежа или корректировки кредитного лимита. Что вам удобнее?»
«Мы можем разбить заказ и отгрузить те позиции, которые помещаются в ваш доступный кредит.»

Когда приходит платеж, выбирайте между авто‑релизом и ручным релизом. Авто‑релиз подходит, когда платежи надежно соответствуют счетам. Ручной релиз безопаснее при частичных или неясных платежах. Частый компромисс — авто‑релиз только если платеж полностью покрывает просроченный баланс; в противном случае направлять в финансы.

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

Пример сценария: оптовый заказ, превышающий порог

Чисто обрабатывать оверрайды

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

Начать проект

Оптовый клиент BrightSide Supplies имеет условия Net 30 и кредитный лимит 50,000.

У него есть неоплаченные счета на 38,000. Он делает новый заказ на 15,000.

Прогнозная экспозиция = 38,000 + 15,000 = 53,000. Поскольку 53,000 больше лимита в 50,000, заказ ставится на удержание и направляется в финансы для проверки. Отдел продаж по‑прежнему видит заказ, но он не может быть упакован, отгружен или выставлен в счёт, пока риск не будет снижён.

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

Бычьий чек‑лист перед включением в прод

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

Начните с небольшой и разнородной тестовой выборки (5–10 клиентов): один с Net 30 и низким лимитом, один с высоким лимитом, один предоплатный, один с несколькими открытыми счетами и один, который часто редактирует заказы после оформления.

Проверьте два момента:

Сходится ли математика экспозиции с ожиданиями бухгалтерии (включая то, что вы учитываете и что не учитываете).
Запускается ли правило удержания в нужные моменты: при создании заказа и при любых правках, которые увеличивают экспозицию (изменение количества, цены, добавление доставки, снятие скидки).

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

Частые ошибки и как их избежать

Построить поток кредитного удержания

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

Создать сейчас

Большинство проблем не технические. Они происходят, когда правило проверяет не ту величину или люди учатся обходить систему.

Частые ошибки:

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

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

Следующие шаги: внедрить ворота в приложении заказов и итеративно улучшать

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

Если вы строите приложение заказов без ручной разработки, AppMaster (appmaster.io) может быть практичным вариантом: вы визуально моделируете клиентов, заказы, счета и оверрайды, а затем реализуете логику удержания как бэкенд‑бизнес‑процесс, который пересчитывает экспозицию при создании, редактировании, выставлении счетов и при поступлении платежей.

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

Вопросы и ответы

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

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

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

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

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

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

Немедленно оповещайте людей, которые могут действовать — обычно команда финансов и резервный менеджер. Добавьте напоминания и эскалацию с четкими временными рамками, чтобы удержания не лежали бесконтрольно; практичный шаблон — напоминание через 2 часа, эскалация через 24 часа и автo‑отмена через 72 часа, если никто не рассмотрел заказ.

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

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

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