Manual de Orientação ao Contribuinte da Nota Fiscal Eletrônica de Alienação de Bens Imóveis

1. Introdução

2. Considerações Iniciais

A NF-e de Alienação de Bens Imóveis (NF-e ABI) é o documento emitido e armazenado eletronicamente, de existência apenas digital, cuja validade jurídica é garantida pela assinatura digital do emitente e autorização de uso pelo ambiente nacional da NF-e ABI.

2.1. Objetivos do Projeto

O Projeto NF-e ABI tem como objetivo a implantação de um modelo nacional de documento fiscal eletrônico, identificado pelo modelo 77, visando atender à Lei Complementar 214/2025, com validade jurídica garantida pela assinatura digital do emitente.

2.2. Conceitos

2.2.1. NF-e ABI (Modelo 77)

A NF-e ABI é um documento de existência exclusivamente digital, emitido e armazenado eletronicamente, com o intuito de documentar uma operação sujeita ao IBS/CBS.

2.2.2. Chave de Acesso

A Chave de Acesso de identificação da NF-e ABI é um conjunto de 44 caracteres numéricos, formado pela concatenação de campos que se encontram no leiaute da NF-e, seguindo a estrutura apresentada na Tabela 2-1.

O Dígito Verificador (DV) irá garantir a integridade da chave de acesso, protegendo-a principalmente contra digitações erradas.

O cálculo do Dígito Verificador da Chave de Acesso da NF-e ABI deverá respeitar o mesmo cálculo feito para os demais documentos fiscais eletrônicos, conforme a DFe NTCJ 2025.001_CNPJ Alfa_v1.00.

2.2.3. Chave Natural

A identificação única de uma nota fiscal para efeitos tributários é feita pelos seguintes conjuntos de informações, que são um subconjunto das informações existentes na chave de acesso:

• NF-e ABI: UF, CNPJ ou CPF do emitente, série e número da NF-e, modelo do documento fiscal eletrônico, ambiente de autorização e site de autorização.

Estes subconjuntos recebem a denominação de “chave natural”.

O Sistema de Autorização de Uso valida a existência de uma NF-e ABI previamente autorizada e rejeita novos pedidos de autorização para NF-e ABI caso seja identificada duplicidade de Chave Natural.

2.2.4. Responsável Técnico

Responsável Técnico é a empresa desenvolvedora ou a empresa responsável tecnicamente pelo sistema (software) de emissão utilizado pelo emitente. Essa informação será utilizada pelas Administrações Tributárias.

Em caso de sistema de emissão de NF-e ABI de desenvolvimento próprio, o responsável técnico é o próprio emitente.

2.3. Descrição Simplificada do Modelo Operacional da NF-e ABI

2.3.1. Autorização de Uso

O emissor da NF-e ABI gera um arquivo eletrônico contendo as informações da operação, o qual deverá ser assinado digitalmente, transformando este arquivo em um documento eletrônico nos termos da legislação brasileira, de maneira a garantir a integridade dos dados e a autoria do emissor.

Este arquivo eletrônico será transmitido pela Internet para a Administração Tributária, que, após verificar a integridade formal, devolverá um protocolo de recebimento denominado “Autorização de Uso”.

Após a Autorização de Uso, que transforma o documento eletrônico no Documento Fiscal denominado NF-e ABI, a Administração Tributária disponibilizará consulta, através da Internet, para o adquirente e outros legítimos interessados que conheçam a chave de acesso do documento eletrônico.

2.3.2. Modalidades de Emissão

Em um cenário de falha que impossibilite a emissão da NF-e ABI na modalidade normal, o emissor poderá escolher a modalidade de emissão de contingência, ou aguardar a regularização da situação para voltar a emitir a NF-e ABI na modalidade normal.

2.3.2.1. Emissão Normal

O processo de emissão normal é a situação desejada e mais adequada para o emissor, pois é a situação em que todos os recursos necessários para a emissão da NF-e ABI estão operacionais e a autorização de uso da NF-e ABI é concedida normalmente.

Nesta situação, a emissão das NF-e ABI é realizada normalmente, sendo que os respectivos documentos auxiliares somente podem ser gerados após o emitente ter recebido a autorização de uso.

