Партнёрское вознаграждение без споров: база, событие и реестр выплат

Партнёр открывает письмо и видит: «За прошлый месяц вам начислено 47 300 ₽». В его таблице — 61 000 ₽. Менеджер считает процент от подписанных договоров, финансы — от поступивших денег без НДС, а партнёр — от всей суммы счетов. Одна из сделок оплачена частями, по второй был возврат, третью компания считает дублем.

Проблема не в формуле процента. Три стороны считают разные события и называют результат одним словом «продажа».

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

Сначала разведите четыре суммы

В интерфейсе и отчёте не стоит показывать одно поле «вознаграждение», которое меняет смысл по мере движения сделки. Используйте четыре самостоятельных состояния.

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

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

К выплате — начисление прошло необходимые проверки и включено в ближайший платёжный период. Здесь уже учтены корректировки и документы, предусмотренные выбранной схемой работы.

Выплачено — деньги фактически перечислены, сохранены дата и идентификатор операции. Статус «отправили в бухгалтерию» выплатой не является.

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

База расчёта: от какой суммы берётся процент

Фраза «10% со сделки» почти ничего не определяет. У одной сделки могут быть цена договора, выставленные счета, фактические поступления, НДС, скидка, стоимость сторонних услуг, возврат и несколько периодов оплаты.

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

• используется сумма договора, счёта или полученной оплаты;

• включаются ли налоги и сборы;

• исключаются ли доставка, лицензии третьих сторон и компенсируемые расходы;

• как учитываются скидки и промокоды;

• считается ли продление той же сделкой;

• что происходит с рассрочкой;

• в какой валюте и по какому правилу пересчитываются поступления;

• как долго действует право партнёра на повторную выручку клиента.

Пример прозрачной формулировки для внутреннего расчёта: «База равна фактически полученной компании оплате за собственные услуги по связанному договору, за вычетом возвратов и позиций, прямо исключённых в приложении». Это не универсальное условие, а образец точности. Конкретную формулировку проверяют юрист и бухгалтер с учётом модели бизнеса.

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

Событие начисления: когда возникает основание

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

Выберите событие, которое одновременно:

1. связано с реальной ценностью для бизнеса;

2. однозначно фиксируется в системе;

3. может быть подтверждено конкретной ролью;

4. понятно партнёру до передачи лида;

5. не требует раскрывать ему лишние данные клиента.

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

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

Формула, которую можно прочитать слева направо

Хорошая формула помещается в одну строку, а все исключения вынесены в явные определения:

Вознаграждение = подтверждённая база × ставка + фиксированные бонусы − корректировки.

Допустим, ставка партнёра — 8%, подтверждённая база по оплате — 400 000 ₽, а возврат по части услуги составил 50 000 ₽ и по правилам уменьшает базу. Тогда сначала фиксируется новая база 350 000 ₽, и только после этого рассчитываются 28 000 ₽. Нельзя молча вычесть 4 000 ₽ из готового вознаграждения: партнёр должен увидеть происхождение изменения.

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

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

Корректировки: возвраты, рассрочка, дубли и отмены

Исключения нельзя дописывать после первого спора. Составьте таблицу до запуска.

• Ситуация: Частичная оплата; Что проверить: какие деньги получены; Возможное правило процесса: считать базу по каждой подтверждённой части

• Ситуация: Возврат; Что проверить: относится ли он к включённой позиции; Возможное правило процесса: уменьшить будущий реестр отдельной строкой

• Ситуация: Дубль; Что проверить: был ли активный контакт в установленном окне; Возможное правило процесса: применить заранее заданный приоритет источника

• Ситуация: Смена тарифа; Что проверить: новая продажа или изменение прежней; Возможное правило процесса: закрепить правило для расширений и продлений

• Ситуация: Расторжение; Что проверить: какое событие уже подтверждено; Возможное правило процесса: использовать установленное окно корректировки

• Ситуация: Несколько партнёров; Что проверить: какой вклад фиксировался первым; Возможное правило процесса: не делить сумму вручную без правила

Корректировка должна ссылаться на исходное начисление. Отрицательная строка «прочее» разрушает проверяемость. Покажите тип, сумму, дату, причину и ответственное решение, не раскрывая партнёру внутренние комментарии или персональные данные клиента.

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

Реестр выплат: одна строка — одна объяснимая история

Минимальная строка реестра содержит:

• идентификатор партнёра;

• идентификатор рекомендации без лишних данных клиента;

• целевое событие и дату его подтверждения;

• исходную базу;

• исключения и итоговую базу;

• ставку или фикс;

• сумму начисления;

• корректировки со ссылками;

