Zurück zum Blog Wholesale SMS

A2P-SMS-Abrechnungsabgleich: CDR, DLR und Rechnungen ohne falsche Gleichsetzungen

Ein operativer Rahmen zum Abgleich interner Datensätze, technischer Annahmen, CDR, DLR und Rechnungen, ohne anzunehmen, dass ein technisches Signal allein die Abrechnung entscheidet.

Operatives Team prüft CDR-Datensätze, SMS-Status und Unterschiede in der A2P-Abrechnung

Welches Problem der A2P-SMS-Abrechnungsabgleich löst

Der A2P-SMS-Abrechnungsabgleich ermöglicht die Prüfung, ob die Gebühren eines Anbieters durch nachvollziehbare operative Nachweise erklärt werden können. Sein Ziel ist nicht, eine Zustellmetrik in eine automatische Finanzentscheidung umzuwandeln, sondern Datensatzmengen zu vergleichen, Abweichungen zu finden und die für Route und Anbieter vereinbarte Geschäftsregel anzuwenden.

Diese Funktion sollte Betrieb, Wholesale, Anbietermanagement und Finanzen einbeziehen. Die Finanzabteilung kann Beträge, Zeiträume und Freigaben kontrollieren, verfügt jedoch normalerweise nicht allein über den Kontext, der zur Interpretation von Kennungen, Wiederholungsversuchen, Routen, Segmenten, Fehlercodes oder verspäteten Statusmeldungen erforderlich ist.

Das zentrale Prinzip ist einfach: Technische Annahme, Anbieter-CDR, DLR und beobachteter Empfang auf dem Endgerät sind unterschiedliche Signale. Ein belastbarer Abgleich bewahrt diesen Unterschied, statt alle Ereignisse unter einer einzigen Kennzeichnung wie „zugestellt“ oder „abrechenbar“ zusammenzufassen.

  • Verwenden Sie einen DLR nicht als universelle Abrechnungsregel.
  • Behandeln Sie das Fehlen eines DLR nicht als automatischen Beweis für einen Fehler oder fehlende Abrechenbarkeit.
  • Diskutieren Sie Abweichungen nicht ausschließlich anhand aggregierter Summen, wenn Nachrichtenkennungen verfügbar sind.
  • Wenden Sie die dokumentierte Vertragsregel an, bevor Sie Anpassungen berechnen oder Gebühren akzeptieren.
Welches Problem der A2P-SMS-Abrechnungsabgleich löst

Die vier abzugleichenden Nachweisquellen

Ein reproduzierbarer Abgleich beginnt mit getrennten Quelldatensätzen. Jede Quelle beantwortet eine andere Frage und hat andere Einschränkungen. Der interne Datensatz bestätigt, was Ihre Plattform zu senden versucht hat; die Annahmeantwort zeigt, wie der Anbieter oder SMSC auf die Übermittlung reagiert hat; der CDR bildet die vom Anbieter gemeldete Menge ab; und der DLR liefert einen späteren technischen Status, wenn er angefordert und empfangen wurde.

In SMPP ist submit_sm_resp die Antwort auf submit_sm und kann die vom SMSC zugewiesene Nachrichtenkennung enthalten. Zustellberichte werden später über deliver_sm oder data_sm zurückgegeben. Diese Abfolge ist wichtig: Der Erhalt einer Annahme ist nicht gleichbedeutend mit dem Vorliegen eines Endstatus, und ein Endstatus ersetzt nicht die vereinbarte Abrechnungsregel.

  • Interner Versanddatensatz: eigene ID, ursprüngliches Ziel, Payload oder Inhaltsreferenz, Absender, vorgesehene Route, Zeitstempel und lokales Ergebnis.
  • Annahmeantwort: Antwortcode, Anbieter- oder SMSC-ID, sofern vorhanden, sowie Empfangszeitstempel.
  • CDR oder gleichwertiger Auszug: vom Anbieter bereitgestellte Datensätze, Felder, Zeitraum und Kriterien.
  • DLR oder Status: Originalwert, normalisierter Status, Fehlercode, verfügbare Netzwerknachweise sowie Zeitstempel für Submit und Abschluss, wenn empfangen.
