Les rapports doivent correspondre aux DLR, pas aux soumissions

Les volumes de soumission sont rassurants : l API a accepté le message, donc la semaine semble réussie. Ce confort s effondre lors des semaines de facturation. Un rapport qui comptabilise les soumissions comme des succès sera en désaccord avec les accusés DLR, les débits de portefeuille pour le trafic multi-segments et les audits webhook.

IOSOR applique une règle stricte : les exports de rapports suivent les accusés de réception. Les états soumis, en file d attente et accepté pour envoi restent des repères opérationnels. Livré, échoué et inconnu sont les seules colonnes sur lesquelles la finance et le produit doivent débattre.

La soumission est une trace, pas une métrique de clôture

L acceptation pour envoi prouve que le système a pris en charge la tâche. Cela ne prouve pas que le téléphone a reçu le SMS. Si le KPI principal de votre rapport est le nombre de soumissions, vous surdimensionnerez le succès dès que la part d échecs ou d inconnus augmentera. Conservez la soumission comme colonne de débit si nécessaire, mais jamais comme un indicateur de livraison.

Les colonnes d export suivent les accusés de réception

Le schéma d export nomme explicitement les états de réception. Le statut livré exige un DLR. Le statut échoué exige un signal de défaillance terminal. Le statut inconnu reste inconnu jusqu à la réception d un accusé ; il ne s agit pas d une livraison implicite. Les semaines de facturation qui masquent l inconnu dans le succès provoquent des conflits sur la part non livrée.

Réconciliez les webhooks et le grand livre sur la même base

La réconciliation entre l audit webhook et l export du grand livre permet de prouver que le rapport reflète la réalité. Les journaux webhooks quotidiens, les états DLR et les lignes du grand livre prépayé doivent raconter la même histoire. Si les webhooks indiquent un échec alors que le rapport affiche un succès, le rapport est erroné : corrigez l export, ne modifiez pas le solde du portefeuille.

Refusez les semaines de facturation basées sur les soumissions

Toute clôture qui facture ou célèbre des résultats sur la base des seules soumissions doit être bloquée. Réécrivez le rapport pour que la finance s appuie sur les parts de livraisons et d inconnus. Si un contrat partenaire mentionne encore 'soumissions API réussies', traduisez ces termes en notes DLR sans altérer la structure des colonnes.

Voies opérationnelles associées

• Semaine de facturation DLR : la part inconnue n est pas livrée
• Réconciliation des journaux Webhook quotidiens avec les soldes prépayés
• Semaine de facturation SMS : quand les mathématiques des segments et la factu…

Commencez avec IOSOR

Ouvrez le pack de rapports de la semaine dans la console IOSOR et vérifiez que chaque KPI d’en-tête s’appuie sur les reçus DLR — delivered, failed et unknown — pas sur les submits ni les accepts API. Si un graphique traite encore le submit comme un succès, renommez-le ou retirez-le avant la clôture finance. Exportez une fois et partagez les mêmes colonnes de reçu entre produit et finance.

À retenir — IOSOR

Les rapports se ferment sur les reçus DLR : delivered, failed et unknown — pas sur les submits. Le submit mesure le débit, jamais la vérité de livraison ni un argument de facture.

À faire : un schéma d’export ancré aux champs de reçu. À ne pas faire : le produit célèbre les accepts pendant que la finance discute un failed DLR.