Retour au blog SMS wholesale

Rapprochement de facturation A2P SMS : CDR, DLR et factures sans faux raccourcis

Un cadre opérationnel pour rapprocher les enregistrements internes, les acceptations techniques, les CDR, les DLR et les factures sans supposer qu’un signal technique décide à lui seul de la facturation.

Équipe opérationnelle examinant des enregistrements CDR, des statuts SMS et des écarts de facturation A2P

Quel problème résout le rapprochement de facturation A2P SMS

Le rapprochement de facturation A2P SMS permet de vérifier si les frais d’un fournisseur peuvent être expliqués par des éléments de preuve opérationnels traçables. Son objectif n’est pas de transformer une métrique de livraison en une décision financière automatique, mais de comparer des ensembles d’enregistrements, d’identifier les écarts et d’appliquer la règle commerciale convenue pour la route et le fournisseur.

Cette fonction doit impliquer les opérations, le wholesale, la gestion des fournisseurs et la finance. La finance peut contrôler les montants, les périodes et les validations, mais elle ne dispose généralement pas seule du contexte nécessaire pour interpréter les identifiants, les tentatives répétées, les routes, les segments, les codes d’erreur ou les statuts tardifs.

Le principe central est simple : l’acceptation technique, le CDR du fournisseur, le DLR et la réception constatée sur le terminal sont des signaux distincts. Un rapprochement solide préserve cette distinction au lieu de résumer tous les événements sous une seule étiquette telle que « livré » ou « facturable ».

  • N’utilisez pas un DLR comme règle universelle de facturation.
  • Ne considérez pas l’absence de DLR comme une preuve automatique d’échec ou de non-facturabilité.
  • Ne discutez pas les écarts uniquement à partir de totaux agrégés lorsque des identifiants de message existent.
  • Appliquez la règle contractuelle documentée avant de calculer des ajustements ou d’accepter des frais.
Quel problème résout le rapprochement de facturation A2P SMS

Les quatre sources de preuve à rapprocher

Un rapprochement reproductible part de sources distinctes. Chaque source répond à une question différente et présente des limites différentes. L’enregistrement interne confirme ce que votre plateforme a tenté d’envoyer ; la réponse d’acceptation indique comment le fournisseur ou le SMSC a répondu à l’envoi ; le CDR étaye l’ensemble déclaré par le fournisseur ; et le DLR apporte un statut technique ultérieur lorsqu’il a été demandé et reçu.

Dans SMPP, submit_sm_resp est la réponse à submit_sm et peut inclure l’identifiant de message attribué par le SMSC. Les accusés de réception sont retournés ultérieurement via deliver_sm ou data_sm. Cette séquence est importante : recevoir une acceptation ne revient pas à disposer d’un statut final, et disposer d’un statut final ne remplace pas la règle de facturation convenue.

  • Enregistrement interne d’envoi : ID propre, destination d’origine, payload ou référence de contenu, expéditeur, route prévue, horodatage et résultat local.
  • Réponse d’acceptation : code de réponse, ID du fournisseur ou du SMSC lorsqu’il existe, et horodatage de réception.
  • CDR ou extrait équivalent : enregistrements, champs, période et critères fournis par le fournisseur.
  • DLR ou statut : valeur d’origine, statut normalisé, code d’erreur, preuve réseau disponible et horodatages de soumission et de finalisation lorsqu’ils sont reçus.
Les quatre sources de preuve à rapprocher

DLR, acceptation et réception : ce que prouve chaque signal

L’acceptation technique démontre que le système destinataire a accepté ou répondu à la tentative de soumission conformément à l’interface utilisée. Elle ne démontre pas à elle seule la livraison au terminal ni la lecture par une personne. La portée exacte de cette acceptation doit être interprétée selon l’intégration et l’accord opérationnel applicables.

