Как сверить журнал сервисных SMS со счётом провайдера?

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

Дата публикации: 2026-11-07. Материал посвящён сервисным уведомлениям: подтверждениям операций, кодам авторизации и сообщениям о статусе заказа.

Какие данные нужны для сверки журнала и счёта?

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

Для мониторинга SMS-интеграции рекомендуют фиксировать технический идентификатор, время постановки в очередь, время передачи, ответ шлюза и итоговый статус. Эти поля помогают сопоставить событие в CRM с записью в SMS-системе (источник: smpp.by, «Как настроить мониторинг SMS-интеграции в 2026 году»).

Соберите рабочий файл для сверки. В нём нужны следующие группы полей:

• ID бизнес-операции и внутренний ID отправки, чтобы найти исходное уведомление.
• ID сообщения у провайдера, чтобы связать журнал с детализацией.
• Время передачи и часовой пояс, чтобы правильно определить расчётный период.
• Число сегментов, применённая цена и сумма начисления.
• Финальный статус, код ошибки и связь с предыдущей попыткой, если был повтор.

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

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

Почему число строк в журнале не равно числу оплачиваемых SMS?

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

При работе через SMPP провайдер обычно считает отправленные сегменты, а не количество вызовов команды submit_sm. Расчёт нужно сверять с биллингом поставщика (источник: smpp.by, «Как рассчитать стоимость SMS через SMPP в 2026 году»).

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

1. Отберите отправки за период счёта с учётом часового пояса выгрузки.
2. Объедините события по ID сообщения, сохранив историю статусов.
3. Возьмите число оплачиваемых сегментов из детализации провайдера и проверьте спорные записи.
4. Разделите отправки по ставке и условиям тарификации.
5. Умножьте объём каждой группы на её цену и сложите результаты.

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

Как проверить статусы доставки и повторные отправки?

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

Для контроля доставки полезно разделять сообщения на переданные, доставленные, завершившиеся ошибкой и оставшиеся без финального статуса. Последнюю группу проверяйте отдельно, без автоматического отнесения к ошибкам (источник: mobizon.by, «Почему SMS не доходят клиентам в Беларуси: чек-лист»).

Задайте для каждого сервисного сценария допустимое время ожидания DLR. Такой подход помогает выделить отправки, которые требуют проверки, и не смешивать их с сообщениями, по которым уже получен окончательный результат (источник: smsinfo.by, «Как контролировать доставку сервисных SMS в 2026 году»).

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

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

Задержку доставки тоже разбирайте отдельно от стоимости. Если сообщение пришло поздно, сравните время бизнес-события, передачи провайдеру и получения DLR. Порядок такой проверки описан в материале о том, как проверить скорость доставки сервисных SMS в Беларуси.

Что делать, если журнал и счёт не совпадают?

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

Для спорной позиции соберите короткую цепочку: операция в вашей системе, запрос к шлюзу, ID провайдера, история статусов и начисление. Одна запись об успешном ответе API не раскрывает всю историю уведомления. Для диагностики нужна связь между запросом, очередью, ответом провайдера, повторами и DLR (источник: QUICKTEL, «Логи SMS-отправок для поддержки и диагностики»).

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

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

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

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

Типичные ошибки при сверке сервисных SMS

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

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