Relatórios devem corresponder aos DLRs, não a envios

Os números de submissão trazem uma falsa sensação de segurança: a API aceitou a mensagem, então a semana 'funcionou'. Essa ilusão se desfaz nas semanas de faturamento. Um relatório que contabiliza submissões como sucesso discordará dos recibos DLR, dos débitos de saldo para tráfego multissegmento e das auditorias de webhooks.

A IOSOR estabelece uma regra clara: as exportações de relatórios seguem os recibos de entrega. Submetido, na fila e aceito para envio permanecem apenas como rastros operacionais. Entregue, falhou e desconhecido são as colunas reais sobre as quais finanças e produto negociam.

Submetido é um rastro operacional, não uma métrica de fechamento

A aceitação para envio prova apenas que o sistema recebeu a tarefa. Não garante que o dispositivo final recebeu o SMS. Se o KPI principal do seu relatório for o volume de submissões, você superestimará o sucesso sempre que a taxa de falhas ou desconhecidos aumentar. Mantenha a submissão como uma coluna de volume, mas nunca como substituto de entrega.

Colunas de exportação seguem recibos oficiais

O esquema de exportação nomeia explicitamente os estados de recibo. Entregue exige um DLR. Falhou exige um sinal de falha terminal. Desconhecido permanece como desconhecido até que um recibo seja recebido — não é uma entrega presumida. Semanas de faturamento que ocultam o estado desconhecido no sucesso geram disputas sobre parcelas não entregues.

Concilie webhooks e livro-razão com os mesmos recibos

A conciliação de auditoria de webhooks com a exportação do livro-razão é a forma de provar que o relatório reflete a realidade. Logs diários de webhooks, status DLR e lançamentos do livro-razão pré-pago devem contar a mesma história. Se os webhooks indicarem falha enquanto o relatório mostrar sucesso, o relatório está incorreto: corrija a exportação em vez de ajustar o saldo.

Recuse semanas de faturamento baseadas em submissões

Qualquer fechamento que fature ou comemore resultados com base apenas em submissões deve ser bloqueado. Reestruture o relatório para que o setor financeiro trabalhe com entregas e parcelas desconhecidas. Se o contrato de um parceiro ainda mencionar 'submissões de API com sucesso', traduza essa terminologia para observações de DLR sem alterar a estrutura das colunas.

Caminhos operacionais relacionados

• Semana de fatura DLR: a fatia desconhecida não é entregue
• Conciliação de logs diários de Webhook com saldos pré-pagos
• Fatura de SMS semanal: quando a conta de segmentos e a cobrança divergem

Comece com a IOSOR

Abra o pacote de relatórios desta semana no console IOSOR e confirme que cada KPI de capa usa recibos DLR — delivered, failed e unknown — não submits nem accepts de API. Se um gráfico ainda trata submit como sucesso, renomeie ou remova antes do fechamento financeiro. Exporte uma vez e compartilhe as mesmas colunas de recibo entre produto e finanças.

Conclusão IOSOR

Relatórios fecham com recibos DLR: delivered, failed e unknown — não com submits. Submit serve para throughput, nunca como verdade de entrega nem como argumento de fatura.

Faça: um esquema de exportação preso a campos de recibo. Não: produto celebrar accepts enquanto finanças discute failed DLR.