Баланс есть, истории нет: когда платежам нужен денежный реестр

В кабинете продавца было 100 евро, стало 70. Разработчик объясняет: «Мы поправили баланс после возврата». Финансовая команда спрашивает: какой возврат, кто его разрешил и почему на 30? Если ответ находится только в переписке, число на экране уже перестало быть проверяемым результатом. Оно стало чьим-то последним мнением о деньгах.

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

Что именно означает ваш баланс

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

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

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

Один условный платёж на 100 евро

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

После этих событий требование платформы к PSP составляет 98 евро. Обязательство перед продавцом составляет 97 евро. Экономический результат платформы до других расходов равен 1 евро. Можно проверить равенство: 98 = 97 + 1. Если в интерфейсе продавца появилось 98, вероятно, смешали деньги у провайдера и обязательство перед продавцом.

Теперь из 97 евро продавца временно ограничены 20 по заранее согласованному основанию. Доступно к выплате 77, но общий долг перед ним остаётся 97. Снятие ограничения вернёт доступность, а не создаст новую продажу. Если модель продукта трактует удержание иначе, это нужно отразить явно, а не подгонять расчёт под пример.

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

Исправление оставляет след

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

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

Операционное правило для ручного исправления: покажите ожидаемый эффект до исполнения. Какая сумма изменится у какого участника? Какая доступность станет другой? Как коррекция отразится в следующем отчёте? Для существенных действий применяйте согласованные полномочия и контроль второго сотрудника.

Копейки и валюты относятся к модели

Не складывайте евро и доллары в один денежный счёт без явной операции обмена. Храните валюту и масштаб суммы. В API Stripe суммы обычно задаются в минимальных единицах, при этом для отдельных валют и выплат действуют особые правила. Правила формата сумм Stripe показывают, почему универсальное «умножить на сто» опасно.

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

Начните с одного спорного остатка

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

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