Биллинг: тарифы, подписки и деньги, которые теряются на округлениях

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

Модель определяет, что система обязана уметь, поэтому её выбирают раньше, чем пишут первую строку кода.

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

Недосчитанное потребление. События теряются на пути от продукта к расчётному ядру, и часть услуг не тарифицируется вообще. Компания оказывает услугу бесплатно и не знает об этом.

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

Расхождения на закрытии. Итог сервиса не сходится с учётной системой на копейки. Бухгалтерия закрывает период руками, и каждый месяц на это уходит несколько дней.

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

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

Тариф стоит 3000 ₽ в месяц. Клиент переходит на другой тариф 12 марта, в месяце 31 день. За 11 дней старого тарифа приходится 3000 × 11 ÷ 31 = 1064,516 ₽. Округление до копеек даёт 1064,52 ₽, округление до рублей — 1065 ₽. Разница копеечная, но на тысяче переходов в месяц она превращается в сотни рублей, и накапливается она каждый месяц.

Второй классический случай — скидка на счёт из нескольких позиций. Скидка 10% на три позиции по 333,33 ₽: сумма скидок, посчитанных по каждой позиции, и скидка от итоговой суммы различаются на копейку. Обе арифметики верны, но результат разный.

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

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

Основная ставка НДС повышена с 20% до 22% — Федеральный закон от 28.11.2025 № 425-ФЗ. Пониженные ставки 0% и 10% для отдельных категорий сохранены. Для продукта с подписками из этого следуют три конкретных требования.

Первое. Расчётный период, начавшийся в декабре 2025 года и закончившийся в январе 2026, попадает на две разные ставки. Правило распределения задаёт бухгалтерия, а реализовать деление обязана система, и заранее её к этому обычно никто не готовит.

Второе. В тарифной сетке нужно однозначно понимать, цена указана с налогом или без. При смене ставки цена «с НДС» меняется для клиента, цена «без НДС» — для компании. Оба варианта законны, но выбор влияет на выручку, и делают его один раз.

Третье. Компании на упрощённой системе с 2026 года платят НДС, если доход за 2025 год превысил 20 млн ₽. Если порог превышен в течение 2026 года, налог считают с первого числа месяца, следующего за месяцем превышения. Для биллинга это означает, что ставка налога у продавца может измениться в середине года. Хранить её нужно параметром с датой действия.

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

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

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

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

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

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

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

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

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

Поэтому система с самого начала строится на неизменяемых записях. Начисление не редактируют — его сторнируют и создают новое, а история операций остаётся целиком. Такой подход дороже на старте и единственный, который переживает первую же налоговую проверку.

Практическое следствие для требований: спросить про пересчёты нужно до проектирования. Ответ «нам это не понадобится» на практике не сбывается почти никогда.

Тарифная сетка живёт год-полтора, потом её пересматривают. Клиенты при этом остаются на прежних условиях — иногда по договору, иногда из соображений лояльности.

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

Правильная модель простая. Тариф — версионируемая сущность с датами действия, подписка клиента ссылается на конкретную версию, а перевод на новую версию оформляется отдельной операцией с датой. Тогда ответ на вопрос, почему этот клиент платит 2400 при цене тарифа 3000, находится за десять секунд.

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

Требование 54-ФЗ формулируется просто: при расчёте с физическим лицом нужен кассовый чек. Каждое автосписание считается отдельным расчётом, поэтому чек формируется на каждое, а не только при оформлении подписки.

Жёсткой формы наименования услуги закон не устанавливает. Требование одно — из чека должно быть понятно, за что заплатили. Формулировка вида «Доступ к сервису, 30 дней» работает, абстрактное «Оплата услуг» вызывает вопросы.

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

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

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

Расчётное ядро отвечает за тарифы, начисления, счета, платежи и баланс. Личный кабинет показывает клиенту его баланс, документы и историю. Учётная система принимает проводки и закрывает период. Аналитика считает выручку, отток и доход с клиента.

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

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

Вариантов четыре, и комбинация встречается чаще одного чистого решения.

Смету задают три параметра. Сложность тарифной модели, число внешних систем в контуре и требование пересчётов задним числом.

По нашим работам ориентиры такие. Расчётное ядро под процесс компании обходится от 1,7 млн ₽, бэкенд и веб-часть с личным кабинетом — от 1 млн ₽, отдельный личный кабинет с балансом и документами — от 800 тыс. ₽, интеграция с платёжным провайдером, кассой или учётной системой — от 150 тыс. до 1,5 млн ₽ за каждую. Точную цифру считаем по вашей тарифной модели: оценка проекта бесплатная.

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

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

Начисления редактируют на месте. История теряется, объяснить клиенту старый счёт невозможно, корректирующих документов нет.

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

Тариф зашит в код. Изменение цены становится релизом, а старые клиенты живут набором исключений.

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

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

Второе — зафиксировать арифметику. База неполного периода, знак и сторона округления, порядок применения скидки и налога. Один документ на страницу снимает половину будущих расхождений с бухгалтерией.

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