Сверка сошлась в ноль. Почему это ещё не повод закрывать день

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

Разберём условный день

Пусть начальный остаток у провайдера равен 10 000, поступления составили 250 000, возвраты 8 000, комиссии 4 500, выплата в банк 232 500. Тогда расчётный конечный остаток равен 10 000 + 250 000 − 8 000 − 4 500 − 232 500 = 15 000. Если отчёт показывает те же 15 000, движение баланса объяснено. Однако ещё нужно доказать, что возвраты относятся к правильным заказам, комиссии рассчитаны верно, а выплата действительно получена.

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

Нулевую разницу тоже можно расследовать

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

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

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

Сначала определите границы дня

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

Не все отчёты решают одну задачу. Stripe указывает, что Balance summary отражает движения и выплаты за период, но не связывает выплату с конкретными платежами. Поэтому такой отчёт подходит для проверки остатка, а не для восстановления состава каждой выплаты. Источник: Stripe, Balance summary report.

Сопоставляйте на трёх уровнях

1. 1.Заказ и операция. Свяжите внутренний идентификатор с идентификатором провайдера, типом события, суммой и валютой. Возврат должен ссылаться на исходный платёж, но оставаться отдельным движением.
2. 2.Операции и расчётный пакет. Соберите валовые поступления, возвраты, комиссии и прочие подтверждённые корректировки. Проверьте чистую сумму пакета.
3. 3.Пакет и банк. Сопоставьте выплату с банковским зачислением по доступному идентификатору, валюте и сумме. Допустимую разницу в датах задавайте отдельно от допуска по сумме.

У Adyen Settlement details report содержит операции, комиссии, корректировки депозита и выплаты; запись MerchantPayout помогает связать пакет с банковским поступлением. Это пример того, почему одной выгрузки успешных платежей для сверки недостаточно. Источник: Adyen, Settlement details report.

Очередь расхождений должна объяснять причину

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

Отчёт Stripe по сверке выплат ориентирован на автоматические выплаты; для мгновенных выплат Stripe не определяет автоматически состав включённых операций. Метод сверки поэтому нужно выбирать с учётом конкретного режима выплат. Источник: Stripe, Payout reconciliation report.

Возраст расхождения считайте от обещанного события

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

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

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

Что остаётся открытым после закрытия дня

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

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