A modalidade alternativa é detalhada no capítulo 6. Contingência.

3. Eventos

Um evento é o registro de uma ocorrência relacionada com um documento fiscal eletrônico.

O evento pode modificar a situação do documento, por exemplo, por cancelamento.

O Sistema de Registro de Eventos da NF-e (SRE) é o modelo genérico que permite o registro da ocorrência por ator que pratica ou recepciona qualquer ocorrência que tenha vinculação ou interesse para a NF-e ABI.

Existe um único Web Service com a funcionalidade de tratar eventos de forma genérica, para facilitar a criação de novos eventos sem a necessidade de criação de novos serviços e com poucas alterações na aplicação de Registro de Eventos do Ambiente Autorizador.

O modelo de mensagem de registro de evento possui o seguinte conjunto mínimo de informações comuns:

• Identificação do autor do registro;
• Identificação do evento;
• Identificação da NF-e ABI vinculada;
• Informações específicas do evento;
• Assinatura digital da mensagem.

O leiaute da mensagem de Registro de Evento contém uma parte genérica, comum a todos os tipos de evento, e uma parte específica onde será inserido o XML correspondente a cada tipo de evento em uma tag do tipo any.

O Pacote de Liberação de schemas da NF-e ABI contém o leiaute da parte genérica do Registro de Eventos e um schema para cada leiaute específico dos eventos definidos neste manual.

4. Arquitetura de Comunicação com Emitente

4.1. Modelo Conceitual

As Administrações Tributárias disponibilizam os seguintes serviços:

• Recepção de NF-e ABI;
• Consulta da situação atual da NF-e ABI;
• Consulta do status do serviço;
• Registro de eventos.

Para cada serviço oferecido existe um Web Service específico. O fluxo de comunicação é sempre iniciado pelo aplicativo do emitente através do envio de uma mensagem ao Web Service com a solicitação do serviço desejado.

O Web Service devolve uma mensagem de resposta confirmando o recebimento da solicitação de serviço ao aplicativo do emitente na mesma conexão.

4.2. Padrões Técnicos

4.2.1. Padrão de Documento XML

4.2.1.1. Padrão de Codificação

A especificação do documento XML adotada é a recomendação W3C para XML 1.0, disponível em www.w3.org/TR/REC-xml, e a codificação dos caracteres é UTF-8; assim, todos os documentos XML devem iniciar com a seguinte declaração:

<?xml version="1.0" encoding="UTF-8"?>

Cada arquivo XML somente poderá ter uma única declaração <?xml version="1.0" encoding="UTF-8"?>. Nas situações em que um documento XML pode conter outros documentos XML, deve-se tomar cuidado para que exista uma única declaração.

4.2.1.2. Declaração namespace

O documento XML deverá ter uma única declaração de namespace no elemento raiz do documento com o seguinte padrão:

xmlns="http://www.portalfiscal.inf.br/nfeabi"

É vedado o uso de declaração namespace diferente do padrão estabelecido.

Para reduzir o tamanho final do arquivo XML da NF-e ABI, alguns cuidados de programação deverão ser assumidos:

• não incluir zeros não significativos para campos numéricos;
• não incluir espaços no início ou no final de campos numéricos e alfanuméricos;
• não incluir comentários no arquivo XML;
• não incluir anotação e documentação no arquivo XML (TAG annotation e TAG documentation);
• não incluir caracteres de formatação no arquivo XML (line-feed, carriage return, tab e caractere de espaço entre as TAGs);
• não incluir prefixo no namespace das tags de NFe.

4.2.1.3. Validação de Schema

Para garantir minimamente a integridade das informações prestadas e a correta formação dos arquivos XML, o emitente deverá, antes de seu envio, submeter o arquivo da NF-e ABI e as demais mensagens XML para validação pelo Schema do XML (XSD - XML Schema Definition), disponibilizado pela Administração Tributária.

4.2.1.4. Tratamento de Caracteres Especiais no Texto de XML

Todos os textos de um documento XML passam por uma análise do parser específico da linguagem. Alguns caracteres afetam o funcionamento deste parser, não podendo aparecer no texto de uma forma não controlada.