Un DLR représente un événement ultérieur communiqué par la chaîne de messagerie. La norme SMPP prévoit des statuts et des formats d’accusé, y compris des formats propres au fournisseur. En outre, la spécification technique distingue les rapports émis par le Service Centre de ceux émis par la station mobile : un rapport du Service Centre peut confirmer la réception par ce centre, tandis qu’un rapport émis par la station mobile confirme la réception par l’équipement, et non une lecture humaine.

La réception constatée sur un terminal peut constituer une preuve supplémentaire lors de tests contrôlés, mais elle ne doit pas non plus être automatiquement assimilée à une lecture, un consentement, une identité ou une obligation de facturation. La base de facturation n’est pas déterminée par la sémantique générale d’un DLR : elle doit être expressément définie dans le contrat ou l’accord opérationnel pour chaque fournisseur et chaque route.

  • Acceptation : preuve d’une réponse à la soumission technique du message.
  • DLR : preuve d’un statut déclaré ; conservez sa valeur d’origine et son contexte.
  • Réception sur le terminal : peut démontrer une réception technique lors de tests, mais pas une lecture humaine.
  • Facturation : résultat d’une règle commerciale documentée, non d’une étiquette technique isolée.

Définir l’unité rapprochable avant toute comparaison

L’objet du rapprochement doit être défini avant le démarrage du trafic ou avant le prochain cycle de facturation. Si une partie compare des messages logiques et l’autre des segments techniques, un écart peut être apparent plutôt qu’être une erreur de facturation. La concaténation exige une décision explicite sur l’unité de comparaison et de règlement.

SMPP prévoit des champs permettant d’identifier les messages concaténés, notamment un numéro de référence, le nombre total de segments et la séquence de chaque segment. Conservez ces champs lorsqu’ils sont disponibles et reliez chaque segment au message logique correspondant sans substituer l’un à l’autre.

La corrélation ne doit pas dépendre uniquement de l’heure ni de l’ordre d’arrivée. SMPP autorise des réponses hors séquence. Par conséquent, l’identifiant interne et l’identifiant renvoyé par le fournisseur ou le SMSC doivent être les clés principales lorsqu’ils existent, complétés par des attributs additionnels pour résoudre les cas incomplets.

  • ID interne immuable de la tentative d’envoi.
  • ID attribué par le fournisseur ou le SMSC, lorsqu’il est reçu.
  • Destination d’origine et destination normalisée conformément à une politique documentée.
  • Horodatage de l’envoi interne, de l’acceptation, de la soumission fournisseur et du statut final, avec fuseau horaire et précision.
  • Fournisseur, route ou référence commerciale applicable au moment de l’envoi.
  • Expéditeur, type de trafic et référence de contenu lorsque cela est nécessaire à l’enquête.
  • Données de segmentation et relation avec le message logique.
  • Statut d’origine, code d’erreur et champs de preuve réseau disponibles.

Convenir des règles de facturation et de l’échange de données

La spécification SMPP définit des mécanismes techniques d’envoi, de réponses, d’identifiants et de statuts, mais elle ne précise pas quel événement est facturable. Chaque relation avec un fournisseur doit donc disposer d’une règle commerciale et opérationnelle indiquant l’unité facturée, l’événement de référence et le traitement des exceptions.

La règle doit être associée à la route ou au produit applicable. Si une organisation utilise plusieurs fournisseurs ou routes, elle ne doit pas transposer sans validation une politique de rapprochement d’une relation à une autre. Il est également recommandé de versionner les règles afin de pouvoir appliquer celle qui était en vigueur au moment du trafic.

L’accord d’échange de données doit éviter les ambiguïtés qui apparaissent à la clôture : sémantique des colonnes, format des identifiants, fuseau horaire, période de coupure, fréquence de livraison des CDR et délai applicable aux statuts tardifs.

  • Unité de facturation : segment, message logique ou autre unité expressément convenue.
  • Événement de référence pour la facturation et traitement des rejets, tentatives répétées et ajustements.
  • Schéma CDR, types de fichiers ou interface, encodage et sémantique de chaque champ.
  • Clés de corrélation et règles de priorité entre identifiants.
  • Fuseau horaire, précision temporelle, période de coupure et date de disponibilité du CDR.
  • Fenêtre applicable aux DLR tardifs et procédure de réouverture ou d’ajustement.
  • Responsables de l’enquête, de l’approbation, de la contestation et de l’enregistrement des résolutions.

