Nota Fiscal de Serviços Eletrônica Nacional (NFS-e)

1. Objetivos deste documento

O presente documento tem por objetivo principal guiar os Contribuintes domiciliados nos municípios aderentes à Nota Fiscal de Serviço Eletrônica Nacional (NFS-e) quanto à utilização do WebService no Padrão NFS-e Nacional disponibilizado por esta empresa. Desse modo, espera-se que ao final o contribuinte esteja orientado quanto ao serviço disponibilizado e suas possibilidades de uso.

2. O que é a NFS-e Nacional?

A NFS-e Nacional consiste na criação de um leiaute único de documento fiscal, de forma a padronizar os potenciais 5.570 modelos de notas fiscais de serviço existentes no país. Os objetivos principais da adoção de um padrão para o adimplemento das obrigações acessórias no setor de serviços consistem não só na melhoria do ambiente de negócios no país, mas também de uma maior integração entre as administrações tributárias das esferas municipal, distrital e federal, gerando a racionalização de recursos governamentais, maior eficiência na atividade fiscal e melhores serviços aos cidadãos.

3. Processo de emissão da NFS-e Nacional

Este processo se baseia nos seguintes passos:

  1. Preenchimento e envio do arquivo por parte do contribuinte.
  2. Validação e envio do arquivo para o Portal da Nota Nacional.
  3. Recepção da NFS-e no sistema tributário municipal com a autenticação da NFS-e Nacional.

4. Funcionalidades Disponíveis

4.1 Geração da NFS-e

Responsável por receber os dados referentes a uma prestação de serviços, validar e gravar na base da Administração Tributária Municipal, gerando a NFS-e. Caso haja alguma inconsistência, uma mensagem de erro é retornada ao requisitante. Este processo é síncrono e não permite envio em lote nem via arquivo texto (.txt).

4.2 Cancelamento da NFS-e

Efetua o cancelamento de uma NFS-e já emitida e integrada com o sistema Tributário Municipal. Se a nota já estiver cancelada ou inexistente, será retornada uma mensagem informando o fato. O cancelamento é individual e não se vincula a RPS ou nota substituta. Este processo é síncrono.

4.3 Substituição da NFS-e

Gera uma nova NFS-e em substituição à anterior, cancelando a nota substituída (caso ainda não esteja). Utiliza a mesma estrutura da geração, adicionando os campos que identificam a nota substituída e o motivo da substituição. Este processo também é síncrono.

4.4 Consulta da NFS-e

Retorna o XML da nota fiscal consultada pela número da chave de acesso ou número do DPS informando na emissão via webservice. Este processo também é síncrono.

5. Padrões Técnicos

A troca de mensagens entre o Web Service do Sistema de Notas Fiscais de Serviço Eletrônicas e o sistema do contribuinte será realizada no padrão SOAP, com troca de mensagens XML estilo Document/Literal. O WSDL (Web Service Description Language) é utilizado para descrever os serviços disponíveis.

5.1 Padrão de Certificado Digital

O certificado digital deve ser emitido por Autoridade Certificadora credenciada pela ICP-Brasil, tipo A1 ou A3. Ele é exigido tanto na transmissão quanto na assinatura de documentos, contendo o CNPJ ou CPF do emitente conforme o tipo de certificado.

5.2 Padrão de Assinatura Digital

As NFS-e enviadas devem ser assinadas digitalmente conforme o padrão XML Signature definido pelo W3C. O esquema XML utilizado é o xmldsig-core-schema_v1.01.xsd.

6. Estrutura dos dados

Os campos para preenchimento do XML de emissão da NFS-e está na aba "LEIAUTE DPS_NFS-e" da planilha disponível no link: acessar documentação

Os campos para preenchimento do XML de envio de Cancelamento ou Substituição da NFS-e está disponível no link: acessar documentação

7. Modelos dos XMLs

7.1 Modelo de emissão nota fiscal

Disponíveis no link: Visualizar XML

7.2 Modelo de cancelamento nota fiscal

Disponíveis no link: Visualizar XML

7.3 Modelo substituição nota fiscal

Disponíveis no link: Visualizar XML

7.4 Modelo consulta da nota fiscal

Disponíveis no link: Visualizar XML

8. Orientações Emissão Manual

As orientações quanto a emissão manual via sistema municipal está disponível no link: acessar documentação

9. Atualizações e Perguntas frequentes

9.1 Como devo preencher o campo “ID” da tag NFSe/infNFSe?

O campo ID deve ser preenchido com um identificador iniciado pelo literal “ID”, seguido da composição obrigatória de 53 posições, conforme padrão nacional da NFS-e.

Estrutura do Identificador (53 posições):

9.2 Como preencher a posição 8 do Código Numérico Sequencial de 9 posições do campo “ID”?

O código numérico sequencial deve:

9.3 Como calcular o dígito verificador?

O dígito verificador (DV) é calculado utilizando o método do Módulo 11, que garante maior segurança e evita erros de digitação.

