Что именно нужно сверять каждый день
Сверка - это не поиск одной суммы в выписке, а сопоставление платежа, заказа, CRM-статуса, ERP-записи и возврата.
Если бизнес принимает онлайн-платежи, каждый рабочий день должен закрываться не только банковской выпиской. Нужно понимать, какие платежи прошли у провайдера, какие заказы закрылись на сайте, какие сделки обновились в CRM и какие записи ушли в ERP или бухгалтерский контур.
Основной ответ: сверять нужно не "суммы вообще", а конкретные пары идентификаторов. Минимальный набор - provider reference, internal payment id, order id, сумма, валюта, время создания, финальный статус и источник записи. Если хотя бы одного идентификатора нет, операционная команда будет искать платежи вручную.
- provider reference из банка или платежного провайдера;
- internal payment id и order id из сайта или backend;
- CRM deal, invoice или lead id;
- ERP document id, если заказ передается в учет;
- refund id и сумма возврата, если возвраты разрешены.
Какие расхождения считать критичными
Не каждое расхождение означает потерю денег, но каждое должно иметь тип и ответственного.
Самый опасный случай - провайдер показывает successful, а сайт или CRM все еще видит pending. Клиент уже заплатил, но заказ не обработан, менеджер не получил уведомление, а поддержка узнает о проблеме только из обращения клиента.
Другие типовые mismatch-случаи: сумма в CRM отличается от суммы у провайдера, возврат проведен у провайдера, но не отражен в ERP, платеж пришел без понятного order id, webhook не дошел, а ручное исправление не было зафиксировано в audit trail.
- provider paid, website pending;
- CRM paid, provider failed или cancelled;
- amount или currency mismatch;
- refund есть у провайдера, но отсутствует во внутреннем учете;
- ручная правка без комментария и ответственного.
Как построить рабочий reconciliation flow
Оператор должен работать со списком исключений, а не с полной таблицей всех платежей.
Практичный flow выглядит так: система загружает данные провайдера и внутренние записи за период, сопоставляет их по reference и order id, закрывает совпадения автоматически, а все расхождения складывает в короткий список исключений.
Для каждого исключения нужен тип, причина, ответственный, комментарий и результат повторной проверки. Тогда сверка перестает быть ручным поиском в таблицах и становится управляемым процессом, который можно передать оператору, бухгалтерии или интегратору.
- автоматически закрывать exact matches;
- выносить mismatches в отдельную очередь;
- логировать ручные решения и повторные проверки;
- использовать один timezone и правила округления;
- разделять sale, refund и partial refund.
FAQ
Сверку нужно делать по выписке банка или по отчету платежного провайдера?
Лучше использовать оба источника. Отчет провайдера помогает сопоставить payment id и статусы, а банковская выписка подтверждает движение денег и закрытие периода.
Можно ли делать сверку раз в месяц?
Можно, но это повышает операционный риск. Для e-commerce и CRM-счетов лучше закрывать исключения ежедневно, пока клиент, заказ и платеж еще легко восстановить по событиям.
Что считать хорошим результатом сверки?
Хороший результат - не отсутствие всех ошибок, а прозрачный список исключений, где у каждого mismatch есть тип, причина, ответственный и история исправления.
Источники
- Stripe Documentation - Balance summary reportОфициальный пример того, как платежный провайдер структурирует отчеты для сверки баланса и транзакций.
- Stripe Documentation - How to select a reportДокументация по выбору отчетов для сверки транзакций, выплат и баланса.
- Armeconombank - VPOSОфициальная страница vPOS с условиями, тестовым запуском и платежными требованиями к сайту.