Construire un modèle de statuts utile au rapprochement

Les statuts doivent être conservés à deux niveaux. Le premier est la valeur d’origine reçue du fournisseur, accompagnée du code d’erreur et de toute preuve supplémentaire disponible. Le second est une catégorie interne définie pour opérer le rapprochement. Cette normalisation permet de comparer les fournisseurs sans détruire les informations nécessaires à l’examen de cas précis.

Évitez d’utiliser une catégorie interne comme s’il s’agissait d’une déclaration universelle sur la livraison ou la facturation. Un statut technique peut être utile pour classer un dossier, mais la décision de facturer, de créditer ou d’enquêter dépend de la politique convenue et des preuves disponibles.

L’absence de DLR doit être enregistrée comme une absence de preuve de statut dans les conditions concrètes de l’envoi. Dans SMPP, le retour des accusés dépend de ce qui a été demandé par registered_delivery, et le contenu peut varier selon le fournisseur. L’absence de DLR n’équivaut donc pas automatiquement à une non-livraison ni à un ajustement automatique.

  • Accepté techniquement.
  • Rejeté dans la réponse de soumission, si cet événement est enregistré.
  • Statut final déclaré par le fournisseur ou le SMSC.
  • Statut intermédiaire ou non final, s’il est reçu.
  • Aucun DLR disponible dans la fenêtre convenue.
  • Corrélation insuffisante.
  • En attente d’enquête ou de résolution commerciale.

Processus étape par étape pour rapprocher CDR, statuts et factures

Le processus doit être exécuté sur une copie de travail, sans modifier les enregistrements d’origine. Les événements internes, les réponses d’acceptation, les DLR et le CDR du fournisseur sont d’abord ingérés. Le schéma est ensuite validé, les fichiers ou extractions reçus sont enregistrés et leur provenance est préservée.

La normalisation est appliquée de manière versionnée : destinations, fuseaux horaires, noms de statuts et formats d’identifiant. La corrélation est ensuite effectuée en donnant priorité aux clés fortes, notamment l’ID interne et l’ID fournisseur. Les appariements fondés sur des attributs secondaires doivent être signalés comme tels et pouvoir être revus.

Ce n’est qu’après avoir identifié les ensembles comparables que la règle commerciale en vigueur doit être appliquée. Le résultat ne se limite pas à un solde : il doit inclure les écarts classifiés, les preuves disponibles, le responsable et l’étape suivante.

  • 1. Clôturez la période de référence selon le calendrier convenu.
  • 2. Ingérez et conservez les sources sans modification : événements internes, réponses, DLR, CDR et facture.
  • 3. Validez l’intégrité : champs obligatoires, doublons de fichiers, fuseau horaire et période couverte.
  • 4. Normalisez de manière versionnée les identifiants, destinations, horodatages et statuts.
  • 5. Corrélez par ID ; utilisez les attributs secondaires uniquement comme appui et indiquez le niveau de confiance.
  • 6. Regroupez par fournisseur, route, période et unité de facturation convenue.
  • 7. Classez les écarts et appliquez la politique contractuelle.
  • 8. Effectuez la revue opérationnelle, l’approbation financière et l’enregistrement des ajustements ou contestations.

Écarts fréquents et traitement approprié

Les enregistrements en double exigent de distinguer un événement répété dans l’export, une retransmission légitime et deux tentatives distinctes. Ne supprimez pas les doublons uniquement parce qu’ils partagent une destination ou un contenu. Examinez les identifiants, les horodatages, la route et la relation entre la soumission d’origine et toute nouvelle tentative.

La concaténation peut produire des écarts lorsqu’une partie comptabilise les segments et l’autre regroupe par message logique. La solution n’est pas de forcer une équivalence a posteriori, mais de reconstruire la relation entre les segments et le message logique, puis d’appliquer l’unité définie dans l’accord.