Passo a passo do cálculo:

  1. Pegue o número base.
    Exemplo: 12345
  2. Aplique os pesos (2 a 9), da direita para a esquerda, repetindo se necessário.
  3. Multiplique cada dígito pelo respectivo peso e some os resultados.
    10 + 12 + 12 + 10 + 6 = 50
  4. Divida a soma por 11 e obtenha o resto:
    50 ÷ 11 → resto = 6
  5. Calcule o DV usando a regra:
    Se o resto for 0, 1 ou 10 → DV = 0
    Caso contrário → DV = 11 – resto

Para o exemplo:
DV = 11 – 6 = 5
✔ Dígito verificador final: 5

9.4 Possibilidades de situações quando ocorrer a rejeição “E1235 – Falha no esquema XML do DF-e.”

A rejeição E1235 indica que o XML não está aderente ao esquema XSD oficial.

Possíveis causas:

a) Ordem incorreta das tags
A estrutura deve seguir exatamente o layout nacional.

b) Campos obrigatórios ausentes
Exemplo: ausência da tag Bairro ou menção da tag sem valor atribuído.

c) Campos fora do padrão exigido

d) Estrutura XML mal formatado

9.5 Quando serão disponibilizados os campos referentes ao IBS/CBS?

Quanto aos testes no envio das informações de CBS e IBS, o CGNFSe disponibilizou, no dia 19 de novembro de 2025, a Nota Técnica SE/CGNFS-e nº 005/2025, juntamente com o novo layout Anexo VI – LeiautesRN_RTC_IBSCBS-V1.01.02, que inclui os grupos “IBSCBS”.

Entretanto, nos testes em Produção Restrita, ocorre rejeição porque o SERPRO ainda não realizou as adaptações necessárias.

➡ Somente após o SERPRO concluir as adequações será possível iniciar os testes desses campos.

9.6 Implementação das validações das regras municipais

Os envios via WebService passarão a ter as mesmas validações aplicadas na emissão manual da prefeitura.

Cronograma:

As regras municipais envolvem obrigatoriedade de campos, validações de valores e permissões específicas de cada município.

9.7 Implementação das alterações para atender a NT 007

A partir de 09/02/2026, estão vigentes as alterações previstas na Nota Técnica NT 007.

PIS/COFINS
Os campos “vPis” e “vCofins” passam a ser apenas informativos (débitos próprios), não tratando retenção.

Código da Situação Tributária
Acrescentados os códigos 49 a 99.

Tipo de Retenção PIS/COFINS e CSLL
Acrescentados os códigos 0 e 3 a 9.
OBS: Os códigos 1 e 2 serão removidos após obrigatoriedade do grupo IBSCBS.

Valor Relativo às Retenções de Contribuições Sociais
Se houver retenções de PIS, COFINS e/ou CSLL, deverão ser somadas e informadas no campo “vRetCSLL”, conforme “tpRetPisCofins”.
➡ Reforçando: “vPis” e “vCofins” não devem ser utilizados para informar valores retidos.

9.8 Como calcular o valor líquido da nota?

O valor líquido da nota (tag vLiq) é o resultado da operação: "Valor do serviço - Desconto condicionado - Desconto incondicionado - Valores retidos (vTotalRet)". Deste modo, os campos utilizados do XML para esta operação são:

Valor do serviço
Valor informado na tag "vServ"
(caminho no XML: NFSe/infNFSe/DPS/infDPS/valores/vServPrest/vServ).

Desconto condicionado
Valor informado na tag "vDescCond"
(caminho no XML: NFSe/infNFSe/DPS/infDPS/valores/vDescCondIncond/vDescCond).

Desconto incondicionado
Valor informado na tag "vDescIncond"
(caminho no XML: NFSe/infNFSe/DPS/infDPS/valores/vDescCondIncond/vDescIncond).

Valores retidos
Somatória dos valores informados nas tag:
"vRetCP" (caminho no XML: NFSe/infNFSe/DPS/infDPS/valores/trib/tribFed/vRetCP)
"vRetIRRF" (caminho no XML: NFSe/infNFSe/DPS/infDPS/valores/trib/tribFed/vRetIRRF)
"vRetCSLL" (caminho no XML: NFSe/infNFSe/DPS/infDPS/valores/trib/tribFed/vRetCSLL)
"vISSQN" (caminho no XML: NFSe/infNFSe/valores/vISSQN - somar apenas quando houver retenção do ISS).

9.9 Grupo de informações para totais aproximados dos tributos (tag "totTrib")

Não será aceito o envio de valores nas tag "vTotTribFed" ou "pTotTribFed" sem a discriminação desses valores nas tag "vRetCP", "vRetIRRF" e "vRetCSLL", ou seja, para informar o total ou percentual destes tributos é preciso discrimina-los nos campos devidos.

9.10 Origem da rejeição

Nos casos onde houver retorno de "erro" e iniciar por "Rejeitado pelo Emissor Nacional", significa que quem recusou o envio é o NACIONAL (sistema do emissor nacional).

Nos demais casos em que houver retorno de "erro" e não iniciar por "Rejeitado pelo Emissor Nacional", significa que quem recusou o envio é a PREFEITURA (sistema tribuário municipal).