Riconciliazione della fatturazione A2P SMS: CDR, DLR e fatture senza false equivalenze

Quale problema risolve la riconciliazione della fatturazione A2P SMS

La riconciliazione della fatturazione A2P SMS consente di verificare se gli addebiti di un fornitore siano spiegabili mediante evidenze operative tracciabili. Il suo obiettivo non è trasformare una metrica di consegna in una decisione finanziaria automatica, bensì confrontare insiemi di registri, individuare differenze e applicare la regola commerciale concordata per la rotta e il fornitore.

Questa funzione deve coinvolgere operation, wholesale, gestione dei fornitori e finanza. La finanza può controllare importi, periodi e approvazioni, ma in genere non dispone da sola del contesto necessario per interpretare identificatori, ritentativi, rotte, segmenti, codici di errore o stati tardivi.

Il principio centrale è semplice: accettazione tecnica, CDR del fornitore, DLR e ricezione osservata sul terminale sono segnali diversi. Una riconciliazione solida conserva questa distinzione, anziché riassumere tutti gli eventi sotto un'unica etichetta di “consegnato” o “fatturabile”.

• Non utilizzare un DLR come regola universale di addebito.
• Non considerare l'assenza di DLR come prova automatica di errore o di non fatturabilità.
• Non discutere le differenze solo sulla base di totali aggregati quando sono disponibili identificatori di messaggio.
• Applicare la regola contrattuale documentata prima di calcolare rettifiche o accettare addebiti.

Le quattro fonti di evidenza da confrontare

Una riconciliazione riproducibile parte da registri sorgente separati. Ogni fonte risponde a una domanda diversa e presenta limiti diversi. Il registro interno conferma ciò che la piattaforma ha tentato di inviare; la risposta di accettazione indica come il fornitore o l'SMSC ha risposto all'invio; il CDR supporta l'insieme riportato dal fornitore; e il DLR fornisce uno stato tecnico successivo quando è stato richiesto e ricevuto.

In SMPP, submit_sm_resp è la risposta al submit_sm e può includere l'identificatore di messaggio assegnato dall'SMSC. Le ricevute di consegna vengono restituite successivamente tramite deliver_sm o data_sm. Questa sequenza è importante: ricevere un'accettazione non equivale a disporre di uno stato finale, e disporre di uno stato finale non sostituisce la regola di fatturazione concordata.

• Registro interno di invio: ID proprietario, destinazione originale, payload o riferimento al contenuto, mittente, rotta prevista, timestamp e risultato locale.
• Risposta di accettazione: codice di risposta, ID del fornitore o dell'SMSC quando disponibile e timestamp di ricezione.
• CDR o estratto equivalente: record, campi, periodo e criteri forniti dal fornitore.
• DLR o stato: valore originale, stato normalizzato, codice di errore, evidenza di rete disponibile e timestamp di submit e completamento quando ricevuti.

DLR, accettazione e ricezione: cosa dimostra ogni segnale

L'accettazione tecnica dimostra che il sistema ricevente ha accettato o risposto al tentativo di submit secondo l'interfaccia utilizzata. Non dimostra di per sé la consegna al dispositivo né la lettura da parte di una persona. La portata esatta di questa accettazione deve essere interpretata in base all'integrazione e all'accordo operativo applicabile.

Un DLR rappresenta un evento successivo comunicato dalla catena di messaggistica. Lo standard SMPP contempla stati e formati di ricevuta, inclusi formati specifici del fornitore. Inoltre, la specifica tecnica distingue i rapporti emessi dal Service Centre da quelli emessi dalla stazione mobile: un rapporto del Service Centre può confermare la ricezione presso tale centro, mentre uno emesso dalla stazione mobile conferma la ricezione da parte del dispositivo, non la lettura umana.

La ricezione osservata su un terminale può costituire un'evidenza aggiuntiva nei test controllati, ma non deve essere automaticamente confusa con lettura, consenso, identità o obbligo di addebito. La base di addebito non è determinata dalla semantica generale di un DLR: deve essere definita espressamente nel contratto o nell'accordo operativo per fornitore e rotta.

