Fim do mês, guias conferidas, arquivo pronto. Você faz o upload no portal do convênio e, dez segundos depois, a tela devolve uma mensagem em vermelho com um código de quatro dígitos. O arquivo foi recusado.
Ninguém olhou uma sessão sequer. A operadora nem chegou a analisar as guias. O arquivo que as carregava parou na porta, e com ele o faturamento do mês inteiro daquele convênio.
Esse tipo de recusa assusta mais do que deveria. Quase sempre ela vem de um punhado de causas conhecidas, nenhuma delas clínica, e todas se resolvem antes do envio quando você entende o que o portal confere.
Guia, lote e protocolo: três coisas diferentes
Vale separar os conceitos, porque boa parte da confusão vem de tratá-los como sinônimos:
- A guia é a cobrança de um atendimento ou de uma série. Na fisioterapia, as sessões vão na guia SP/SADT, com a senha da autorização, as datas, os códigos e o profissional que executou. Se a dúvida é o que preencher dentro dela, o guia de códigos TUSS e da guia SP/SADT cobre campo a campo.
- O lote é o envelope. É o arquivo XML que junta várias guias fechadas de um único convênio e as entrega de uma vez. Tem número próprio, sequencial por convênio, e termina com um código de verificação.
- O protocolo é o recibo. É o número que o portal devolve quando aceita o arquivo, e é a única prova de que você entregou o faturamento dentro do prazo.
A operadora confere essas camadas em ordem. Primeiro o envelope: o arquivo está no padrão, na versão aceita, com o código de verificação correto e dentro do limite de guias? Só depois ela abre as guias e analisa cada cobrança. Erro na primeira etapa devolve o lote inteiro; erro na segunda vira glosa da guia ou da sessão, e aparece semanas depois no demonstrativo.
O caminho da guia até o protocolo
- Atender com a autorização válida. Senha, validade e quantidade conferidas antes da sessão, não depois.
- Fechar a guia. Quando as sessões do período estão realizadas, a guia é fechada com o que de fato aconteceu. Falta e sessão cancelada não entram.
- Montar o lote. Juntar as guias fechadas do mesmo convênio que ainda não foram enviadas.
- Gerar o arquivo XML. No padrão TISS, na versão exigida: desde 1º de julho de 2026, a 4.03.00.
- Conferir antes de enviar. Estrutura, quantidade, dados cadastrais. É aqui que se evita a recusa.
- Fazer o upload no portal da operadora. Cada convênio tem o seu portal, e alguns pedem o arquivo compactado ou com um nome em formato específico. Isso está no manual do prestador.
- Anotar o protocolo e a data. No mesmo dia, em um lugar onde a equipe inteira encontre.
- Acompanhar o demonstrativo. É ele que mostra o que foi pago e o que foi glosado, sessão por sessão.
Repare que o passo 7 é o mais esquecido. Quando o pagamento não vem e você liga para a operadora, a primeira pergunta é o número do protocolo. Sem ele, a conversa começa do zero, e o prazo de envio do contrato pode já ter passado.
O que tem dentro do arquivo
Você não precisa ler XML para faturar, mas entender três coisas sobre o arquivo explica quase todas as recusas.
O cabeçalho identifica quem manda e quem recebe. Vai o Registro ANS da operadora (seis dígitos), o seu código de prestador naquele convênio, o número do lote e a versão do padrão. Um Registro ANS errado no cadastro do convênio faz o arquivo chegar “endereçado a outra pessoa”.
A versão também conta. A 4.03.00 vale desde dezembro de 2025 e é obrigatória desde 1º de julho de 2026, e há operadora que já avisou que recusa automaticamente arquivo em versão anterior. Como a ANS revisa o padrão periodicamente, vale conferir de tempos em tempos a versão vigente no site dela.
As guias carregam os dados de cadastro em formato de máquina. E alguns formatos não são os que você usa no dia a dia:
- A UF do conselho vai como código numérico do IBGE, não como sigla. São Paulo é 35, Minas Gerais é 31. Um sistema que escreve “SP” no campo gera um arquivo reprovado na validação.
- O CBO precisa estar na lista fechada do padrão. Um código digitado com um dígito trocado não é “quase certo”: o arquivo não passa.
- Campo opcional vazio não pode aparecer vazio. Se não há observação, o campo simplesmente não vai no arquivo. Um campo presente e em branco reprova.
- Sem CNES, a guia sai com o valor reservado 9999999. O padrão aceita, mas alguns convênios recusam.
O final do arquivo tem o hash. É um código de verificação calculado sobre o texto de todos os campos do lote, na ordem em que aparecem. A operadora recalcula esse código ao receber. Se uma única letra mudou entre a geração e o envio, o resultado não bate e o lote volta.
Os erros que mais fazem o lote voltar
Pelo padrão, a operadora responde a um lote de uma de duas formas: com o protocolo de recebimento ou com uma mensagem de erro que traz um código da Tabela 38 do TISS, a mesma terminologia usada nas glosas. Nem todo portal mostra o código (alguns exibem só a frase, ou uma mensagem própria), mas, quando ele aparece, costuma ser um destes:
| Código | O que o portal diz | Causa mais comum | Como corrigir |
|---|---|---|---|
| 5001 | Mensagem eletrônica fora do padrão TISS | O arquivo não é reconhecido como mensagem TISS: arquivo errado no upload ou gerado fora do padrão | Conferir se enviou o XML do lote certo; gerar de novo pelo sistema |
| 5002 | Não foi possível validar o arquivo XML | Estrutura inválida: campo vazio, formato errado (UF como sigla, CBO fora da lista), campo obrigatório ausente | Corrigir o cadastro que originou o dado e gerar de novo |
| 5014 | Código hash inválido. Mensagem pode estar corrompida | Arquivo aberto e salvo em editor de texto, campo corrigido à mão, ou codificação de caracteres diferente da que o convênio usa | Gerar de novo pelo sistema, sem editar; se só um convênio recusa, conferir a codificação que ele usa |
| 5015 | Número de guias/demonstrativos dentro da mensagem superior ao tamanho máximo permitido | Mais de 100 guias no mesmo lote | Dividir em dois ou mais lotes |
| 5028 | Versão do padrão inválida | Arquivo gerado em versão anterior à exigida | Gerar na versão vigente (desde 1º de julho de 2026, a 4.03.00) |
| 1308 | Guia já apresentada | A mesma guia foi enviada em outro lote, normalmente num reenvio sem conferência | Tirar a guia repetida; se o primeiro envio foi recusado, conferir antes de reenviar |
| 3268 | Número de lote já informado anteriormente | Lote novo enviado com o número de um lote anterior | Gerar o lote com número novo |
Duas observações sobre o 5014, porque ele é o mais frustrante: o arquivo parece perfeito quando você o abre, e o problema não aparece em nenhuma tela.
A primeira causa é humana. Alguém nota um nome escrito errado, abre o XML no bloco de notas, corrige e salva. O dado ficou certo e o arquivo ficou inválido, porque o hash foi calculado sobre o texto antigo. O editor também pode trocar a codificação de caracteres ao salvar, e aí cada acento vira outra sequência de bytes.
A segunda é técnica: a codificação dos caracteres no cálculo. O manual do padrão manda calcular o hash em uma codificação (ISO-8859-1), mas há validadores que calculam em outra (UTF-8). Em texto sem acento as duas dão o mesmo resultado; basta um “ç” ou um “ã”, ou seja, quase todo nome brasileiro, para darem resultados diferentes. É por isso que o mesmo sistema gera arquivos que passam num convênio e voltam com 5014 em outro. Se a recusa se repete só com um convênio e o arquivo não foi mexido, pergunte ao suporte dele qual codificação o validador usa.
Como corrigir sem bagunçar a numeração
A regra que resolve quase tudo: não se conserta um lote. Descarta-se o lote e gera-se outro.
- Leia o código da recusa e identifique se o problema é do arquivo (5001, 5014, 5015) ou de uma guia específica (dado cadastral, guia repetida).
- Corrija na origem: o cadastro do profissional, do convênio ou do paciente, ou a própria guia, reabrindo-a se for preciso.
- Descarte o lote recusado e registre o motivo, para a equipe não repetir o mesmo erro no mês seguinte.
- Gere um lote novo, com número novo.
Por que número novo? Porque a operadora controla pelo número o que já recebeu. A Tabela 38 tem até um código para isso, o 3268 (número de lote já informado anteriormente), e reenviar com o mesmo número pode ser recusado de cara. Quando passa, é pior: a conferência do outro lado pode se perder entre as duas versões, e o pagamento atrasa sem glosa nenhuma que explique. Buraco na numeração é aceitável. Número repetido, não.
Se a recusa veio da segunda etapa, na forma de glosa no demonstrativo, o caminho é outro: recurso de glosa, com a prova de cada sessão. Quando a glosa é de mérito, sobre a necessidade da continuidade, a defesa se apoia no relatório de continuidade das sessões e na evolução registrada em cada atendimento.
O que muda de uma operadora para outra
O padrão TISS é o mesmo para todas as operadoras, mas o manual de cada uma acrescenta regras. As mais comuns:
- Prazo de envio. Quantos dias depois do atendimento o lote ainda é aceito. Está no contrato, e passar dele é glosa sem recurso.
- Tamanho do lote. Algumas pedem menos de 100 guias.
- Nome e compactação do arquivo. Há portais que só aceitam o XML dentro de um arquivo compactado, ou com um padrão de nome.
- Calendário de corte. Lotes enviados até determinado dia entram no pagamento do mês. Depois disso, só no seguinte.
- Via física da guia. O que vale para a cobrança é o arquivo, mas muitas operadoras pedem a guia em papel assinada pelo paciente a cada sessão para a auditoria.
Vale reunir essas regras numa folha por convênio, junto com o login do portal e o contato do setor de credenciamento. É o tipo de informação que mora na cabeça de uma pessoa só na clínica, até ela sair de férias. Se você ainda está decidindo com quais operadoras trabalhar, o passo a passo do credenciamento mostra o que perguntar antes de assinar, e o prazo de envio e o calendário de pagamento entram na conta de quanto o convênio realmente paga.
Checklist antes do upload
- Todas as guias do lote são do mesmo convênio
- O lote tem até 100 guias, ou menos, se o manual da operadora pedir
- Nenhuma guia do lote já foi protocolada em outro envio
- Registro ANS do convênio e código do prestador conferidos no cadastro
- Conselho, UF e CBO de quem executou e de quem solicitou estão preenchidos
- As sessões estão dentro da validade e da quantidade da autorização
- O arquivo não foi aberto nem salvo em nenhum editor depois de gerado
- O lote está dentro do prazo de envio do contrato
- Há um lugar combinado para anotar o protocolo assim que o portal devolver
No Clinvo, o módulo de convênios faz a parte que costuma derrubar o lote. Ao fechar a guia, ele confere o Registro ANS, a identificação da clínica, a carteirinha, a senha e as datas, a quantidade contra o autorizado, e o conselho e o CBO de quem solicitou e de quem executou. Quando falta alguma coisa, a mensagem diz quem corrige, por exemplo o profissional em Meu perfil. Na hora de gerar o lote, o arquivo é conferido contra as regras oficiais do padrão TISS 4.03.00 antes de existir, e o erro aparece traduzido e ligado à guia em que está. O XML gerado fica guardado exatamente como foi baixado, e corrigir significa descartar o lote e gerar outro com número novo. Para o convênio que foge do padrão, o nome do arquivo e a codificação do hash são ajustáveis no cadastro dele. Depois do envio, você registra o protocolo e, quando o demonstrativo chega, o que foi pago e o que foi glosado em cada sessão.
O envio continua sendo seu: o Clinvo não se conecta ao convênio, você baixa o arquivo e faz o upload no portal. O faturamento de convênios está nos planos Profissional e Clínica e é ativado pela clínica. O passo a passo de fechar a guia e gerar o lote está na Central de Ajuda. Teste grátis por 14 dias, sem cartão de crédito.