Die vier abzugleichenden Nachweisquellen

DLR, Annahme und Empfang: Was jedes Signal belegt

Die technische Annahme belegt, dass das empfangende System den Submit-Versuch gemäß der verwendeten Schnittstelle angenommen oder beantwortet hat. Sie belegt für sich allein weder die Zustellung an ein Gerät noch das Lesen durch eine Person. Der genaue Umfang dieser Annahme muss gemäß der Integration und der geltenden Betriebsvereinbarung ausgelegt werden.

Ein DLR stellt ein späteres Ereignis dar, das durch die Nachrichtenkette übermittelt wird. Der SMPP-Standard sieht Status und Belegformate vor, einschließlich anbieterspezifischer Formate. Zudem unterscheidet die technische Spezifikation Berichte, die vom Service Centre ausgegeben werden, von solchen der Mobilstation: Ein Bericht des Service Centre kann den Empfang durch dieses Zentrum bestätigen, während ein von der Mobilstation ausgegebener Bericht den Empfang durch das Gerät bestätigt, nicht jedoch das menschliche Lesen.

Ein auf einem Endgerät beobachteter Empfang kann bei kontrollierten Tests einen zusätzlichen Nachweis darstellen, darf jedoch ebenfalls nicht automatisch mit Lesen, Einwilligung, Identität oder einer Zahlungspflicht gleichgesetzt werden. Die Abrechnungsgrundlage wird nicht durch die allgemeine Semantik eines DLR bestimmt: Sie muss im Vertrag oder in der Betriebsvereinbarung für jeden Anbieter und jede Route ausdrücklich definiert sein.

  • Annahme: Nachweis einer Antwort auf die technische Einreichung der Nachricht.
  • DLR: Nachweis eines gemeldeten Status; bewahren Sie Originalwert und Kontext auf.
  • Empfang auf dem Endgerät: Kann in Tests den technischen Empfang belegen, nicht das menschliche Lesen.
  • Abrechnung: Ergebnis einer dokumentierten Geschäftsregel, nicht einer isolierten technischen Kennzeichnung.

Die abgleichbare Einheit vor dem Vergleich definieren

Das Abgleichobjekt muss vor Beginn des Verkehrs oder vor dem nächsten Abrechnungszyklus festgelegt werden. Wenn eine Partei logische Nachrichten und die andere technische Segmente vergleicht, kann eine Abweichung lediglich scheinbar sein und keinen Abrechnungsfehler darstellen. Verkettung erfordert eine ausdrückliche Entscheidung über die Vergleichs- und Abrechnungseinheit.

SMPP sieht Felder zur Identifikation verketteter Nachrichten vor, darunter eine Referenznummer, die Gesamtzahl der Segmente und die Reihenfolge jedes Segments. Bewahren Sie diese Felder auf, wenn sie verfügbar sind, und verknüpfen Sie jedes Segment mit der entsprechenden logischen Nachricht, ohne eines durch das andere zu ersetzen.

Die Korrelation sollte nicht ausschließlich von Uhrzeit oder Eingangsreihenfolge abhängen. SMPP erlaubt Antworten außerhalb der Reihenfolge. Deshalb sollten die interne Kennung und die vom Anbieter oder SMSC zurückgegebene Kennung, sofern vorhanden, die primären Schlüssel sein; ergänzende Attribute dienen zur Auflösung unvollständiger Fälle.

  • Unveränderliche interne ID des Versandversuchs.
  • Vom Anbieter oder SMSC zugewiesene ID, sofern empfangen.
  • Ursprüngliches Ziel und gemäß einer dokumentierten Richtlinie normalisiertes Ziel.
  • Zeitstempel für internen Versand, Annahme, Anbieter-Submit und Endstatus mit Zeitzone und Genauigkeit.
  • Zum Versandzeitpunkt geltender Anbieter, Route oder kommerzielle Referenz.
  • Absender, Verkehrsart und Inhaltsreferenz, wenn dies für Untersuchungen erforderlich ist.
  • Segmentierungsdaten und Beziehung zur logischen Nachricht.
  • Originalstatus, Fehlercode und verfügbare Netzwerknachweisfelder.

