Отчёты должны совпадать с DLR, а не с submit

Счётчики submit успокаивают: API принял сообщение, значит неделя «сработала». Это спокойствие ломает invoice-недели. Отчёт, который считает submit как success, разойдётся с DLR receipts, debit кошелька на multi-segment и webhook-аудитами.

IOSOR фиксирует правило: export отчётов следует delivery receipts. Submitted, queued и accepted-for-send — операционные хлебные крошки. Delivered, failed и unknown — колонки, о которых спорят finance и product.

Submitted — крошка, не метрика close

Accept-for-send доказывает, что путь взял задачу. Он не доказывает, что SMS дошёл до handset. Если headline KPI пака — submits, вы завысите success, когда растёт доля unknown или failed. Оставьте submit колонкой throughput при необходимости — никогда как proxy delivered.

Тренируйте ритуал close: сначала колонки DLR. Спросите, какая доля ещё unknown, что failed, что delivered. Лишь потом смотрите submits, вырос ли объём. Launch-ревью product идут в том же порядке, чтобы marketing-слайды не переопределяли success среди недели.

Колонки export следуют receipts

Схема export явно именует состояния receipt. Delivered требует DLR. Failed — терминальный сигнал отказа. Unknown остаётся unknown, пока не пришёл receipt — это не мягкий delivered. Invoice-недели, прячущие unknown внутри success, рождают классический спор «unknown share не delivered».

Когда математика сегментов расходится со счётом, начинайте с строк на receipts и сегментов на этих строках — не с submit totals, умноженных на средний guess сегментов. Путь mismatch сегментов SMS-invoice рядом; отчёт всё равно отказывает submit-as-delivered.

Сверяйте webhooks и ledger по тем же receipts

Сверка webhook-аудита с ledger export доказывает, что отчёт не фантазия. Дневные webhook-логи, статусы DLR и строки prepaid ledger должны рассказывать одну историю. Если webhooks показывают failed, а отчёт — success, виноват отчёт: чините export, не «подкручивайте» кошелёк.

Держите аудит скучным: день, receipts из webhook, ledger export, пак отчётов, совпадение message id. Пробелы — в ops; выдуманный success — владельцам схемы.

Откажитесь от invoice-недель на submit

Любой close, который биллит или празднует только по submit, блокируется. Перепишите пак так, чтобы finance сводил delivered и долю unknown. Если партнёрский контракт всё ещё говорит «successful API submits», переведите коммерческий язык в DLR-ноты export — не меняйте колонки под плохую формулировку контракта.

Связанные пути

• Неделя счетов DLR: unknown share не delivered
• Сверка webhook-аудита с ledger export
• Неделя счетов SMS: mismatch сегментов

Начните с IOSOR

Откройте недельный пакет отчётов в консоли IOSOR и проверьте, что каждый KPI в шапке строится по DLR receipts — delivered, failed и unknown — а не по submit или accept API. Если график всё ещё считает успехом submit, переименуйте или уберите его до закрытия финансов. Сделайте один экспорт с одними колонками receipts для продукта и финансов.

Итог IOSOR

Отчёты закрываются по DLR receipts: delivered, failed и unknown — не по submit. Submit годится только как throughput, не как правда доставки и не как спор по счёту.

Делайте: один экспорт на поля receipts. Не делайте: продуктовые дашборды празднуют accept, пока финансы спорят по failed DLR.