• Accettazione: evidenza di una risposta alla presentazione tecnica del messaggio.
• DLR: evidenza di uno stato riportato; conservarne il valore originale e il contesto.
• Ricezione sul terminale: può dimostrare la ricezione tecnica nei test, non la lettura umana.
• Addebito: risultato di una regola commerciale documentata, non di una singola etichetta tecnica.

Definire l'unità riconciliabile prima del confronto

L'oggetto della riconciliazione deve essere definito prima di avviare il traffico o prima del ciclo di fatturazione successivo. Se una parte confronta messaggi logici e l'altra segmenti tecnici, una discrepanza può essere apparente e non un errore di fatturazione. La concatenazione richiede una decisione esplicita sull'unità di confronto e regolamento.

SMPP prevede campi per identificare i messaggi concatenati, inclusi un numero di riferimento, il totale dei segmenti e la sequenza di ciascun segmento. Conservare questi campi quando disponibili e collegare ogni segmento al messaggio logico corrispondente senza sostituire l'uno con l'altro.

La correlazione non deve dipendere esclusivamente dall'orario né dall'ordine di arrivo. SMPP consente risposte fuori sequenza. Pertanto, l'identificatore interno e l'identificatore restituito dal fornitore o dall'SMSC devono essere le chiavi principali quando disponibili, con attributi complementari per risolvere i casi incompleti.

• ID interno immutabile del tentativo di invio.
• ID assegnato dal fornitore o dall'SMSC, quando ricevuto.
• Destinazione originale e destinazione normalizzata secondo una policy documentata.
• Timestamp di invio interno, accettazione, submit del fornitore e stato finale, con fuso orario e precisione.
• Fornitore, rotta o riferimento commerciale applicabile al momento dell'invio.
• Mittente, tipo di traffico e riferimento al contenuto quando necessario per l'indagine.
• Dati di segmentazione e relazione con il messaggio logico.
• Stato originale, codice di errore e campi di evidenza di rete disponibili.

Concordare le regole di addebito e lo scambio dei dati

La specifica SMPP definisce meccanismi tecnici per invio, risposte, identificatori e stati, ma non stabilisce quale evento sia fatturabile. Per questo, ogni relazione con un fornitore deve disporre di una regola commerciale e operativa che indichi quale sia l'unità fatturata, quale l'evento di riferimento e come vengano gestite le eccezioni.

La regola deve essere associata alla rotta o al prodotto applicabile. Se un'organizzazione utilizza più fornitori o rotte, non deve trasferire senza verifica una policy di riconciliazione da una relazione all'altra. È inoltre opportuno versionare le regole per poter applicare quella in vigore al momento del traffico.

L'accordo sullo scambio dei dati deve evitare le ambiguità che emergono alla chiusura: semantica delle colonne, formato degli identificatori, fuso orario, periodo di cut-off, frequenza di consegna dei CDR e termine per gli stati tardivi.

• Unità di addebito: segmento, messaggio logico o altra unità espressamente concordata.
• Evento di riferimento per l'addebito e trattamento di rifiuti, ritentativi e rettifiche.
• Schema CDR, tipi di file o interfaccia, codifica e semantica di ciascun campo.
• Chiavi di correlazione e regole di priorità tra identificatori.
• Fuso orario, precisione temporale, periodo di cut-off e data di disponibilità del CDR.
• Finestra per DLR tardivi e procedura di riapertura o rettifica.
• Responsabili dell'indagine, dell'approvazione, della contestazione e della registrazione delle risoluzioni.

Costruire un modello di stati utile alla riconciliazione

Gli stati devono essere conservati su due livelli. Il primo è il valore originale ricevuto dal fornitore, insieme al codice di errore e a qualsiasi evidenza aggiuntiva disponibile. Il secondo è una categoria interna definita per gestire la riconciliazione. Questa normalizzazione consente di confrontare i fornitori senza distruggere le informazioni necessarie per esaminare casi specifici.

Evitare di utilizzare una categoria interna come se fosse una dichiarazione universale sulla consegna o sulla fatturazione. Uno stato tecnico può essere utile per classificare un caso, ma la decisione di addebito, accredito o indagine dipende dalla policy concordata e dalle evidenze disponibili.

