5 erros no cabeçalho do AFD que detonam a validação do MTE

Há um tipo de frustração técnica que só quem trabalha com Departamento Pessoal e TI conhece bem: enviar o arquivo AFD (Arquivo Fonte de Dados) para o Validador do MTE e ver a mensagem de "REJEIÇÃO" aparecer instantaneamente antes mesmo de analisar as marcações de ponto. Em 2026, com a auditoria digital cada vez mais severa, o menor deslize na estrutura do arquivo pode custar horas de retrabalho ou multas em ações trabalhistas.

Como engenheira de automação especializada em REP, perco mais tempo corrigindo erros de geração de arquivo do que consertando o relógio de ponto propriamente dito. O problema raramente está nos registros de marcação (o "corpo" do arquivo), mas sim no cabeçalho (Registro tipo 1), especificamente no preenchimento do NSR (Número Sequencial de Registro) e na identificação do empregador. É ali, na primeira linha, que a maioria dos desenvolvedores de sistema ou pessoal de TI erra ao fazer a extração.

Se o seu arquivo está falhando na validação, aposto que é um destes cinco motivos abaixo.

1. NSR do cabeçalho (Tipo 1) não corresponde ao relógio físico

O erro mais clássico que vejo em suportes técnicos é o software de gestão tentando ser "esperto" e resetar a contagem. O Registro de Tipo 1 é o cabeçalho. Ele deve conter o NSR atual do relógio no momento exato em que o arquivo foi gerado.

Muitos sistemas, ao exportar o AFD, forçam o NSR do cabeçalho para ser "1" ou "0" para "organizar" o arquivo visualmente. Isso é tecnicamente uma falsificação. O NSR no AFD é um espelho da memória do REP (Registrador Eletrônico de Ponto). Se o seu relógio tem 150.000 marcações na memória e você gera um arquivo agora, o cabeçalho (Tipo 1) deve vir com um NSR correspondente ao contador interno do REP naquele instante (por exemplo, 150.001), e não resetado.

Quando o Validador do MTE lê esse cabeçalho com NSR 1, mas encontra registros de marcação (Tipo 3) com NSR na casa dos milhares logo abaixo, ele detecta uma quebra de sequência lógica ou um "salto" injustificado. O interpretador entende que o arquivo foi adulterado ou gerado por um software não homologado que ignora o estado real do hardware.

2. Truncamento de zeros à esquerda no CNPJ do empregador

Parece bobagem, mas quebra 90% das validações em arquivos de empresas com CNPJ que começam por zero. O campo de identificação do empregador no cabeçalho exige 14 caracteres fixos. Ocorre que muitos bancos de dados armazenam CNPJs como números inteiros (não como texto). Quando o sistema faz o "SELECT" para gerar o arquivo .txt, ele pega o número 00.123.456/0001-90 e exporta apenas 123456000190.

O resultado é um campo com 12 dígitos em vez de 14. O Validador do MTE é implacável: ele espera 14 posições. Se faltarem os dois zeros à esquerda, o arquivo é rejeitado com erro de "tamanho de campo inválido" ou "CNPJ inválido". Isso acontece muito em migrações de sistema onde a equipe de TI converteu o histórico de 5 anos de AFD para o novo software e esqueceu de tratar o formato string com padding de zeros à esquerda.

3. Uso de caracteres de pontuação no identificador

O layout do AFD definido pela Portaria 1.510 é rígido: o campo do identificador do empregador deve ser estritamente numérico. Sem pontos, sem traços, sem barras. Ainda assim, recebo arquivos semana sim, semana não, onde o campo identificador_empregador vem preenchido como 12.345.678/0001-90.

Geralmente, isso ocorre quando o desenvolvedor usa a máscara padrão de visualização do Brasil (##.###.###/####-##) direto na exportação, sem fazer o replace. O Validador lê o primeiro ponto e, como o delimitador de campo do AFD é o ponto-e-vírgula (;), ele entende que o campo acabou ali. O resto do CNPJ "vaza" para o próximo campo, corrompendo a linha inteira. A ferramenta do MTE devolve um erro de "separador inválido" ou desalinhamento de colunas, deixando o usuário sem saber onde está o erro, que está justamente na formatação visual do documento.

4. Incompatibilidade entre Tipo de Identificador e o número informado

No cabeçalho do AFD, existe o campo tipo_identificador_empregador (posição 19 do registro tipo 1). Ele é simples: se for CNPJ, você preenche com '1'; se for CPF, com '2'. O erro está na falta de sincronia entre este campo e o conteúdo do identificador.

Eu já vi casos de CPFs de empreendedores individuais sendo informados com o tipo '1' (CNPJ). O Validador verifica o tipo '1', espera 14 dígitos numéricos e recebe 11. Rejeição pura. O inverso também acontece: colocar tipo '2' (CPF) e informar um CNPJ de 14 dígitos.

Além disso, há o erro da "herança de cadastro". Em sistemas que permitem múltiplos empregadores no mesmo banco de dados, se a lógica de geração do arquivo pegar o CNPJ da matriz (tipo 1, 14 dígitos) mas, por algum bug de configuração, marcar o campo como tipo 2, o arquivo vai para o lixo do auditor. É uma verificação que deveria ser trivial, mas é a causa número um de rejeição "automática" antes mesmo do auditor humano olhar para o conteúdo.

5. NSR gerado por software em vez de hardware

Aqui vamos para um problema de automação mais profundo, frequentemente encontrado quando se faz espelhamento do ponto: por que guardar apenas o arquivo digital não é suficiente judicialmente. O cabeçalho é um registro gerado pelo REP. Ele é um evento físico.

O que vejo acontecer: softwares de terceiros que lêem a memória do relógio e tentam "reconstruir" o AFD do zero. Eles pegam as marcações, ordenam e criam um cabeçalho do zero. O problema é o NSR desse cabeçalho criado pelo software. Se o software inventa um NSR para o cabeçalho (por exemplo, usa o último NSR + 1 de forma lógica, mas não física), ele cria uma discrepância.

Se você pegar o relógio, gerar o AFD direto pela porta USB ou Serial e comparar com o arquivo gerado pelo software, o NSR do registro tipo 1 vai ser diferente em um ou dois números. Isso acontece porque o relógio tem um contador interno que avança a cada gravação. Se o software não consegue "ler" o estado exato desse contador no momento da geração (o que é comum em protocolos de comunicação mal implementados), ele chuta o número. O MTE, ao cruzar dados ou comparar com o AFDT (Arquivo Fonte de Dados Tratado) ou a memória física, percebe a "mentira" do NSR e invalida o arquivo por inconsistência de sequência.

Cuidado com o "reprocessamento" de dados

Se você está lidando com a recuperação de dados ou correções de registros corrompidos no arquivo de processamento, a regra de ouro é nunca alterar o NSR dos cabeçalhos originais. Qualquer tentativa de "ajeitar" a sequência manualmente no Bloco de Notas ou via script de Excel para tornar o arquivo "bonito" vai destruir a validade jurídica do documento.

O Validador do MTE não é um "verificador de erro de digitação", ele é um auditor de consistência lógica. O cabeçalho é a assinatura do arquivo. Se o NSR estiver desconexo ou se o CNPJ do empregador não estiver nu, sem formatação e com 14 dígitos, o auditório não abre. Antes de enviar o arquivo para a fiscalização ou para o advogado, rode o Validador oficial em uma máquina isolada e olhe especificamente para o Log da linha 1. É nela que o jogo começa e termina.