Alguns destes caracteres podem aparecer especialmente no campo de Razão Social, Endereço e Informação Adicional. Para resolver esses casos, é recomendável o uso de uma sequência de escape em substituição ao caractere que causa o problema.

Exemplo: a denominação DIAS & DIAS LTDA deve ser informada como DIAS & DIAS LTDA no XML para não afetar o funcionamento do parser.

Nota: a sequência de escape conta como um único caractere para a validação do tamanho do campo pelo Schema.

4.2.2. Padrão de Comunicação

A comunicação será baseada em Web Services disponibilizados pelo Sistema de Recepção de Nota Fiscal Eletrônica.

O meio físico de comunicação utilizado será a Internet, com o uso do protocolo TLS 1.2 ou superior, com autenticação mútua, que, além de garantir um duto de comunicação seguro na Internet, permite a identificação do servidor e do cliente através de certificados digitais, eliminando a necessidade de identificação do usuário através de nome ou código de usuário e senha.

O modelo de comunicação segue o padrão de Web Services definido pelo WS-I Basic Profile.

A troca de mensagens entre os Web Services do ambiente do Sistema de Recepção da NF-e e o aplicativo da empresa será realizada no padrão SOAP versão 1.2, com troca de mensagens XML no padrão Style/Encoding: Document/Literal.

A chamada de diferentes Web Services é realizada com o envio de uma mensagem XML através do parâmetro nfeDadosMsg.

4.2.3. Padrão de Certificado Digital

O certificado digital utilizado no Sistema NF-e ABI será emitido por Autoridade Certificadora credenciada pela Infraestrutura de Chaves Públicas Brasileira - ICP-Brasil, tipo A1 ou A3, devendo conter o CNPJ da pessoa jurídica titular do certificado digital no campo OtherName OID=2.16.76.1.3.3 ou o CPF da pessoa física titular do certificado digital no campo OtherName OID=2.16.76.1.3.1.

Os certificados digitais serão exigidos em 2 (dois) momentos distintos:

• Assinatura de Mensagens: o certificado digital utilizado para essa função deverá conter o CNPJ/CPF de um emitente da NF-e ABI.
  • Por mensagens, entenda-se: o Pedido de Autorização de Uso (Arquivo NF-e ABI), o Pedido de Cancelamento de NF-e ABI, o Registro de Evento e demais arquivos XML que necessitem de assinatura.
  • O certificado digital deverá ter o “uso da chave” previsto para a função de assinatura digital, respeitando a Política do Certificado.
• Transmissão: durante a transmissão das mensagens entre o servidor do emitente e a Administração Tributária, o certificado digital utilizado para identificação do aplicativo do emitente deverá conter o CNPJ/CPF do responsável pela transmissão das mensagens, que não será necessariamente o CNPJ/CPF da empresa emissora da NF-e ABI, devendo ter a extensão Extended Key Usage com permissão de “Autenticação Cliente”.

4.2.4. Padrão de Assinatura Digital

As mensagens enviadas ao Portal da Administração Tributária são documentos eletrônicos elaborados no padrão XML e devem ser assinados digitalmente com um certificado digital que contenha o CNPJ/CPF do emissor da NF-e ABI objeto do pedido.

Alguns elementos estão presentes dentro do Certificado do emitente, tornando desnecessária a sua representação individualizada no arquivo XML. Portanto, o arquivo XML não deve conter os elementos:

<X509SubjectName>
<X509IssuerSerial>
<X509IssuerName>
<X509SerialNumber>
<X509SKI>

Deve-se evitar o uso das TAGs abaixo, pois as informações serão obtidas a partir do Certificado do emitente:

<KeyValue>
<RSAKeyValue>
<Modulus>
<Exponent>

A NF-e ABI utiliza um subconjunto do padrão de assinatura XML definido pelo W3C XML Signature, com o seguinte leiaute:

Schema XML: xmldsig-core-schema_v1.01.xsd