Les écarts temporels peuvent provenir du fait que les événements surviennent à des moments différents : envoi interne, acceptation, soumission, statut final et coupure de facturation. Les DLR finaux peuvent arriver après la clôture initiale. Il est nécessaire de séparer la période de trafic de la période de disponibilité des preuves et d’utiliser la fenêtre d’ajustement convenue.

Les rejets, les statuts tardifs et les enregistrements manquants doivent être conservés comme des catégories distinctes. Un enregistrement absent du CDR n’est pas identique à un rejet technique ; un DLR tardif n’est pas identique à un DLR inexistant ; et un statut déclaré ne remplace pas l’enregistrement facturé du fournisseur.

  • Doublons : vérifiez l’identité de l’événement, les tentatives répétées et la répétition des exports.
  • Concaténation : comparez l’unité technique et l’unité commerciale convenue.
  • Horodatages : conservez l’événement, le fuseau horaire, la précision et la date de réception de la donnée.
  • Statuts tardifs : appliquez la fenêtre convenue avant de clôturer définitivement l’enquête.
  • Rejets : distinguez le rejet de soumission d’un statut final ultérieur.
  • Enregistrements manquants : ouvrez une exception avec des clés de recherche et une période vérifiable.
FAQ

Questions fréquentes

Un DLR indiquant livré doit-il décider automatiquement si un SMS A2P est facturable ?

Non. Un DLR est un signal technique relatif à un statut déclaré. La règle de facturation doit être définie dans le contrat ou l’accord opérationnel applicable à ce fournisseur et à cette route. Conservez le DLR comme preuve, avec le CDR, l’acceptation et les identifiants de corrélation.

L’absence de DLR prouve-t-elle qu’un SMS n’a pas été livré ?

Non. La réception des DLR dépend notamment de la demande du type d’accusé correspondant et de la manière dont le fournisseur met en œuvre et transmet ces statuts. Elle doit être classée comme une absence de preuve de statut dans la fenêtre convenue, et non comme une preuve automatique d’échec.

Quels identifiants sont nécessaires pour rapprocher des messages SMS ?

Conservez au minimum un identifiant interne immuable et l’identifiant attribué par le fournisseur ou le SMSC lorsqu’il existe. Ajoutez la destination normalisée, les horodatages, le fournisseur, la route, l’expéditeur, la segmentation et le statut d’origine afin de faciliter l’enquête.

Pourquoi ne suffit-il pas de comparer les totaux d’une facture et d’une plateforme ?

Les agrégats peuvent masquer des doublons, des messages concaténés, des tentatives répétées, des écarts de période, des statuts tardifs ou des échecs de corrélation. La comparaison par message ou par unité technique convenue permet d’attribuer l’écart à des preuves vérifiables.

Comment traiter un SMS concaténé dans le rapprochement ?

Il faut définir expressément si la comparaison et la facturation sont effectuées par segment, par message logique ou selon une autre unité contractuelle. Conservez les références de concaténation et reliez chaque segment au message logique sans supposer que ces deux unités sont équivalentes.

Que doit inclure un rapport de rapprochement A2P SMS ?

Il doit distinguer le volume envoyé en interne, les acceptations techniques, les CDR du fournisseur, les statuts finaux disponibles, les enregistrements sans corrélation, les écarts classifiés, les ajustements appliqués et le solde en attente d’enquête. Il doit également indiquer la période, le fuseau horaire, la règle appliquée et la version de la normalisation.

Sources consultées

  1. SMPP Protocol Specification v3.4, Issue 1.2SMPP Developers Forum
  2. 3GPP TS 23.040: Technical realization of the Short Message Service (SMS)3GPP
  3. ETSI TS 123 040 V3.4.1: Technical realization of the Short Message Service (SMS)ETSI / 3GPP
  4. Recommendation ITU-T E.164: The international public telecommunication numbering planInternational Telecommunication Union
  5. How Short Message Service (SMS) worksAmazon Web Services