Rejeição 1160: confira a competência da apuração do crédito da ZFM

A rejeição 1160 trata do ano e mês de referência da apuração informado no documento. Quando esse retorno aparece, a empresa precisa conferir a competência registrada e o valor que foi levado ao XML. Reduzir o período para um mês anterior apenas para eliminar a mensagem pode alterar a informação fiscal e deixar a causa sem explicação.

A mensagem documentada é “Rejeição: Ano e mês referência do período de apuração superior ao ano e mês atual [nItem: 999]”. Preserve o retorno real e identifique o item indicado no arquivo. O número 999 é o marcador da documentação; a identificação efetiva vem da resposta daquela tentativa.

Qual informação a regra compara

Na NT 2025.002-RTC v1.52 preservada, a UB132-10, página 67, corresponde à NF-e modelo 55. A condição começa quando é informado gCredPresIBSZFM/competApur. A rejeição descrita ocorre se o ano e mês informado for superior ao ano e mês atual. [1]

competApur é a referência do período de apuração dentro do grupo de crédito presumido de IBS sobre o saldo devedor na ZFM. Não é uma data de previsão de entrega, um vencimento de cobrança ou uma programação de faturamento. A 1160 não manda comparar esse campo com a data de saída ou com a data de emissão da nota.

A linha usa a expressão “ano/mês atual”, mas não detalha ali o fuso ou o relógio adotado na avaliação concreta. Este guia não presume que a data do computador seja a referência do autorizador nem simula esse relógio.

Competência e demais dados do grupo

O leiaute da página 28 apresenta competApur no formato AAAA-MM, com orientação de informar período atual ou retroativo. É uma referência de ano e mês, sem dia naquele campo. Uma informação com ano incorreto pode apontar para o futuro mesmo quando o número do mês parece familiar. [1]

No mesmo grupo aparecem tpCredPresIBSZFM, a classificação para o cálculo do crédito, e vCredPresIBSZFM, seu valor. Cada informação tem função própria. Trocar classificação, valor ou tipo da nota não corrige automaticamente a competência transmitida.

A possibilidade documental de período retroativo não autoriza selecionar qualquer mês passado. O período precisa representar a apuração real e seu uso deve atender aos requisitos fiscais aplicáveis. A 1160 não comprova direito ao crédito ou cabimento da emissão.

Preserve os arquivos antes de corrigir

Guarde XML transmitido, retorno integral, chave, horário e versão do emissor. Registre UF, autorizador, serviço e ambiente. Confirme se a mensagem veio da SEFAZ ou de uma validação interna e se os arquivos correspondem à mesma tentativa.

Localize competApur no item indicado e compare com os registros que sustentam a apuração. Depois confira cadastro, importação e configuração que alimentaram a geração. Uma tela corrigida depois do envio não demonstra que o arquivo rejeitado já continha o período correto.

A competência pode ter sido digitada incorretamente, importada de outro registro ou preenchida por uma rotina que seleciona um período planejado. Trate essas possibilidades como hipóteses. Não atribua uma falha ao operador, ao ALRA ou ao autorizador sem demonstrar a origem.

Correção conforme o cenário comprovado

O ano ou mês foi digitado ou importado incorretamente

Peça ao responsável fiscal para confirmar o período dos registros de apuração. Se houver erro material demonstrado, corrija a informação na origem e regenere o XML pelo emissor. Preserve o arquivo anterior e a documentação usada na correção.

Não use a competência atual como resposta automática. Ela só é a correção cabível se corresponder ao dado fiscal real. Um documento pode precisar representar período anterior, e a análise não deve se apoiar apenas no desaparecimento da rejeição.

A origem está correta, mas a integração envia outro período

Compare os dados antes e depois do mapeamento. Verifique seleção do registro, transporte de ano e mês e versão da integração. Procure reutilização de informações de outro item ou escolha automática do período seguinte.

Com a divergência demonstrada, o suporte deve corrigir a geração e conferir o valor efetivamente serializado. Não edite manualmente um XML assinado nem compense o erro alterando data de emissão, saída ou outro fato fiscal.

A competência pretendida está realmente no futuro

Não transforme esse período em atual ou retroativo por conveniência. Encaminhe a situação ao responsável fiscal para definir o procedimento cabível, considerando natureza da apuração, vigência e condições de utilização.

Um período planejado ainda não comprova apuração ou direito de apropriação. Este artigo não determina quando aquela emissão poderá ser feita nem promete que esperar uma mudança de mês garantirá autorização.

O período parece correto e o retorno permanece

Confirme o XML da tentativa efetiva, o item, o serviço, o ambiente e a versão documental. Registre a data e hora da tentativa e preserve a resposta para análise da referência temporal usada naquele atendimento.

Se houver dúvida em uma transição de calendário, peça ao suporte para investigar com esses registros. Não altere o relógio do computador ou do servidor para tentar passar. Tampouco conclua que o relógio do autorizador esteja errado com base somente na tela local.

Exemplo fictício de investigação

Em uma simulação documental de cenário em que a emissão fosse cabível, os registros da apuração identificam um período, mas a integração busca a competência de um planejamento posterior. A equipe compara a origem fiscal com o XML e demonstra a diferença.

O suporte corrige a seleção do registro e regenera o documento com o período confirmado para o exemplo, mantendo os arquivos anteriores. A ilustração explica uma falha de transporte de dados; não representa atendimento real, teste de implantação, direito ao crédito ou uma simulação do relógio do autorizador.

Se o período posterior fosse o dado fiscal pretendido, a equipe precisaria resolver seu cabimento. Não bastaria substituí-lo por uma referência anterior.

Calendário documental e alcance da análise

As capturas compartilhadas de 10/10/2026 registraram publicação da v1.52 em 01/10 e aviso ENCAT de 05/10. As alterações citadas com homologação prevista para 05/out foram postergadas para 26/10 em homologação e 16/11 em produção. Esse calendário geral não prova suspensão de todas as regras herdadas nem ativação individual da 1160. [2]

A UB132-10 examinada não apresenta observação própria de implementação futura. Isso não certifica aplicação uniforme por UF, autorizador ou ambiente. A observação de 2027 na página pertence ao crédito suspensivo da CBS em outra linha, não ao início dessa validação.

As regras sobre presença do grupo, tipo da nota, CST e classificação são verificações distintas. A 1160 analisa a competência informada; ela não substitui essas outras análises. Não houve consulta normativa nova, emissão de teste ou validação completa do XSD nesta elaboração.

Como confirmar o resultado e escalar

Depois da correção comprovada, confira o período no XML regenerado e leia o retorno completo. Só registre autorização com resultado válido e protocolo correspondente à chave. Outra rejeição exige investigação própria.

Envolva o suporte nas divergências entre origem e XML e a contabilidade nas dúvidas sobre período ou direito fiscal. Registre a causa e a informação corrigida, sem prometer autorização pela simples alteração da competência.

Fontes

Elaboração documental por IA em 12/10/2026, sem revisão própria, cruzada ou aprovação nesta etapa. Capturas históricas compartilhadas de 10/10 e leitura local atual; PNG documental existente da página 67 reaberto. Sem novo HTTP ou render.

1. NT 2025.002-RTC v1.52: página 67, UB132-10; página 28, UB132/competApur e campos do grupo. Referência v1.51 histórica não utilizada como prova normativa atual.

2. Documentos SVRS e Avisos SVRS: publicação e cronograma geral históricos.

3. TecnoSpeed, panorama RTC e Tax360, alterações RTC: dois apoios gerais adjacentes; não demonstrados três tutoriais específicos da 1160 nos corpos lidos. Provas e limites em fontes.v1.json.