A assinatura do emitente na NF-e ABI será feita na TAG <infNFeABI> identificada pelo atributo Id, cujo conteúdo deverá ser um identificador único (chave de acesso) precedido do literal NFeABI para cada NF-e, conforme leiaute descrito no documento MOC NFe ABI Anexo I Leiaute e RV. O identificador único precedido do literal #NFeABI deverá ser informado no atributo URI da TAG <Reference>. Para as demais mensagens a serem assinadas, o processo é o mesmo, mantendo sempre um identificador único para o atributo Id na TAG a ser assinada.

<NFeABI xmlns="http://www.portalfiscal.inf.br/nfeabi">
  <infNFeABI Id="NFeABI31060243816719000108550000000010001234567897" versao="1.01">
    ...
  </infNFeABI>
  <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
    <SignedInfo>
      <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
      <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
      <Reference URI="#NFeABI31060243816719000108550000000010001234567897">
        <Transforms>
          <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
          <Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
        </Transforms>
        <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
        <DigestValue>vFL68WETQ+mvj1aJAMDx+oVi928=</DigestValue>
      </Reference>
    </SignedInfo>
    <SignatureValue>IhXNhbdL1F9UGb2ydVc5v/gTB/y6r0KIFaf5evUi1i ...</SignatureValue>
    <KeyInfo>
      <X509Data>
        <X509Certificate>MIIFazCCBFOgAwIBAgIQaHEfNaxSeOEvZGlVDANB ...</X509Certificate>
      </X509Data>
    </KeyInfo>
  </Signature>
</NFeABI>

Para o processo de assinatura, o emitente não deve fornecer a Lista de Certificados Revogados, já que a mesma será montada e validada no momento da conferência da assinatura digital.

4.2.5. Validação de Assinatura Digital pela Administração Tributária

O procedimento para a validação da assinatura digital é:

1. Extrair a chave pública do certificado;
2. Verificar o prazo de validade do certificado utilizado;
3. Montar e validar a cadeia de confiança dos certificados, validando também a LCR (Lista de Certificados Revogados) de cada certificado da cadeia;
4. Validar o uso da chave utilizada (Assinatura Digital) de tal forma a aceitar certificados somente do tipo A (não serão aceitos certificados do tipo S);
5. Garantir que o certificado utilizado é de um usuário final e não de uma Autoridade Certificadora;
6. Adotar as regras definidas pelo RFC 3280 para as LCR e cadeia de confiança;
7. Validar a integridade de todas as LCR utilizadas pelo sistema;
8. Verificar o prazo de validade de cada LCR utilizada (data inicial e final).

A forma de conferência da LCR pode ser feita de 2 (duas) maneiras: online ou por download periódico. As assinaturas digitais das mensagens serão verificadas considerando a lista de certificados revogados disponível no momento da conferência da assinatura.

4.2.6. Resumo dos Padrões Técnicos

4.2.7. Colunas das Tabelas de Leiaute de Mensagens

4.3. Modelo Operacional

A solicitação de serviço poderá ser atendida na mesma conexão, ou seja, os serviços são síncronos em função da forma de processamento da solicitação de serviços.

• Serviços síncronos: o processamento da solicitação de serviço é concluído na mesma conexão, com a devolução de uma mensagem com o resultado do processamento do serviço solicitado.

Os Web Services disponibilizam os serviços que serão utilizados pelos aplicativos dos emitentes. O mecanismo de utilização dos Web Services segue as seguintes premissas:

1. É disponibilizado um Web Service por serviço, existindo um método para cada tipo de serviço, com exceção do registro de eventos, que poderá ser atendido por Web Services diferentes conforme o tipo de evento;
2. Para os serviços síncronos, o envio da solicitação e a obtenção do retorno serão realizados na mesma conexão através de um único método;
3. As URL dos Web Services encontram-se disponíveis no Portal Nacional da NF-e ABI; mediante acesso à URL pode ser obtido o WSDL (Web Services Description Language) de cada Web Service;
4. O processo de utilização dos Web Services sempre é iniciado pelo emitente enviando uma mensagem nos padrões XML e SOAP, através do protocolo TLS com autenticação mútua;
5. A ocorrência de qualquer erro na validação dos dados recebidos interrompe o processo com a disponibilização de uma mensagem contendo o código e a descrição do erro.