• статус проверки;

• плановую и фактическую дату выплаты;

• идентификатор платёжной операции.

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

Партнёру не нужен бухгалтерский экран. Покажите человеческое объяснение: «Первая оплата подтверждена 12 июня; база 350 000 ₽; ставка 8%; начислено 28 000 ₽; включено в реестр за июнь; плановая выплата 10 июля». Если строка требует звонка менеджеру, прозрачность ещё не достигнута.

Ежемесячное закрытие без чатов и ручных догадок

Установите календарь, известный всем участникам:

1. До даты отсечения система собирает подтверждённые события периода.

2. Владелец продаж проверяет связь рекомендации и сделки.

3. Финансы проверяют базу, корректировки и комплект документов.

4. Спорные строки выводятся из автоматического пакета, но не исчезают.

5. Уполномоченный сотрудник утверждает реестр.

6. После перечисления фиксируются фактическая дата и платёжный идентификатор.

7. Партнёр получает расшифровку и канал для мотивированного возражения.

Для агентской модели порядок отчётов и вознаграждения должен соответствовать договору. ГК РФ отдельно регулирует агентское вознаграждение и отчёты агента; например, статья 1008 связывает отчётность с условиями договора и предусматривает порядок возражений.[1][2] Конкретные сроки, документы и налоговые последствия проверяйте с юристом и бухгалтером под статус получателя и фактические отношения.

Не храните единственную истину в Excel-файле, который бухгалтер формирует в конце месяца. Реестр может выгружаться в таблицу, но исходные события, решения и связи должны сохраняться там, где их можно восстановить.

Проверка на пяти неудобных примерах

До объявления ставки проведите правила через пять сценариев:

• клиент оплатил половину и задержал вторую часть;

• возврат произошёл после выплаты партнёру;

• контакт уже был в CRM, но без активности;

• два партнёра независимо привели людей из одной компании;

• договор подписан при одной версии ставки, деньги пришли при другой.

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

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

Разбор расхождения: откуда взялись 47 300 ₽ и 61 000 ₽

Вернёмся к письму из начала статьи. Партнёр посчитал три подписанных договора на общую сумму 610 000 ₽ и применил ставку 10%. Его логика проста: 61 000 ₽. В таблице менеджера та же ставка применяется только к двум сделкам, потому что третья помечена дублем. Но сумма менеджера всё равно не совпадает с выплатой.

Финансы открывают банковские поступления. По первой сделке клиент перечислил 300 000 ₽ полностью. По второй из 200 000 ₽ поступило 150 000 ₽, причём 20 000 ₽ относятся к лицензии стороннего поставщика и исключены из базы. Третья сделка на 110 000 ₽ действительно связана с компанией, которая уже находилась в активной работе до рекомендации.

Если действующее правило устанавливает базу по фактически полученной оплате за собственные услуги, расчёт выглядит так:

• Строка: Сделка 1; Подтверждённая база: 300 000 ₽; Ставка: 10%; Результат: 30 000 ₽

• Строка: Сделка 2; Подтверждённая база: 130 000 ₽; Ставка: 10%; Результат: 13 000 ₽

• Строка: Сделка 3; Подтверждённая база: 0 ₽ до решения по дублю; Ставка: 10%; Результат: 0 ₽

Получается 43 000 ₽, а не сумма из письма. Оставшиеся 4 300 ₽ обнаруживаются в отдельной строке: корректировка прошлой сделки, по которой истёк период возврата. Теперь арифметика сходится — 47 300 ₽, — но процесс всё ещё плох. Партнёр не мог восстановить сумму, потому что письмо показало только итог.

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

Затем команда находит более глубокий дефект: в правилах сказано «10% от продажи», а нужное определение фактически жило только в файле финансов. До следующего периода компания обновляет доступное партнёрам описание базы, фиксирует версию и дату применения. Уже созданные строки не пересчитываются новым правилом без предусмотренного основания.

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

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

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

Фикс или процент — только поверхность. Доверие создают версия правила, история решений и реестр, в котором прогноз не смешан с начислением, а начисление — с выплатой.

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

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

Источники

• [1] https://www.consultant.ru/document/cons_doc_LAW_9027/24797d98f3b1dee66fa0d33a07431baf553b7650/

• [2] https://www.consultant.ru/document/cons_doc_LAW_9027/61c9aed64e81a8aed5c7a49cd10b5dce832ac726/

• [3] https://app.recomcode.ru/help/company-goal-economics

• [4] https://app.recomcode.ru/help/rewards-window

• [5] https://www.nalog.gov.ru/rn53/news/activities_fts/16643640/