Reports must match DLR, not submit counts

Submit counts feel comforting: the API accepted the message, so the week “worked.” That comfort breaks invoice weeks. A report that tallies submits as success will disagree with DLR receipts, wallet debits for multi-segment traffic, and webhook audits.

IOSOR locks the rule: report exports follow delivery receipts. Submitted, queued, and accepted-for-send stay operational breadcrumbs. Delivered, failed, and unknown are the columns finance and product argue about.

Submitted is a breadcrumb, not a close metric

Accept-for-send proves the path took the job. It does not prove the handset got the SMS. If your report pack’s headline KPI is submits, you will overstate success whenever unknown or failed share rises. Keep submit as a throughput column if useful — never as the delivered proxy.

Train the close ritual: open DLR columns first — unknown, failed, delivered — then glance at submits for volume. Product launch reviews use the same order so marketing slides cannot redefine success mid-week.

Export columns follow receipts

The export schema names receipt states explicitly. Delivered requires a DLR. Failed requires a terminal failure signal. Unknown stays unknown until a receipt lands — it is not a soft delivered. Invoice weeks that hide unknown inside success create the classic “unknown share is not delivered” fight.

When segment math and the bill disagree, start from receipt-backed rows and their segment counts — not submit totals times an average segment guess. The SMS invoice-week segment path stays adjacent; the report still refuses submit-as-delivered.

Reconcile webhooks and ledger against the same receipts

Webhook audit reconciliation against ledger export is how you prove the report is not a fantasy. Daily webhook logs, DLR states, and prepaid ledger lines must tell one story. If webhooks show failed while the report shows success, the report is wrong — fix the export, do not “adjust” the wallet.

Keep the audit cadence boring: one day, webhook receipts, ledger export, report pack, match message ids. Gaps go to ops; invented success goes back to schema owners.

Refuse submit-based invoice weeks

Any close that bills or celebrates on submit counts alone is blocked. Rewrite the pack so finance pivots delivered and unknown share. If a partner contract still says “successful API submits,” translate that talk into DLR notes — do not bend the columns to match bad wording.

Related ops paths

• DLR invoice week: unknown share is not delivered
• Webhook audit reconciliation against ledger export
• SMS invoice week: segment mismatch

Start with IOSOR

Open this week’s report pack in the IOSOR console and confirm every headline KPI is keyed off DLR receipts — delivered, failed, and unknown — not raw submit or API-accepted counts. If a chart still tracks submits as success, retitle or drop it before finance closes. Export once and keep the same receipt columns for product and finance.

IOSOR takeaway

Reports close on DLR receipts: delivered, failed, and unknown — not submits. Submit counts are useful for throughput, never for delivery truth or invoice arguments.

Do: lock one export schema to receipt fields. Don’t: let product dashboards celebrate accepts while finance argues failed DLR.