4.3.1. Serviços Síncronos

As solicitações de serviços de implementação síncrona são processadas imediatamente e o resultado do processamento é obtido em uma única conexão, conforme o fluxo exposto na Figura 4-2.

Etapas do processo:

1. O aplicativo do emitente inicia a conexão enviando uma mensagem de solicitação de serviço para o Web Service;
2. O Web Service recebe a mensagem de solicitação de serviço e encaminha ao aplicativo da NF-e ABI que irá processar o serviço solicitado;
3. O aplicativo da NF-e ABI recebe a mensagem de solicitação de serviço e realiza o processamento, devolvendo uma mensagem de resultado do processamento ao Web Service;
4. O Web Service recebe a mensagem de resultado do processamento e o encaminha ao aplicativo do emitente;
5. O aplicativo do emitente recebe a mensagem de resultado do processamento e, caso não exista outra mensagem, encerra a conexão.

4.3.2. Número do Protocolo

O número do protocolo (nProt) é gerado pela Administração Tributária para identificar univocamente as transações realizadas de autorização de uso e autorização da NF-e ABI.

• 1 posição para indicar o Tipo Autorizador;
• 2 posições para o código da UF do IBGE;
• 2 posições para o ano;
• 1 posição para o número do Site que autorizou a NF-e ABI (0 para apenas um site);
• 10 posições para o sequencial no ano.

A geração do número de protocolo é única e é utilizada por todos os Web Services que precisam atribuir um número de protocolo para o resultado do processamento.

4.3.3. Ambientes de Homologação e de Produção

As Administrações Tributárias mantêm dois ambientes para recepção de NF-e ABI. O ambiente de homologação é específico para a realização de testes e integração das aplicações do emitente durante a fase de implementação e adequação do sistema de emissão de NF-e do emitente e nos casos em que este sistema sofre alterações após entrar em regime de operação normal.

A autorização de uso de NF-e ABI no ambiente de produção tem o efeito de permitir que o arquivo da NF-e ABI seja utilizado como documento fiscal.

O acesso a cada um dos ambientes será concedido mediante prévia requisição do emitente ou de ofício, caso seja de interesse da Administração Tributária.

4.4. Padrão de Mensagens dos Web Services

As chamadas dos Web Services disponibilizados pelos Web Services da NF-e ABI e os respectivos resultados do processamento são realizados através das mensagens com o padrão mostrado na Figura 4-3, onde:

• versaoDados: versão do leiaute da estrutura XML informado na área de dados;
• Área de Dados: estrutura XML variável definida na documentação do Web Service acessado.

4.4.1. Validação da Estrutura XML das Mensagens dos Web Services

As informações são enviadas ou recebidas dos Web Services através de mensagens no padrão XML definido na documentação de cada Web Service.

As alterações de leiaute e da estrutura de dados XML realizadas nas mensagens são controladas através da atribuição de um número de versão para a mensagem.

Um Schema XML é uma linguagem que define o conteúdo do documento XML, descrevendo os seus elementos e a sua organização, além de estabelecer regras de preenchimento de conteúdo e de obrigatoriedade de cada elemento ou grupo de informação.

A validação da estrutura XML da mensagem é realizada por um analisador sintático (parser) que verifica se a mensagem atende às definições e regras de seu Schema XML.

Qualquer divergência da estrutura XML da mensagem em relação ao seu Schema XML provoca um erro de validação do Schema XML.

A primeira condição para que a mensagem seja validada com sucesso é que ela seja submetida com êxito ao Schema XML correspondente.

Assim, os aplicativos do emitente devem estar preparados para gerar as mensagens no leiaute em vigor, devendo ainda informar a versão do leiaute da estrutura XML da mensagem no campo versaoDados da área de cabeçalho da mensagem.

4.4.2. Schemas XML das Mensagens dos Web Services

Toda mudança de leiaute das mensagens dos Web Services implica na atualização do seu respectivo Schema XML.

