Conciliación de facturación A2P SMS: CDR, DLR y facturas sin falsas equivalencias

Qué problema resuelve la conciliación de facturación A2P SMS

La conciliación de facturación A2P SMS permite comprobar si los cargos de un proveedor pueden explicarse mediante evidencia operativa trazable. Su objetivo no es convertir una métrica de entrega en una decisión financiera automática, sino comparar conjuntos de registros, localizar diferencias y aplicar la regla comercial acordada para la ruta y el proveedor.

Esta función debe involucrar a operaciones, wholesale, gestión de proveedores y finanzas. Finanzas puede controlar importes, períodos y aprobaciones, pero no suele disponer por sí sola del contexto necesario para interpretar identificadores, reintentos, rutas, segmentos, códigos de error o estados tardíos.

El principio central es sencillo: aceptación técnica, CDR del proveedor, DLR y recepción observada en el terminal son señales diferentes. Una conciliación sólida conserva esa diferencia en vez de resumir todos los eventos bajo una única etiqueta de “entregado” o “facturable”.

• No use un DLR como regla universal de cobro.
• No trate la ausencia de DLR como prueba automática de fallo o de no facturabilidad.
• No discuta diferencias solo con totales agregados cuando existan identificadores de mensaje.
• Aplique la regla contractual documentada antes de calcular ajustes o aceptar cargos.

Las cuatro fuentes de evidencia que deben contrastarse

Una conciliación reproducible parte de registros fuente separados. Cada fuente responde a una pregunta distinta y tiene limitaciones distintas. El registro interno confirma qué intentó enviar su plataforma; la respuesta de aceptación indica cómo respondió el proveedor o SMSC al envío; el CDR sustenta el conjunto reportado por el proveedor; y el DLR aporta un estado técnico posterior cuando se ha solicitado y recibido.

En SMPP, submit_sm_resp es la respuesta al submit_sm y puede incluir el identificador de mensaje asignado por el SMSC. Los recibos de entrega se devuelven posteriormente mediante deliver_sm o data_sm. Esa secuencia es importante: recibir una aceptación no equivale a disponer de un estado final, y disponer de un estado final no sustituye la regla de facturación pactada.

• Registro interno de envío: ID propio, destino original, payload o referencia de contenido, remitente, ruta prevista, timestamp y resultado local.
• Respuesta de aceptación: código de respuesta, ID del proveedor o SMSC cuando exista y timestamp de recepción.
• CDR o extracto equivalente: registros, campos, período y criterios proporcionados por el proveedor.
• DLR o estado: valor original, estado normalizado, código de error, evidencia de red disponible y timestamps de submit y finalización cuando se reciban.

DLR, aceptación y recepción: qué demuestra cada señal

La aceptación técnica demuestra que el sistema receptor aceptó o respondió al intento de submit conforme a la interfaz utilizada. No demuestra por sí sola la entrega al dispositivo ni la lectura por una persona. El alcance exacto de esa aceptación debe interpretarse según la integración y el acuerdo operativo aplicable.

Un DLR representa un evento posterior comunicado por la cadena de mensajería. El estándar SMPP contempla estados y formatos de recibo, incluidos formatos específicos del proveedor. Además, la especificación técnica distingue informes emitidos por el Service Centre de los emitidos por la estación móvil: un informe del Service Centre puede confirmar recepción por ese centro, mientras que uno emitido por la estación móvil confirma recepción por el equipo, no lectura humana.

La recepción observada en un terminal puede ser evidencia adicional en pruebas controladas, pero tampoco debe confundirse automáticamente con lectura, consentimiento, identidad u obligación de cobro. La base de cobro no la determina la semántica general de un DLR: debe estar definida expresamente en el contrato o acuerdo operativo por proveedor y ruta.

• Aceptación: evidencia de una respuesta a la presentación técnica del mensaje.
• DLR: evidencia de un estado reportado; preserve su valor original y contexto.
• Recepción en terminal: puede demostrar recepción técnica en pruebas, no lectura humana.
• Cobro: resultado de una regla comercial documentada, no de una etiqueta técnica aislada.

Definir la unidad conciliable antes de comparar

El objeto de conciliación debe definirse antes de iniciar tráfico o antes del siguiente ciclo de facturación. Si una parte compara mensajes lógicos y otra segmentos técnicos, una discrepancia puede ser aparente y no un error de facturación. La concatenación requiere una decisión explícita sobre la unidad de comparación y liquidación.

SMPP contempla campos para identificar mensajes concatenados, incluido un número de referencia, el total de segmentos y la secuencia de cada segmento. Conserve estos campos cuando estén disponibles y vincule cada segmento al mensaje lógico correspondiente sin sustituir uno por otro.

La correlación no debe depender únicamente de la hora ni del orden de llegada. SMPP permite respuestas fuera de secuencia. Por ello, el identificador interno y el identificador devuelto por el proveedor o SMSC deben ser las claves principales cuando existan, con atributos complementarios para resolver casos incompletos.

• ID interno inmutable del intento de envío.
• ID asignado por el proveedor o SMSC, cuando se reciba.
• Destino original y destino normalizado conforme a una política documentada.
• Timestamp de envío interno, aceptación, submit del proveedor y estado final, con zona horaria y precisión.
• Proveedor, ruta o referencia comercial aplicable al momento del envío.
• Remitente, tipo de tráfico y referencia de contenido cuando sea necesario para investigar.
• Datos de segmentación y relación con el mensaje lógico.
• Estado original, código de error y campos de evidencia de red disponibles.

Acordar las reglas de cobro y el intercambio de datos