Abrechnungsregeln und Datenaustausch vereinbaren

Die SMPP-Spezifikation definiert technische Mechanismen für Versand, Antworten, Kennungen und Status, legt jedoch nicht fest, welches Ereignis abrechenbar ist. Daher sollte jede Beziehung mit einem Anbieter über eine geschäftliche und operative Regel verfügen, die die abgerechnete Einheit, das Referenzereignis und die Behandlung von Ausnahmen festlegt.

Die Regel muss mit der geltenden Route oder dem Produkt verknüpft sein. Nutzt eine Organisation mehrere Anbieter oder Routen, darf sie eine Abgleichrichtlinie nicht ohne Validierung von einer Beziehung auf eine andere übertragen. Es ist außerdem sinnvoll, Regeln zu versionieren, damit die zum Zeitpunkt des Verkehrs gültige Regel angewendet werden kann.

Die Datenaustauschvereinbarung sollte Mehrdeutigkeiten vermeiden, die beim Abschluss auftreten: Spaltensemantik, Kennungsformat, Zeitzone, Stichtagszeitraum, Häufigkeit der CDR-Bereitstellung und Frist für verspätete Statusmeldungen.

  • Abrechnungseinheit: Segment, logische Nachricht oder eine andere ausdrücklich vereinbarte Einheit.
  • Referenzereignis für Gebühren sowie Behandlung von Ablehnungen, Wiederholungsversuchen und Anpassungen.
  • CDR-Schema, Dateitypen oder Schnittstelle, Kodierung und Semantik jedes Felds.
  • Korrelationsschlüssel und Prioritätsregeln zwischen Kennungen.
  • Zeitzone, zeitliche Genauigkeit, Stichtagszeitraum und Datum der CDR-Verfügbarkeit.
  • Fenster für verspätete DLR sowie Verfahren zur Wiederaufnahme oder Anpassung.
  • Verantwortliche für Untersuchung, Freigabe, Beanstandung und Dokumentation von Lösungen.

Ein für den Abgleich nützliches Statusmodell aufbauen

Status sollten auf zwei Ebenen gespeichert werden. Die erste Ebene ist der vom Anbieter empfangene Originalwert zusammen mit dem Fehlercode und allen verfügbaren zusätzlichen Nachweisen. Die zweite Ebene ist eine interne Kategorie, die für den Abgleich definiert wird. Diese Normalisierung ermöglicht den Vergleich von Anbietern, ohne Informationen zu zerstören, die für die Prüfung einzelner Fälle erforderlich sind.

Vermeiden Sie es, eine interne Kategorie wie eine universelle Aussage über Zustellung oder Abrechnung zu verwenden. Ein technischer Status kann zur Klassifizierung eines Vorgangs nützlich sein, doch die Entscheidung über Gebühr, Gutschrift oder Untersuchung hängt von der vereinbarten Richtlinie und den verfügbaren Nachweisen ab.

Das Fehlen eines DLR sollte unter den konkreten Bedingungen des Versands als fehlender Statusnachweis erfasst werden. In SMPP hängt die Rückgabe von Zustellberichten davon ab, was über registered_delivery angefordert wurde, und der Inhalt kann je nach Anbieter variieren. Daher bedeutet das Fehlen eines DLR weder automatisch eine Nichtzustellung noch eine automatische Anpassung.

  • Technisch angenommen.
  • In der Submit-Antwort abgelehnt, sofern dieses Ereignis erfasst wird.
  • Vom Anbieter oder SMSC gemeldeter Endstatus.
  • Zwischenstatus oder nicht finaler Status, sofern empfangen.
  • Kein DLR innerhalb des vereinbarten Fensters verfügbar.
  • Keine ausreichende Korrelation.
  • Untersuchung oder kommerzielle Klärung ausstehend.