A maioria dos Schemas XML da NF-e ABI utiliza as definições de tipos básicos ou tipos complexos que estão definidos em outros Schemas XML (ex.: tiposBasico_v1.00.xsd). Nestes casos, a modificação de versão do Schema básico será repercutida no Schema principal.

Por exemplo, o tipo numérico de 15 posições com 2 decimais é definido no Schema tiposBasico_v1.00.xsd. Caso ocorra alguma modificação na definição deste tipo, todos os Schemas que utilizam este tipo básico devem ter a sua versão atualizada e as declarações import ou include devem ser atualizadas com o nome do Schema básico atualizado.

As modificações de leiaute das mensagens dos Web Services podem ser causadas por necessidades técnicas ou em razão da modificação de alguma legislação. As modificações decorrentes de alteração da legislação deverão ser implementadas nos prazos previstos no ato normativo que introduziu a alteração. As modificações de ordem técnica serão divulgadas pela Coordenação Técnica do Sistema e poderão ocorrer sempre que se fizerem necessárias.

4.5. Versão dos Schemas

4.5.1. Controle de Versão

O controle de versão de cada um dos schemas válidos compreende uma definição nacional sobre:

• qual a versão vigente (versão mais atualizada);
• quais são as versões anteriores ainda suportadas por todas as SEFAZ.

Este controle de versões permite a adaptação dos sistemas de informática das empresas participantes do Sistema em diferentes datas; desta forma, algumas empresas poderão estar com uma versão de leiaute mais atualizada, enquanto outras empresas poderão ainda estar operando com mensagens em um leiaute anterior.

Não existem mudanças frequentes de leiaute de mensagens e as empresas dispõem de um prazo razoável para implementar as mudanças necessárias, conforme acordo operacional estabelecido. Mensagens recebidas com uma versão de leiaute não suportada serão rejeitadas com uma mensagem de erro específica na versão do leiaute de resposta mais antiga em uso.

5. DANFE-ABI

O DANFE-ABI (Documento Auxiliar da Nota Fiscal Eletrônica) é um documento fiscal auxiliar, que pode ser impresso em papel; sua especificação e modelos de leiaute serão publicados em Nota Técnica.

O DANFE-ABI não é nota fiscal, nem a substitui, servindo apenas como instrumento auxiliar para consulta da NF-e ABI, pois contém a chave de acesso da NF-e ABI, que permite ao detentor desse documento confirmar a efetiva existência de uma NF-e que tenha tido seu uso regularmente autorizado.

O Anexo I define o campo relacionado ao formato de impressão:

6. Contingência

A obtenção da autorização de uso da NF-e ABI é um processo que envolve diversos recursos de infraestrutura, hardware e software. O mau funcionamento ou a indisponibilidade de qualquer um destes recursos pode prejudicar o processo de autorização da NF-e ABI, com reflexos nos negócios do emissor da NF-e ABI, que fica impossibilitado de obter a prévia autorização de uso da NF-e exigida na legislação para a emissão do DANFE-ABI para registro da alienação do bem imóvel.

A alta disponibilidade é uma das premissas básicas do sistema da NF-e ABI. Contudo, existem diversos outros componentes do sistema que podem apresentar falhas e comprometer a disponibilidade dos serviços, exigindo alternativas de emissão da NF-e ABI em contingência.

O Anexo I identifica a modalidade como contingência off-line e prevê o grupo de contingência abaixo:

7. QR Code

As informações suplementares da NF-e ABI incluem o texto com o QR Code impresso no DANFE-ABI e a URL de consulta por chave de acesso.

8. Consulta Pública da NF-e ABI

8.1. Consulta Completa da NF-e ABI

A Consulta Completa, individualmente realizada através da Internet nos portais das Administrações Tributárias, retornará todo o conteúdo da NF-e ABI, exclusivamente aos participantes da operação comercial descritos no documento eletrônico, que desempenham papéis de emitente, destinatário, transportador e terceiros citados no XML da NF-e (informado na tag autXML), por meio do acesso identificado do consulente ao portal da administração tributária.

8.2. Consulta Resumida da NF-e ABI

Para as situações não enquadradas na Consulta Completa, o acesso aos dados da NF-e ABI só será possível através da consulta resumida.