La especificación SMPP define mecanismos técnicos de envío, respuestas, identificadores y estados, pero no establece qué evento es facturable. Por ello, cada relación con un proveedor debe contar con una regla comercial y operativa que indique cuál es la unidad facturada, cuál es el evento de referencia y cómo se tratan las excepciones.

La regla debe asociarse a la ruta o producto aplicable. Si una organización utiliza múltiples proveedores o rutas, no debe trasladar sin validación una política de conciliación de una relación a otra. También conviene versionar las reglas para poder aplicar la que estaba vigente en el momento del tráfico.

El acuerdo de intercambio de datos debe evitar ambigüedades que aparecen al cierre: semántica de columnas, formato de identificadores, zona horaria, período de corte, frecuencia de entrega de CDR y plazo para estados tardíos.

• Unidad de cobro: segmento, mensaje lógico u otra unidad expresamente acordada.
• Evento de referencia para cargo y tratamiento de rechazos, reintentos y ajustes.
• Esquema de CDR, tipos de archivo o interfaz, codificación y semántica de cada campo.
• Claves de correlación y reglas de prioridad entre identificadores.
• Zona horaria, precisión temporal, período de corte y fecha de disponibilidad del CDR.
• Ventana para DLR tardíos y procedimiento de reapertura o ajuste.
• Responsables de investigar, aprobar, disputar y registrar resoluciones.

Construir un modelo de estados útil para conciliación

Los estados deben conservarse en dos niveles. El primero es el valor original recibido del proveedor, junto con el código de error y cualquier evidencia adicional disponible. El segundo es una categoría interna definida para operar la conciliación. Esta normalización permite comparar proveedores sin destruir información necesaria para revisar casos concretos.

Evite usar una categoría interna como si fuera una declaración universal sobre entrega o facturación. Un estado técnico puede ser útil para clasificar un expediente, pero la decisión de cargo, crédito o investigación depende de la política acordada y de la evidencia disponible.

La falta de DLR debe figurar como falta de evidencia de estado bajo las condiciones concretas del envío. En SMPP, el retorno de recibos depende de lo solicitado mediante registered_delivery y el contenido puede variar según el proveedor. Por tanto, ausencia de DLR no equivale automáticamente a no entrega, ni a un ajuste automático.

• Aceptado técnicamente.
• Rechazado en la respuesta de submit, si ese evento se registra.
• Estado final reportado por el proveedor o SMSC.
• Estado intermedio o no final, si se recibe.
• Sin DLR disponible dentro de la ventana acordada.
• Sin correlación suficiente.
• Pendiente de investigación o de resolución comercial.

Proceso paso a paso para conciliar CDR, estados y facturas

El proceso debe ejecutarse sobre una copia de trabajo, sin alterar los registros originales. Primero se ingieren los eventos internos, las respuestas de aceptación, los DLR y el CDR del proveedor. Después se valida el esquema, se registran los archivos o extracciones recibidos y se preserva su procedencia.

La normalización se aplica de forma versionada: destinos, zonas horarias, nombres de estado y formatos de identificador. A continuación, se correlaciona con prioridad para las claves fuertes, especialmente el ID interno y el ID del proveedor. Los emparejamientos por atributos secundarios deben quedar marcados como tales y ser revisables.

Solo después de identificar los conjuntos comparables debe aplicarse la regla comercial vigente. El resultado no es únicamente un saldo: debe incluir las diferencias clasificadas, la evidencia disponible, el responsable y el siguiente paso.

• 1. Cierre el período de referencia conforme al calendario acordado.
• 2. Ingesta y conservación de fuentes sin modificar: eventos internos, respuestas, DLR, CDR y factura.
• 3. Validación de integridad: campos obligatorios, duplicados de archivo, zona horaria y período cubierto.
• 4. Normalización versionada de identificadores, destinos, timestamps y estados.
• 5. Correlación por IDs; utilice atributos secundarios solo como apoyo y señale el nivel de confianza.
• 6. Agrupación por proveedor, ruta, período y unidad de cobro acordada.
• 7. Clasificación de diferencias y aplicación de la política contractual.
• 8. Revisión operativa, aprobación financiera y registro de ajustes o disputas.

Diferencias frecuentes y cómo tratarlas

Los registros duplicados requieren distinguir entre un evento repetido en la exportación, un reenvío legítimo y dos intentos diferentes. No elimine duplicados solo por compartir destino o contenido. Examine los identificadores, los timestamps, la ruta y la relación entre el submit original y cualquier reintento.

La concatenación puede producir diferencias cuando un lado contabiliza segmentos y el otro agrupa por mensaje lógico. La solución no es forzar una equivalencia posterior, sino reconstruir la relación entre segmentos y mensaje lógico y aplicar la unidad definida en el acuerdo.

Las diferencias temporales pueden surgir porque los eventos tienen momentos distintos: envío interno, aceptación, submit, estado final y corte de facturación. Los DLR finales pueden llegar después del cierre inicial. Es necesario separar el período de tráfico del período de disponibilidad de evidencia y usar la ventana de ajuste acordada.

Los rechazos, los estados tardíos y los registros ausentes deben mantenerse como categorías distintas. Un registro ausente del CDR no es idéntico a un rechazo técnico; un DLR tardío no es igual a un DLR inexistente; y un estado reportado no sustituye el registro facturado del proveedor.

• Duplicados: revise identidad de evento, reintentos y repetición de exportaciones.
• Concatenación: compare la unidad técnica y la unidad comercial pactada.
• Timestamps: conserve evento, zona horaria, precisión y fecha de recepción del dato.
• Estados tardíos: aplique la ventana acordada antes de cerrar definitivamente la investigación.
• Rechazos: diferencie el rechazo de submit de un estado final posterior.
• Registros ausentes: abra una excepción con claves de búsqueda y período verificable.