Schritt-für-Schritt-Prozess zum Abgleich von CDR, Status und Rechnungen

Der Prozess sollte auf einer Arbeitskopie ausgeführt werden, ohne die Originaldatensätze zu verändern. Zunächst werden interne Ereignisse, Annahmeantworten, DLR und der Anbieter-CDR eingelesen. Anschließend wird das Schema validiert, eingegangene Dateien oder Extraktionen werden protokolliert und ihre Herkunft wird bewahrt.

Die Normalisierung wird versioniert angewendet: Ziele, Zeitzonen, Statusbezeichnungen und Kennungsformate. Danach erfolgt die Korrelation mit Priorität für starke Schlüssel, insbesondere interne ID und Anbieter-ID. Abgleiche anhand sekundärer Attribute müssen entsprechend gekennzeichnet und überprüfbar sein.

Erst nachdem die vergleichbaren Mengen ermittelt wurden, darf die geltende Geschäftsregel angewendet werden. Das Ergebnis ist nicht nur ein Saldo: Es sollte die klassifizierten Abweichungen, die verfügbaren Nachweise, die verantwortliche Person und den nächsten Schritt enthalten.

  • 1. Schließen Sie den Referenzzeitraum gemäß dem vereinbarten Kalender.
  • 2. Lesen Sie unveränderte Quellen ein und bewahren Sie sie auf: interne Ereignisse, Antworten, DLR, CDR und Rechnung.
  • 3. Validieren Sie die Integrität: Pflichtfelder, doppelte Dateien, Zeitzone und abgedeckter Zeitraum.
  • 4. Führen Sie eine versionierte Normalisierung von Kennungen, Zielen, Zeitstempeln und Status durch.
  • 5. Korrelieren Sie über IDs; verwenden Sie sekundäre Attribute nur unterstützend und kennzeichnen Sie die Vertrauensstufe.
  • 6. Gruppieren Sie nach Anbieter, Route, Zeitraum und vereinbarter Abrechnungseinheit.
  • 7. Klassifizieren Sie Abweichungen und wenden Sie die Vertragsrichtlinie an.
  • 8. Führen Sie operative Prüfung, finanzielle Freigabe sowie Dokumentation von Anpassungen oder Beanstandungen durch.

Häufige Abweichungen und ihr Umgang

Bei doppelten Datensätzen muss zwischen einem wiederholten Ereignis im Export, einer legitimen erneuten Sendung und zwei unterschiedlichen Versuchen unterschieden werden. Entfernen Sie Duplikate nicht allein deshalb, weil Ziel oder Inhalt übereinstimmen. Prüfen Sie Kennungen, Zeitstempel, Route und die Beziehung zwischen dem ursprünglichen Submit und jedem Wiederholungsversuch.

Verkettung kann zu Abweichungen führen, wenn eine Seite Segmente zählt und die andere nach logischer Nachricht gruppiert. Die Lösung besteht nicht darin, nachträglich eine Gleichwertigkeit zu erzwingen, sondern die Beziehung zwischen Segmenten und logischer Nachricht zu rekonstruieren und die im Vertrag definierte Einheit anzuwenden.

Zeitliche Abweichungen können entstehen, weil Ereignisse unterschiedliche Zeitpunkte haben: interner Versand, Annahme, Submit, Endstatus und Abrechnungsstichtag. Finale DLR können nach dem ersten Abschluss eintreffen. Es ist notwendig, den Verkehrszeitraum vom Zeitraum der Nachweisverfügbarkeit zu trennen und das vereinbarte Anpassungsfenster zu nutzen.