L'assenza di DLR deve essere indicata come assenza di evidenza di stato nelle condizioni concrete dell'invio. In SMPP, la restituzione delle ricevute dipende da quanto richiesto tramite registered_delivery e il contenuto può variare a seconda del fornitore. Pertanto, l'assenza di DLR non equivale automaticamente a mancata consegna né a una rettifica automatica.

• Accettato tecnicamente.
• Rifiutato nella risposta di submit, se l'evento viene registrato.
• Stato finale riportato dal fornitore o dall'SMSC.
• Stato intermedio o non finale, se ricevuto.
• Nessun DLR disponibile entro la finestra concordata.
• Correlazione insufficiente.
• In attesa di indagine o risoluzione commerciale.

Processo passo passo per riconciliare CDR, stati e fatture

Il processo deve essere eseguito su una copia di lavoro, senza modificare i record originali. Per prima cosa vengono acquisiti gli eventi interni, le risposte di accettazione, i DLR e il CDR del fornitore. Successivamente si valida lo schema, si registrano i file o le estrazioni ricevute e se ne conserva la provenienza.

La normalizzazione viene applicata in modo versionato: destinazioni, fusi orari, nomi degli stati e formati degli identificatori. Si procede quindi alla correlazione, dando priorità alle chiavi forti, in particolare l'ID interno e l'ID del fornitore. Gli abbinamenti basati su attributi secondari devono essere contrassegnati come tali e verificabili.

Solo dopo aver identificato gli insiemi confrontabili deve essere applicata la regola commerciale in vigore. Il risultato non è soltanto un saldo: deve includere le differenze classificate, le evidenze disponibili, il responsabile e il passaggio successivo.

• 1. Chiudere il periodo di riferimento secondo il calendario concordato.
• 2. Acquisire e conservare le fonti senza modificarle: eventi interni, risposte, DLR, CDR e fattura.
• 3. Validare l'integrità: campi obbligatori, duplicati di file, fuso orario e periodo coperto.
• 4. Normalizzare in modo versionato identificatori, destinazioni, timestamp e stati.
• 5. Correlare mediante ID; utilizzare attributi secondari solo come supporto e indicare il livello di confidenza.
• 6. Raggruppare per fornitore, rotta, periodo e unità di addebito concordata.
• 7. Classificare le differenze e applicare la policy contrattuale.
• 8. Effettuare la revisione operativa, l'approvazione finanziaria e registrare rettifiche o contestazioni.

Differenze ricorrenti e come gestirle

I record duplicati richiedono di distinguere tra un evento ripetuto nell'esportazione, un reinvio legittimo e due tentativi diversi. Non eliminare duplicati solo perché condividono destinazione o contenuto. Esaminare gli identificatori, i timestamp, la rotta e la relazione tra il submit originale e qualsiasi ritentativo.

La concatenazione può produrre differenze quando una parte conteggia i segmenti e l'altra raggruppa per messaggio logico. La soluzione non è forzare un'equivalenza successiva, ma ricostruire la relazione tra segmenti e messaggio logico e applicare l'unità definita nell'accordo.

Le differenze temporali possono sorgere perché gli eventi hanno momenti diversi: invio interno, accettazione, submit, stato finale e cut-off di fatturazione. I DLR finali possono arrivare dopo la chiusura iniziale. È necessario separare il periodo di traffico dal periodo di disponibilità delle evidenze e utilizzare la finestra di rettifica concordata.

Rifiuti, stati tardivi e record mancanti devono essere mantenuti come categorie distinte. Un record assente dal CDR non è identico a un rifiuto tecnico; un DLR tardivo non equivale a un DLR inesistente; e uno stato riportato non sostituisce il record fatturato dal fornitore.

• Duplicati: verificare l'identità dell'evento, i ritentativi e la ripetizione delle esportazioni.
• Concatenazione: confrontare l'unità tecnica e l'unità commerciale concordata.
• Timestamp: conservare evento, fuso orario, precisione e data di ricezione del dato.
• Stati tardivi: applicare la finestra concordata prima di chiudere definitivamente l'indagine.
• Rifiuti: distinguere il rifiuto del submit da uno stato finale successivo.
• Record mancanti: aprire un'eccezione con chiavi di ricerca e periodo verificabile.