Reconciliação operacional de SMS A2P: guia para resolver discrepâncias
Um processo de reconciliação útil separa solicitações, eventos de estado e dados de faturamento. Saiba como cruzar registros, classificar diferenças e documentar contestações sem presumir que um DLR comprova a receção no terminal.
O que o processo reconcilia e por que surgem diferenças
A reconciliação operacional compara três perspetivas que não descrevem necessariamente o mesmo facto: a solicitação registada pela sua plataforma, os eventos de estado comunicados pelo fornecedor e as linhas ou os totais apresentados para faturamento. O objetivo é explicar cada diferença com evidências e uma regra acordada, não forçar todos os sistemas a apresentar contagens idênticas.
Antes de comparar números, determine a que pergunta cada conjunto de dados responde. Uma solicitação aceite por uma interface não equivale, por si só, a uma mensagem entregue; um estado comunicado por um fornecedor é um evento do sistema desse fornecedor, e um valor faturado deve ser analisado de acordo com o contrato e os detalhes de faturamento aplicáveis. Não use um DLR como prova independente de receção no terminal nem como critério automático de cobrança.
- Defina o âmbito: contas, rotas, destinos, tráfego, moeda e período incluídos.
- Especifique se está a comparar solicitações, mensagens aceites, eventos, unidades faturáveis ou valores; não misture estas métricas.
- Documente separadamente as regras contratuais de faturamento e as regras de estado operacional.
Que fontes conservar e como avaliar a sua utilidade
Conserve uma cópia datada e inalterada dos registros usados na comparação. A lista exata depende das interfaces e dos formatos disponibilizados pelas partes; as evidências disponíveis não permitem prescrever campos universais de CDR ou DLR para todos os ambientes A2P.
Como mínimo operacional, faça um inventário dos dados que pode obter de cada sistema, de quem os gera, de quando são exportados e do período abrangido. Registe também a versão do ficheiro ou relatório e quaisquer transformações aplicadas antes da comparação. Se uma fonte não incluir um identificador de mensagem comum, anote essa limitação em vez de inferir uma correspondência segura.
- Plataforma: solicitações e respostas registadas, além dos identificadores efetivamente disponibilizados pelo sistema.
- Fornecedor: registros de tráfego e eventos de estado disponíveis, com as respetivas definições e marcas temporais declaradas.
- Faturamento: fatura e detalhes associados disponíveis, período de serviço e critério de cobrança acordado.
- Rejeições e novas tentativas: mantenha-as separadas quando o sistema as registar; não as converta automaticamente em mensagens faturáveis ou entregues.
- Rastreabilidade: guarde a data de extração, o fuso horário declarado, a origem, o responsável e os controlos de integridade do ficheiro.
Defina identificadores e regras de cruzamento antes de contar
Estabeleça uma hierarquia de correlação usando apenas identificadores presentes nos sistemas envolvidos. Um identificador próprio da plataforma e outro atribuído pelo fornecedor só podem referir-se ao mesmo fluxo se houver uma ligação documentada entre eles. Guarde essa ligação de forma explícita quando a integração a disponibilizar.
Se não houver uma chave comum, defina uma regra de comparação provisória e marque os resultados como correspondências prováveis, não como factos confirmados. A combinação de destinatário, hora ou outros atributos pode gerar colisões, e as evidências disponíveis não apresentam uma regra universal que garanta um cruzamento correto. Evite eliminar duplicados apenas porque dois registros são semelhantes.
- Dê prioridade a um identificador de mensagem partilhado ou a uma tabela de correspondências verificável.
- Mantenha separados o identificador da solicitação, o identificador atribuído pelo fornecedor e o identificador do evento, se existirem.
- Defina como tratar novas tentativas, partes de mensagens concatenadas e registros repetidos, de acordo com as definições reais dos seus sistemas e do contrato.
- Atribua um nível de confiança aos cruzamentos: confirmado, provável ou por resolver, e registe o motivo.
Alinhe períodos, fusos horários e eventos tardios
Antes de comparar, acordem um fuso horário de referência e conservem também o valor e o fuso horário originais de cada registro, quando disponíveis. Não converta marcas temporais sem documentar a transformação. Se os sistemas não indicarem o fuso horário, trate essa ausência como uma limitação a esclarecer com o responsável pela fonte.
Distinga a data do evento, a data do registro e o período de faturamento: podem ser diferentes. Defina uma janela de fecho e um procedimento de revisão posterior para eventos que surjam depois do corte, mas não imponha uma duração universal; esta deve ser acordada entre as partes e ajustada à latência observada e às condições contratuais.
- Especifique o início e o fim do período, a convenção dos limites e o fuso horário comum.
- Registe separadamente a data de envio, a do estado e a do lançamento ou da linha de faturamento, se cada fonte as disponibilizar.
- Marque as mensagens sem estado final como pendentes de revisão, não como entregues ou falhadas por defeito.
- Defina como reabrir um período quando chegam dados tardios e como documentar os ajustes posteriores.
Classifique discrepâncias sem presumir a causa
Uma taxonomia comum evita que cada equipa explique o mesmo caso de forma diferente. Comece por classificar o que é observável e mantenha a causa como hipótese até haver evidências suficientes. Por exemplo, uma diferença de quantidade não prova, por si só, um erro de faturamento: pode refletir períodos distintos, unidades de contagem diferentes, novas tentativas ou informações incompletas.
Mantenha o diagnóstico técnico separado da decisão financeira. A investigação pode determinar que registros coincidem e que eventos estão em falta; a aplicação de uma cobrança, crédito ou ajuste deve seguir o contrato e os controlos internos de aprovação.
- Ausência: registro presente numa fonte e não localizado noutra.
- Possível duplicado: várias linhas podem representar a mesma mensagem ou evento; verifique as chaves e as regras de cada sistema.
- Quantidade diferente: compare a definição da unidade, o âmbito, o período e o tratamento das novas tentativas.
- Estado incompatível: conserve o estado tal como foi comunicado por cada fonte e solicite a definição técnica aplicável.
- Período desalinhado: identifique diferenças de fuso horário, corte ou data usada para atribuir o registro.
- Sem estado final: mantenha o caso pendente e registe que evidências estão em falta.
Solicite evidências e documente a contestação
Abra uma contestação com um conjunto limitado de casos reproduzíveis, não apenas com um total agregado. Para cada caso, indique o período, a referência que permite localizá-lo, a diferença observada, a regra aplicada e a resposta concreta que pretende obter da outra parte.
Peça a definição dos estados e campos relevantes, os detalhes que sustentam a contagem ou a cobrança contestada e uma explicação das diferenças de período ou unidade. Um DLR é um estado comunicado no fluxo disponível; por si só, não constitui uma verificação independente de que a mensagem tenha sido apresentada ou recebida no terminal. Também não determina automaticamente se a cobrança é devida.
- Anexe referências que possam ser correlacionadas e uma amostra representativa de casos, protegendo os dados de acordo com as suas políticas e obrigações aplicáveis.
- Peça esclarecimentos sobre a origem do registro, o significado do estado e o período ao qual foi atribuído.
- Separe factos confirmados, inferências e questões em aberto.
- Registe a data de abertura, os interlocutores, as respostas, os ficheiros trocados e a conclusão de cada caso.
- Associe qualquer ajuste aprovado à contestação e à regra contratual que o sustenta.
Atribua responsáveis, prazos e aprovações
A reconciliação funciona melhor quando cada fase tem um responsável explícito. As operações podem preparar o cruzamento e explicar os eventos; a equipa técnica pode esclarecer identificadores ou exportações; as finanças podem validar valores e períodos; e o responsável comercial ou contratual pode interpretar as condições aplicáveis. Ajuste esta distribuição à sua organização e não presuma que uma única área pode validar todas as dimensões.
Acorde prazos internos para extrair dados, analisar diferenças e escalar casos; não há aqui um prazo universal sustentado por evidências. Defina também quem pode aprovar ajustes e quem confirma o fecho. O registo de auditoria deve permitir reconstituir que dados foram comparados, que regra foi usada, quem tomou a decisão e quando.
- Designe um responsável pela reconciliação e um substituto.
- Atribua responsáveis pelas fontes para resolver dúvidas sobre exportações e a semântica dos estados.
- Defina etapas de revisão e escalonamento de acordo com o contrato e os controlos internos.
- Exija a aprovação adequada antes de registar créditos, cobranças corrigidas ou outros ajustes.
- Conserve o resultado final e a respetiva justificação junto das evidências de origem.
Lista de verificação para implementar e rever o processo
Comece com um período de teste e um âmbito limitado. Valide se é possível obter as fontes, se as regras de cruzamento geram resultados verificáveis e se as exceções têm um responsável. Só amplie o processo quando conseguir explicar os seus limites e conservar evidências suficientes para repetir a análise.
Reveja periodicamente as definições e os acordos: alterações nas exportações, nos identificadores, nos critérios de faturamento ou nos calendários podem invalidar uma reconciliação anterior. Este guia ajuda a organizar o trabalho; não substitui as especificações técnicas das partes nem os termos contratuais.
- Está definido o que é reconciliado e que unidade é contada?
- As fontes originais e os respetivos metadados de extração são conservados?
- As chaves de cruzamento e as regras de eliminação de duplicados estão documentadas e podem ser reproduzidas?
- Os fusos horários, os cortes e os eventos tardios são distinguidos?
- Os casos sem estado final e as correspondências incertas continuam visíveis?
- Cada discrepância tem uma categoria, um responsável, evidências e uma resolução?
- As cobranças e os ajustes são decididos de acordo com o acordo aplicável, e não apenas com base num estado de entrega?
- Outra pessoa consegue rever o fecho com os mesmos registros e regras?
Perguntas frequentes
Um DLR comprova que a mensagem chegou ao terminal?
Não deve ser tratado como verificação independente de receção no terminal. É um estado comunicado no fluxo disponível, e o seu significado deve ser confirmado na documentação da fonte.
Um DLR determina automaticamente se uma mensagem é faturável?
Não. O faturamento deve ser analisado com base nos detalhes disponíveis e nas condições contratuais aplicáveis; um estado, por si só, não determina automaticamente a cobrança.
Que identificador devo usar para cruzar os registros?
Comece por usar um identificador partilhado ou uma correspondência documentada entre sistemas. Se não existir, defina uma regra provisória, marque a correspondência como incerta e não elimine duplicados apenas por semelhança.
O que faço com mensagens sem estado final no fecho?
Mantenha-as numa categoria pendente, registe que informação está em falta e aplique uma regra de revisão posterior acordada. Não as classifique por defeito como entregues ou falhadas.
Fontes consultadas
- 3GPP specifications3GPP
- ITU-T E.164International Telecommunication Union
- GSMA resourcesGSMA
- Resolución de discrepancias durante la comparación de facturasMicrosoft Learn