Rejeições fiscais
Rejeição 876: corrija o campo do FCP na operação interestadual
A rejeição 876 exige conferir onde o emissor informou o Fundo de Combate à Pobreza no item da NF-e. Em uma operação interestadual para consumidor final não contribuinte, o FCP devido ao destino deve ser representado no campo próprio. Uma configuração que reutiliza os campos das vendas internas pode gerar a informação…
A rejeição 876 exige conferir onde o emissor informou o Fundo de Combate à Pobreza no item da NF-e. Em uma operação interestadual para consumidor final não contribuinte, o FCP devido ao destino deve ser representado no campo próprio. Uma configuração que reutiliza os campos das vendas internas pode gerar a informação em outro lugar.
Comece pelo XML que recebeu a rejeição e pelo número do item indicado na resposta. A mensagem não determina uma alíquota nem comprova que o produto está sujeito ao FCP. Para corrigir, é necessário separar o enquadramento fiscal da operação do mapeamento dos campos no emissor.
Quando a regra 876 se aplica
No MOC 7.0, Anexo I, a regra N17c-20 é obrigatória para a NF-e, modelo 55, quando as quatro condições estão reunidas:
operação interestadual, com
idDest=2;consumidor final, com
indFinal=1;destinatário não contribuinte, com
indIEDest=9;valor do FCP informado no campo
vFCPdo item.
A observação da regra orienta que o FCP do destino, quando existir, seja informado em vFCPUFDest, identificado como NA13. A linha não acrescenta um teste de valor maior que zero. Por isso, simplesmente substituir o conteúdo de vFCP por zero não demonstra que o preenchimento indevido desapareceu. [1]
Também não acrescente uma condição de finalidade normal da nota: esse requisito aparece em outra validação vizinha, referente ao cálculo do FCP. A 876 trata das quatro condições acima. O modelo 55 consta no MOC posterior; o rótulo histórico 55/65 da NT 2016.002 v1.61 não deve ampliar este roteiro para NFC-e. [1][2]
Confira o significado de cada campo
vFCPUFDest é o valor monetário do FCP para a UF de destino, dentro de ICMSUFDest. Nesse grupo, a base aparece em vBCFCPUFDest e o percentual em pFCPUFDest. Base, percentual e valor são informações separadas; não devem ser colocadas juntas em um único campo chamado “FCP”. [1]
O vFCP do grupo de ICMS e os valores de FCP-ST pertencem a contextos próprios. Não transfira uma retenção por substituição tributária para o destino por semelhança de nome. Preserve ainda a separação entre FCP e o ICMS do destino: uma parcela não deve ser somada à outra apenas para completar o XML.
Uma nota pode conter vFCPUFDest corretamente e continuar com vFCP indevido no mesmo item. Acrescentar o campo de destino, sem corrigir a origem da duplicação, deixa a situação descrita pela N17c-20 presente.
Faça o diagnóstico com os dados transmitidos
Preserve o XML enviado, a resposta completa e a memória de cálculo. Identifique chave, ambiente, autorizador e horário da tentativa. Compare o item rejeitado com o pedido e com a configuração que efetivamente gerou aquele arquivo; uma alteração posterior no cadastro não modifica o XML já transmitido.
Confira modelo, origem, destino, eventual local de entrega, finalidade da compra e condição fiscal do destinatário. Verifique os três indicadores da regra e a presença dos campos de FCP. Se existir integração, investigue se ela reutilizou o mapeamento de outra operação ou manteve um valor que o emissor deveria recalcular.
Ter CNPJ não comprova, sozinho, que o cliente é contribuinte do ICMS. Também não basta um endereço em outra UF para resolver todos os elementos fiscais da emissão. Cadastros incorretos precisam ser ajustados com base nos documentos e nos fatos, sem trocar indFinal ou indIEDest somente para afastar a rejeição.
Corrija conforme a incidência confirmada
Se o responsável fiscal confirmar FCP devido ao destino, confira base, percentual e valor aplicáveis ao produto, à operação, à UF e à data. Em seguida, ajuste a configuração que gera os campos: a parcela deve aparecer no contexto correto, sem permanecer duplicada indevidamente em vFCP.
Não copie uma alíquota de um tutorial nem suponha que todo item da nota terá o mesmo tratamento. Os demais produtos devem ser conferidos individualmente. Uma rotina que remove todos os valores de FCP pode apagar informações corretas de itens com situações diferentes.
Se não houver incidência, investigue por que o emissor gerou o campo. Corrija o parâmetro ou a integração responsável pelo preenchimento indevido. Essa conclusão não permite apagar automaticamente todo o grupo ICMSUFDest, cuja exigência e cujos demais valores seguem validações próprias.
Separe a 876 das regras do grupo de destino
A rejeição 694, regra NA01-20, trata da ausência de ICMSUFDest e possui condições e exceções próprias. A NT 2022.005 apresenta essa disciplina. Uma exceção dessa regra não é, por si só, exceção à N17c-20. A presença de um grupo exigido e a posição correta de um valor são verificações diferentes. [3]
Há também restrição atual ao próprio grupo: a NT 2026.002 v1.11, na NA01-10/807, veda ICMSUFDest na NFC-e e na NF-e com DANFE Simplificado Tipo 2, identificada por tpImp=6. Portanto, acrescentar esse grupo indiscriminadamente não é solução para qualquer documento. Confira primeiro o modelo e a modalidade realmente utilizados. [4]
Os cronogramas precisam ser lidos por regra. A reativação da NA01-20 teve previsão de produção corrigida para 03/04/2023. A alteração da NT 2022.005 v1.11 relativa ao comércio exterior e à 3BA02-50 tem outro objeto. Nenhuma delas estabelece uma nova data ou dispensa geral para a rejeição 876. [3]
Exemplo de uma associação incorreta
Uma empresa fictícia vende mercadoria a consumidor final não contribuinte de outra UF. O fiscal confirma FCP devido ao destino e fornece a memória de cálculo. A integração recebe os dados, mas associa o valor a vFCP, porque aproveitou o mapeamento usado em vendas internas. O retorno aponta 876 no item 2.
A equipe confirma os indicadores, corrige a associação e regenera a nota. Confere base, percentual e valor nos campos do destino, além da retirada do preenchimento indevido no outro contexto. O destinatário e os fatos da operação permanecem os mesmos. O exemplo ilustra um erro de geração; não determina a incidência de uma mercadoria real.
Regenere e confira a resposta
Faça a correção na origem e utilize o fluxo normal de geração e assinatura do emissor. Não altere diretamente um XML assinado. Compare os grupos e os totalizadores antes de transmitir novamente, evitando valores duplicados ou totais conservados da tentativa anterior.
Leia a resposta completa da nova tentativa. O desaparecimento da 876 não comprova autorização; outra mensagem exige diagnóstico próprio. Quando autorizada, preserve a NF-e e seu protocolo. Se os parâmetros fiscais estiverem confirmados, mas o arquivo continuar diferente, encaminhe ao suporte XML, retorno, ambiente e memória de cálculo para localizar a origem da divergência.
Fontes
Referências consultadas em 15/10/2026. O roteiro é documental; a incidência e o cálculo da operação concreta dependem da análise fiscal aplicável.
MOC 7.0 — Anexo I, páginas 49–50 e 111: grupo de destino e N17c-20.
NT 2016.002 v1.61, página 60: redação histórica da regra.
NT 2022.005 v1.11, páginas 2–5: NA01-20 e cronogramas; aviso oficial de publicação.
NT 2026.002 v1.11, página 17: restrição NA01-10/807.
Apoios práticos específicos: Treeunfe, InvoiSys e IOB. Telas e automatizações desses emissores não descrevem o funcionamento do ALRA.