Ablehnungen, verspätete Statusmeldungen und fehlende Datensätze müssen als unterschiedliche Kategorien erhalten bleiben. Ein im CDR fehlender Datensatz ist nicht identisch mit einer technischen Ablehnung; ein verspäteter DLR ist nicht gleich einem nicht vorhandenen DLR; und ein gemeldeter Status ersetzt nicht den abgerechneten Datensatz des Anbieters.

  • Duplikate: Prüfen Sie Ereignisidentität, Wiederholungsversuche und wiederholte Exporte.
  • Verkettung: Vergleichen Sie die technische Einheit mit der vereinbarten kommerziellen Einheit.
  • Zeitstempel: Bewahren Sie Ereignis, Zeitzone, Genauigkeit und Eingangsdatum der Daten auf.
  • Verspätete Statusmeldungen: Wenden Sie das vereinbarte Fenster an, bevor Sie die Untersuchung endgültig schließen.
  • Ablehnungen: Unterscheiden Sie die Submit-Ablehnung von einem späteren Endstatus.
  • Fehlende Datensätze: Eröffnen Sie eine Ausnahme mit Suchschlüsseln und einem überprüfbaren Zeitraum.
FAQ

Häufige Fragen

Sollte ein zugestellter DLR automatisch entscheiden, ob eine A2P-SMS abrechenbar ist?

Nein. Ein DLR ist ein technisches Signal über einen gemeldeten Status. Die Abrechnungsregel muss im Vertrag oder in der für diesen Anbieter und diese Route geltenden Betriebsvereinbarung festgelegt sein. Bewahren Sie den DLR zusammen mit CDR, Annahme und Korrelationskennungen als Nachweis auf.

Beweist das Fehlen eines DLR, dass eine SMS nicht zugestellt wurde?

Nein. Der Empfang von DLR hängt unter anderem davon ab, ob der entsprechende Belegtyp angefordert wurde und wie der Anbieter diese Statusmeldungen implementiert und bereitstellt. Er sollte als fehlender Statusnachweis innerhalb des vereinbarten Fensters klassifiziert werden, nicht als automatischer Fehlernachweis.

Welche Kennungen werden für den Abgleich von SMS-Nachrichten benötigt?

Bewahren Sie mindestens eine unveränderliche interne Kennung und die vom Anbieter oder SMSC zugewiesene Kennung auf, sofern vorhanden. Ergänzen Sie normalisiertes Ziel, Zeitstempel, Anbieter, Route, Absender, Segmentierung und Originalstatus, um die Untersuchung zu erleichtern.

Warum reicht es nicht aus, die Summen einer Rechnung und einer Plattform zu vergleichen?

Aggregierte Werte können Duplikate, verkettete Nachrichten, Wiederholungsversuche, Zeitraumabweichungen, verspätete Statusmeldungen oder Korrelationsfehler verdecken. Ein Vergleich je Nachricht oder je vereinbarter technischer Einheit ermöglicht es, die Abweichung überprüfbaren Nachweisen zuzuordnen.

Wie sollte eine verkettete SMS im Abgleich behandelt werden?

Es muss ausdrücklich definiert werden, ob Vergleich und Abrechnung je Segment, je logischer Nachricht oder je anderer Vertragseinheit erfolgen. Bewahren Sie Verkettungsreferenzen auf und verknüpfen Sie jedes Segment mit der logischen Nachricht, ohne anzunehmen, dass beide Einheiten gleichwertig sind.

Was sollte ein Bericht zum A2P-SMS-Abgleich enthalten?

Er sollte intern gesendetes Volumen, technische Annahmen, Anbieter-CDR, verfügbare Endstatus, nicht korrelierte Datensätze, klassifizierte Abweichungen, angewendete Anpassungen und den noch zu untersuchenden Saldo getrennt darstellen. Außerdem sollte er Zeitraum, Zeitzone, angewendete Regel und Version der Normalisierung angeben.

Verwendete Quellen

  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