Campos obrigatórios XML TISS exigem mais do que preencher uma tag apontada pelo validador: é preciso entender o contexto da guia, corrigir o dado na origem e gerar um arquivo novo para nova conferência.
Ao investigar campos obrigatórios XML TISS, o objetivo não deve ser apenas fazer a mensagem de erro desaparecer. A correção confiável começa ao identificar o elemento indicado, verificar a qual guia e ocorrência ele pertence, conferir o dado registrado no cadastro ou no atendimento e somente então gerar um novo XML. Esse método ajuda faturistas, equipes administrativas e gestores a tratar a causa do erro de preenchimento TISS sem editar o arquivo de forma isolada.
Neste artigo
O que torna um campo obrigatório no XML TISS
Um campo obrigatório é uma informação cuja presença, posição, formato ou combinação com outros dados é exigida pela estrutura aplicável à mensagem. No padrão TISS, o componente de conteúdo e estrutura estabelece a arquitetura dos dados usados nas mensagens eletrônicas, enquanto o componente de comunicação adota XML como linguagem de marcação de dados. Por isso, a obrigatoriedade não deve ser entendida como uma lista única e fixa para toda situação: ela depende do tipo de mensagem, da guia, do grupo de dados e da versão que está sendo usada. (Padrão TISS – Maio/2026 — Agência Nacional de Saúde Suplementar)
Regra prática
Não preencha um campo apenas porque ele aparece em outro XML ou em outra guia. Primeiro confirme se aquele elemento é previsto para o ponto exato da estrutura que está sendo corrigido.
Ausência, formato e valor inválido: diferenças que mudam a correção
Mensagens parecidas podem exigir tratamentos diferentes. Um elemento ausente indica que a informação esperada não foi gerada naquele local. Já um valor inválido sugere que a tag pode existir, mas seu conteúdo não atende à regra aplicada. Há ainda situações de estrutura: o conteúdo está preenchido, porém foi colocado no grupo errado, em uma ordem não aceita ou em uma ocorrência incompatível. Separar essas hipóteses evita substituir dados corretos por tentativas aleatórias.
Como interpretar o primeiro apontamento
| Tipo de apontamento | O que conferir | Onde a causa costuma estar |
|---|---|---|
| Campo ausente | Se a informação deveria ser coletada para aquela guia e ocorrência | Cadastro, tela de atendimento, regra de geração ou mapeamento |
| Formato inválido | Caracteres, tamanho, casas decimais, padrão de data ou composição do código | Modo de preenchimento, máscara do sistema ou transformação do dado |
| Valor inválido | Se o conteúdo corresponde ao contexto e à tabela ou regra aplicável | Cadastro desatualizado, seleção incorreta ou associação inadequada |
| Estrutura ou ordem | Caminho do elemento, grupo pai e sequência de elementos | Modelo de XML, versão configurada ou rotina de geração |
| Inconsistência entre campos | Relação entre tipo de guia, procedimento, datas, quantidades e totais | Dados da conta, parametrização ou integração entre sistemas |
Como localizar o campo indicado na mensagem de erro
Comece preservando a mensagem completa, e não apenas seu código. Anote o nome do elemento, o caminho informado quando houver, a linha ou posição, a guia ou lote relacionado e a descrição do motivo. Em um lote com várias guias, a mesma tag pode aparecer diversas vezes; localizar somente pelo nome pode levar à correção da ocorrência errada. Se a mensagem não trouxer caminho, procure primeiro a guia e o bloco de dados que estavam sendo gerados no momento da falha.
Registro mínimo para investigar cada falha
- Identificador interno da conta, guia ou lote, conforme a política da instituição
- Texto integral da mensagem recebida
- Elemento, caminho ou posição apontada
- Tipo de problema percebido: ausência, formato, valor, estrutura ou relação entre dados
- Sistema, tela, cadastro ou integração responsável pela informação
- Ação adotada, responsável, data da correção e resultado da nova validação
Confira o contexto antes de alterar o dado
Uma correção só é segura quando o campo faz sentido dentro do contexto. Antes de editar, confronte a informação com o registro que a originou: identificação do beneficiário e do prestador, tipo de guia, data do atendimento, procedimento, quantidade, valores, autorização quando aplicável e demais documentos operacionais. Não se trata de copiar dados de uma conta anterior, mas de confirmar que cada dado representa o atendimento que está sendo faturado.
Quando a dúvida for sobre a etapa anterior ao XML — coleta de dados, montagem da conta, conferência e tratamento de retornos — consulte também o material sobre Faturamento TISS: guia completo para clínicas, hospitais e laboratórios. Ele ajuda a enxergar a falha de preenchimento como parte do processo operacional, e não como um problema restrito ao arquivo.
Corrija a informação na guia, no cadastro ou na regra de geração
Depois de compreender a falha, volte à origem do dado. Se a informação é estável e reutilizada, como um dado de identificação do prestador, investigue o cadastro e sua parametrização. Se depende do atendimento, como data, procedimento, quantidade ou informação vinculada à guia, revise o lançamento daquela conta. Se o cadastro e a guia estão corretos, mas o XML permanece divergente, o problema pode estar no mapeamento ou na regra de geração do sistema.
Roteiro de correção na origem
Siga a sequência abaixo para manter rastreabilidade e reduzir correções repetidas.
- Classifique o campo como cadastral, assistencial, financeiro ou estrutural
- Confirme a ocorrência exata da guia afetada
- Compare o valor informado com o registro fonte e com a regra aplicável
- Corrija o cadastro quando o mesmo erro puder se repetir em novas guias
- Corrija a guia quando o problema for específico daquele atendimento
- Encaminhe o caso técnico quando a informação correta não estiver sendo transportada para o XML
- Registre a causa confirmada para aprimorar a conferência futura
Exemplo ilustrativo de investigação e correção
O caso abaixo é ilustrativo e não representa uma mensagem universal de operadora, um layout completo nem uma regra oficial específica. Ele mostra como separar o sintoma técnico da correção operacional.
Caminho do apontamento à nova geração
| Etapa | Descrição ilustrativa |
|---|---|
| Entrada | O validador aponta que um elemento esperado em determinada ocorrência da guia está ausente. |
| Mapeamento | A equipe relaciona o caminho da mensagem à guia afetada e identifica que o elemento deveria receber um dado registrado na tela do atendimento. |
| Erro identificado | O campo correspondente estava vazio na guia, embora o cadastro geral do prestador estivesse correto. |
| Correção | A equipe revisa o registro fonte, preenche a informação comprovada para aquela ocorrência e salva a guia. |
| Novo XML | O arquivo é gerado novamente a partir do sistema, sem inserir manualmente uma tag no XML anterior. |
| Nova conferência | A equipe valida o novo arquivo e analisa qualquer apontamento remanescente como uma falha separada. |
Cuidados ao editar informações do XML
Alterar diretamente o XML pode ser útil para análise técnica controlada, mas não deve substituir a correção do sistema de origem. Uma edição pontual pode ocultar um cadastro incompleto, não se repetir no próximo lote e criar divergência entre o arquivo enviado e o registro interno. Quando for indispensável examinar o conteúdo do arquivo, trabalhe sobre uma cópia, preserve o original e documente o que foi observado; a versão operacional deve nascer novamente a partir do dado corrigido.
Gere um novo XML e valide novamente
Após salvar a correção na origem, gere um arquivo novo e repita a validação. O resultado sem o apontamento original confirma apenas que aquela verificação não voltou a ser apresentada pela ferramenta utilizada; ele não substitui a conferência das regras operacionais, contratuais ou específicas da operadora. Por isso, trate cada nova mensagem pelo mesmo fluxo: localizar, contextualizar, corrigir na origem, gerar novamente e conferir.
Para uma conferência técnica antes do envio, use o Validador TISS online. A ferramenta é oferecida para validar XML TISS e identificar inconsistências antes do envio à operadora; ainda assim, mantenha a revisão dos dados de origem e das regras aplicáveis ao seu fluxo.
Quando consultar a documentação oficial e a operadora
Consulte a documentação oficial quando a dúvida envolver arquitetura da mensagem, versões, arquivos do padrão ou terminologia aplicável. A ANS organiza o padrão TISS em cinco componentes e disponibiliza os arquivos correspondentes; o histórico de versões também apresenta competências, publicações, início de vigência e limites de implantação. Para exigências próprias de recebimento, regras contratuais ou interpretação de uma rejeição específica, a fonte adequada é a documentação e o canal da operadora envolvida. (Padrão TISS – Maio/2026 — Agência Nacional de Saúde Suplementar) (Padrão TISS – Histórico das versões dos Componentes do Padrão TISS — Agência Nacional de Saúde Suplementar)
Pontos principais
- Leia a mensagem completa e localize a ocorrência exata antes de alterar qualquer dado
- Diferencie ausência, formato inválido, valor inválido e erro estrutural
- Verifique o contexto da guia e a fonte que gerou a informação
- Corrija cadastro, guia ou regra de geração, em vez de tratar o XML como fonte definitiva
- Gere um novo arquivo após a correção e valide outra vez
- Use a documentação oficial e a orientação da operadora quando a regra depender de versão ou de recebimento específico
Perguntas frequentes sobre campos obrigatórios no XML TISS
Valide o arquivo depois da correção
Depois de corrigir o cadastro, a guia ou a regra de geração, gere um novo arquivo e faça uma nova conferência com o Validador TISS online antes de seguir com seu processo de envio.