Los informes deben coincidir con DLR, no con conteos de envío

Los conteos de envío resultan reconfortantes: la API aceptó el mensaje, por lo que la semana 'funcionó'. Esa comodidad se rompe en las semanas de facturación. Un informe que contabiliza los envíos como éxito no coincidirá con los recibos DLR, los débitos de la billetera para tráfico de múltiples segmentos y las auditorías de webhooks.

IOSOR establece una regla estricta: las exportaciones de informes siguen a los recibos de entrega. Enviado, en cola y aceptado para envío se mantienen como indicadores operativos. Entregado, fallido y desconocido son las columnas sobre las cuales debaten los equipos de finanzas y producto.

Lo enviado es una miga de pan, no una métrica de cierre

La aceptación para envío demuestra que la ruta tomó el trabajo. No prueba que el terminal recibió el SMS. Si el KPI principal de su paquete de informes es el conteo de envíos, sobreestimará el éxito cada vez que aumente la proporción de fallidos o desconocidos. Conserve el envío como una columna de volumen si resulta útil, pero nunca como un sustituto de lo entregado.

Las columnas de exportación siguen a los recibos

El esquema de exportación nombra los estados de los recibos de forma explícita. Entregado requiere un DLR. Fallido requiere una señal de falla terminal. Desconocido permanece como desconocido hasta que llega un recibo; no es una entrega suave. Las semanas de facturación que ocultan el estado desconocido dentro del éxito generan la clásica disputa de que la cuota desconocida no ha sido entregada.

Concilie webhooks y libro mayor contra los mismos recibos

La conciliación de auditoría de webhooks frente a la exportación del libro mayor es la forma de demostrar que el informe no es una fantasía. Los registros diarios de webhooks, los estados DLR y las líneas del libro mayor prepago deben contar la misma historia. Si los webhooks muestran fallos mientras el informe muestra éxito, el informe está equivocado: corrija la exportación, no 'ajuste' la billetera.

Rechace semanas de facturación basadas en envíos

Cualquier cierre que facture o celebre basándose únicamente en los conteos de envío debe ser bloqueado. Reescriba el paquete para que finanzas analice las cuotas de entregados y desconocidos. Si el contrato de un socio aún menciona 'envíos API exitosos', traduzca esa terminología en notas DLR, sin alterar las columnas para adaptarse a una redacción incorrecta.

Rutas de operaciones relacionadas

• Semana de facturación DLR: la cuota desconocida no se entrega
• Conciliación de registros de Webhook diarios frente a saldos prepagos
• Semana de facturas SMS: cuando las matemáticas de segmentos y la factura no c…

Comience con IOSOR

Abre el paquete de informes de esta semana en la consola IOSOR y confirma que cada KPI de portada use recibos DLR — delivered, failed y unknown — no submits ni accepts de API. Si un gráfico aún trata el submit como éxito, renómbralo o quítalo antes del cierre financiero. Exporta una vez y comparte las mismas columnas de recibo entre producto y finanzas.

Conclusión IOSOR

Los informes cierran con recibos DLR: delivered, failed y unknown — no con submits. El submit sirve para throughput, nunca como verdad de entrega ni como argumento de factura.

Haz: un esquema de exportación anclado a campos de recibo. No: que producto celebre accepts mientras finanzas discute failed DLR.