Todo lote de faturamento enviado a uma operadora de plano de saúde depende de um arquivo que poucos profissionais da área administrativa realmente entendem por dentro: o XML TISS. Quando esse arquivo sai com um campo errado, uma tag mal fechada ou uma versão de layout defasada, o lote inteiro pode ser devolvido antes mesmo de chegar à análise financeira. Isso significa retrabalho, atraso no recebimento e mais pressão sobre a equipe de faturamento.
Este guia explica o que é o arquivo xml tiss, como ele é estruturado, o que muda com a versão 4.03.00 da ANS e, principalmente, como montar uma rotina de validação que reduz rejeições antes do envio.
Principais conclusões
- •O XML TISS organiza o faturamento em três blocos: cabeçalho, corpo e fechamento, agrupados em lotes de 1 a 100 guias.
- •A partir da competência junho/2026 (entrega em julho/2026), a versão 4.03.00 passa a ser obrigatória e arquivos em versões antigas são rejeitados automaticamente.
- •Erro, rejeição e glosa TISS são etapas diferentes do mesmo problema, e tratá-las como sinônimos atrasa a correção.
- •Validar o schema XSD antes do envio é o passo que mais evita devolução de lote.
O que é o XML TISS e como ele é estruturado?
O XML TISS é a implementação técnica e digital das diretrizes do Padrão TISS (Troca de Informação de Saúde Suplementar), criado pela ANS para padronizar a troca eletrônica de dados administrativos, financeiros e assistenciais entre prestadores e operadoras. Na prática, é um arquivo estruturado em linguagem XML (Extensible Markup Language) que permite que sistemas diferentes, de clínicas e de operadoras, se comuniquem em um formato único.
O arquivo segue uma organização hierárquica rígida, dividida em três blocos. O cabeçalho (header) traz a identificação do prestador, da operadora, o número do lote e a versão do layout usada. O corpo (body) reúne os dados do beneficiário, do atendimento, os procedimentos realizados, códigos e valores. Já o fechamento (trailer) apresenta o somatório financeiro e a quantidade total de guias enviadas.
As guias individuais, como consulta, SP/SADT, internação e honorários, não são enviadas soltas. Elas são agrupadas em lotes de faturamento, e cada lote pode conter de 1 a 100 guias dentro de um único arquivo XML. Entender essa hierarquia é o primeiro passo para saber onde procurar quando um lote volta rejeitado: o problema pode estar em um dado pontual do corpo ou em uma inconsistência no fechamento do lote inteiro.
Quais são as exigências regulatórias da ANS para o XML TISS?
A ANS atualiza periodicamente a referência técnica do Padrão TISS, e ignorar essas atualizações é uma das causas mais comuns de rejeição em massa. A próxima mudança relevante já tem data marcada: a partir da entrega de faturamento de julho de 2026, referente à competência de junho de 2026, o uso da versão 4.03.00 passa a ser obrigatório.
Atenção ao prazo da versão 4.03.00
Arquivos XML enviados em versões anteriores à 4.03.00, após o prazo definido pela ANS, são rejeitados automaticamente pela operadora. Não há tolerância ou período de adaptação paralelo: a mudança de versão precisa estar implantada no sistema de faturamento antes da competência de junho/2026.
Entre as principais mudanças da versão 4.03.00 estão a inclusão de suporte ao CNPJ alfanumérico, novos campos para o nome social do beneficiário, a remoção do nome do beneficiário em recursos digitais específicos e a atualização das tabelas TUSS e OPME (tabelas 19, 20, 38 e 87). Cada uma dessas mudanças afeta diretamente o schema XSD contra o qual o arquivo é validado.
Na prática clínica, isso quer dizer que depender de um sistema que atualiza manualmente o layout TISS é um risco. No Medicit, as atualizações de versão e de tabelas TUSS/OPME são aplicadas diretamente no módulo de faturamento, o que evita que a equipe precise acompanhar manualmente cada nova referência técnica publicada pela ANS.
Erro, rejeição ou glosa TISS: qual a diferença?
Tratar erro, rejeição e glosa como sinônimos é um dos motivos pelos quais as equipes de faturamento perdem tempo corrigindo a coisa errada. São três etapas distintas do mesmo processo, e cada uma exige uma ação diferente da equipe.
Erro, rejeição e glosa TISS lado a lado
| Etapa | Quando ocorre | O que acontece | Ação esperada |
|---|---|---|---|
| Erro TISS | Na origem, antes do envio | Dado incorreto, campo obrigatório omisso ou incompatibilidade de layout | Corrigir no sistema antes de gerar o lote |
| Rejeição TISS | Na recepção/validação pela operadora | O arquivo é recusado antes de qualquer auditoria ou análise financeira | Corrigir e reenviar o lote completo |
| Glosa TISS | Após o aceite técnico do XML | Pagamento negado total ou parcialmente por inconsistência administrativa, técnica ou contratual | Recurso de glosa, com justificativa e documentação |
A rejeição é especialmente custosa porque bloqueia o lote inteiro, mesmo quando o problema está em uma única guia. As causas estruturais mais recorrentes incluem campos obrigatórios em branco, como número da carteirinha ou código do prestador, formatação inválida de datas e valores, códigos TUSS ausentes ou desatualizados, divergência nos somatórios do lote e erros de sintaxe XML, como tags mal formadas ou sem fechamento. Para entender como esses problemas evoluem depois do aceite técnico, vale aprofundar em glosas no faturamento e como preveni-las na prática.
Como garantir conformidade no envio do XML TISS?
A forma mais eficaz de evitar rejeição é tratar a validação como uma rotina em camadas, aplicada antes do envio, e não como uma conferência pontual feita quando o lote já voltou recusado.
Rotina de validação do XML TISS em 5 camadas
Conferência dos dados de origem: validar se o que foi digitado no sistema corresponde à guia física ou digital, ao prontuário e à autorização prévia. Revisão de regras de preenchimento: confirmar datas, horários, profissionais executantes e códigos TUSS na versão vigente da tabela. Checagem relacional: comparar os somatórios de itens e valores unitários com o campo totalizador do lote. Validação estrutural com schema XSD: submeter o arquivo a um validador XML TISS que compare o arquivo contra os schemas oficiais da ANS, checando ordem de elementos, tipos de dados e limites de tamanho. Correção com rastreabilidade: tratar as falhas por ordem de dependência, primeiro estrutura e sintaxe, depois preenchimento e regras de negócio, gerando uma nova versão identificável do arquivo após cada ajuste.
Depois de qualquer correção, o arquivo precisa ser revalidado por completo, nunca apenas no trecho alterado. Um erro de sintaxe resolvido pode deixar passar despercebido um problema de somatório que só aparece na validação relacional seguinte.
Monitorar indicadores também faz parte da conformidade, não só da correção pontual. Acompanhar o percentual de XMLs rejeitados, a taxa de glosa, o tempo médio de reenvio e o retrabalho da equipe mostra se a rotina de validação está funcionando ou só mascarando o mesmo erro repetido mês a mês. Processos manuais de conferência, assim como o prontuário em papel, tendem a concentrar esse tipo de falha justamente porque dependem de conferência humana repetitiva em cada etapa.
Validação automática reduz o retrabalho
Sistemas de faturamento que já geram o XML na versão vigente e aplicam a validação estrutural contra o schema XSD antes do envio eliminam boa parte das rejeições por formatação e sintaxe, que são justamente as mais evitáveis. É esse o papel do módulo de faturamento TISS do Medicit dentro da rotina diária de uma clínica.
Conclusão
O XML TISS não é só um formato de arquivo, é a porta de entrada do faturamento de uma clínica junto às operadoras. Entender sua estrutura, acompanhar as exigências da ANS como a obrigatoriedade da versão 4.03.00 e aplicar uma validação em camadas antes do envio reduz rejeições, acelera o recebimento e libera a equipe de faturamento do retrabalho repetitivo.
Perguntas frequentes
O que é o XML TISS?
É o arquivo estruturado em linguagem XML que implementa tecnicamente o Padrão TISS da ANS. Ele organiza dados administrativos, financeiros e assistenciais em cabeçalho, corpo e fechamento, permitindo que sistemas de clínicas e de operadoras troquem informações de faturamento em um formato único e padronizado.
Qual a diferença entre erro, rejeição e glosa TISS?
O erro acontece na origem, antes do envio, por dado incorreto ou campo omisso. A rejeição ocorre na recepção do arquivo pela operadora, que recusa o lote antes de qualquer análise financeira. Já a glosa acontece depois do aceite técnico, quando o pagamento é negado por inconsistência administrativa, técnica ou contratual.
Quando a versão 4.03.00 do TISS se torna obrigatória?
A partir da entrega de faturamento de julho de 2026, referente à competência de junho de 2026, o uso da versão 4.03.00 passa a ser obrigatório para todos os arquivos XML TISS. Arquivos enviados em versões anteriores a essa data são rejeitados automaticamente pela operadora, sem período de tolerância.
Como validar o schema XSD do XML TISS antes do envio?
É preciso submeter o arquivo a um validador que compare sua estrutura contra os schemas oficiais publicados pela ANS, verificando ordem dos elementos, tipos de dados e limites de tamanho de cada campo. Sistemas de faturamento como o Medicit já aplicam essa validação automaticamente antes de liberar o envio do lote.
O que fazer quando um lote de XML TISS é rejeitado?
O primeiro passo é identificar em qual camada o problema está: sintaxe, preenchimento ou regra relacional, já que corrigir fora dessa ordem costuma gerar retrabalho. Depois do ajuste, o arquivo deve ser salvo como uma nova versão identificável e revalidado por completo antes do reenvio à operadora.
