Manual de Orientação ao Contribuinte da Nota Fiscal de Água e Saneamento Eletrônica

1. Introdução

Este Manual tem por objetivo a definição das especificações e critérios técnicos necessários para a integração entre os sistemas das administrações tributárias e os sistemas das empresas emissoras da Nota Fiscal de Água e Saneamento Eletrônica - NFAg.

A versão original do Manual e as Notas Técnicas que o atualizam podem ser encontradas no Portal da NFAG da SVRS, onde também se encontram os pacotes de liberação de schemas e demais documentos.

2. Base Conceitual

2.1. Conceitos

2.1.1. NFAg (Modelo 75)

Nota Fiscal de Água e Saneamento Eletrônica (NFAg) é 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 NFAg.

2.1.2. DANFAG

O DANFAG (Documento Auxiliar da Nota Fiscal de Água e Saneamento Eletrônica) é um documento auxiliar impresso em papel, cuja especificação e modelos de leiaute se encontram no Anexo II: Manual de Especificações Técnicas do DANFAG.

2.1.3. Chave de Acesso da NFAg

A Chave de Acesso da NFAg é composta pelos seguintes campos que se encontram dispersos no leiaute da NFAg, conforme o Anexo I:

• cUF - Código da UF do emitente do Documento Fiscal;
• AAMM - Ano e Mês de emissão da NFAg;
• CNPJ - CNPJ do emitente;
• mod - Modelo do Documento Fiscal (75);
• serie - Série do Documento Fiscal;
• nNF - Número do Documento Fiscal;
• tpEmis - Forma de emissão da NFAg (1 - Normal; 2 - Contingência Offline);
• nSiteAutoriz - Site do Autorizador que recepcionou a NFAg;
• cNF - Código Numérico aleatório que compõe a Chave de Acesso;
• cDV - Dígito Verificador da Chave de Acesso.

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

2.1.4. Chave Natural da NFAg

A Chave Natural da NFAg é composta pelos campos de UF, CNPJ do Emitente, Série e Número da NFAg, além do modelo do documento fiscal eletrônico, da forma de emissão e do Site em que ela foi autorizada.

O Sistema de Autorização de Uso validará a existência de uma NFAg previamente autorizada e rejeitará novos pedidos de autorização para NFAg com duplicidade da Chave Natural, quando autorizados no mesmo ambiente de autorização. A informação da Forma de Emissão e do Site em que foi autorizada a NFAg pode indicar ambientes alternativos de autorização do Ambiente Nacional.

3. Arquitetura de Comunicação com Contribuinte

3.1. Modelo Conceitual

O ambiente autorizador de NFAg irá disponibilizar os seguintes serviços:

1. Recepção de NFAg (Modelo 75) - modelo síncrono, com uma nota;
2. Consulta da Situação Atual da NFAg;
3. Consulta do status do serviço;
4. Registro de Eventos.

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

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

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.

O diagrama a seguir ilustra o fluxo conceitual de comunicação entre o aplicativo do contribuinte e o Ambiente Autorizador:

3.2. Padrões Técnicos

3.2.1. Padrão de Documento XML

3.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 será em UTF-8; assim, todos os documentos XML serão iniciados com a seguinte declaração:

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

Observação: cada arquivo XML somente poderá ter uma única declaração <?xml version="1.0" encoding="UTF-8"?>.

3.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:

<NFAg xmlns="http://www.portalfiscal.inf.br/nfag">

O uso de declaração namespace diferente do padrão estabelecido para o Projeto é vedado. A declaração do namespace da assinatura digital deverá ser realizada na própria tag <Signature>.

3.2.1.3. Prefixo de namespace

Não é permitida a utilização de prefixos de namespace. Essa restrição visa otimizar o tamanho do arquivo XML.

Assim, em vez de:

<NFAg:NFAg xmlns:NFAg="http://www.portalfiscal.inf.br/nfag">

deverá ser adotada a declaração:

<NFAg xmlns="http://www.portalfiscal.inf.br/nfag">

3.2.1.4. Otimização na Montagem do Arquivo

Na geração do arquivo XML da NFAg, excetuados os campos identificados como obrigatórios no modelo, não deverão ser incluídas as TAGs de campos com conteúdo zero, para campos do tipo numérico, ou vazio, para campos do tipo caractere.

Deverão ser preenchidas no modelo apenas as TAGs de campos identificados como obrigatórios no leiaute ou os campos obrigatórios por força da legislação pertinente. Os campos obrigatórios no leiaute são identificados pelo primeiro dígito da coluna ocorrência (“Ocorr”) que inicie com 1, como 1-1, 1-2 ou 1-N. Os campos obrigatórios por força da legislação pertinente devem ser informados, mesmo que no leiaute seu preenchimento seja facultativo.

Essa regra estende-se aos campos sem indicação de obrigatoriedade cujo preenchimento se torne obrigatório por estar condicionado à legislação específica ou ao negócio do contribuinte. Nesse caso, deverá constar a TAG com o valor correspondente e, para os demais campos, deverão ser eliminadas as TAGs.

Para reduzir o tamanho final do arquivo XML da NFAg, 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, line-feed, carriage return ou tab 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, como line-feed, carriage return, tab e caractere de espaço entre as TAGs.

3.2.1.5. Validação de Schema

Para garantir minimamente a integridade das informações prestadas e a correta formação dos arquivos XML, o contribuinte deverá submeter o arquivo da NFAg e as demais mensagens XML para validação pelo Schema (XSD - XML Schema Definition), disponibilizado pelo Ambiente Autorizador, antes de seu envio.

3.2.2. Padrão de Comunicação

A comunicação entre o contribuinte e o Ambiente de Autorização será baseada em Web Services disponíveis no Portal da SEFAZ Virtual.

O meio físico de comunicação utilizado será a Internet, com o uso do protocolo TLS versão 1.2, 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 Autorizador e o aplicativo do contribuinte será realizada no padrão SOAP versão 1.2, com troca de mensagens XML no padrão Style/Encoding: Document/Literal.

A chamada dos diferentes Web Services do Projeto NFAg é realizada com o envio de uma mensagem através do campo nfagDadosMsg. A resposta do processamento da requisição pela aplicação do ambiente autorizador será realizada através de uma mensagem XML no campo nfagResultMsg.

3.2.3. Padrão de Certificado Digital

O certificado digital utilizado no Projeto da NFAg 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.

Os certificados digitais serão exigidos em três momentos distintos:

1. Assinatura de Mensagens: o certificado deverá conter o CNPJ de um dos estabelecimentos da empresa emissora da NFAg. Por mensagens, entendem-se o Pedido de Autorização de Uso, o Registro de Eventos de NFAg e demais arquivos XML que necessitem de assinatura. O certificado deverá ter o uso da chave previsto para assinatura digital e atributo de não recusa, obrigatoriamente com o CNPJ no campo otherName OID = 2.16.76.1.3.3, respeitando a Política do Certificado.
2. Transmissão: durante a transmissão das mensagens entre o servidor do contribuinte e o Ambiente Autorizador, o certificado digital utilizado para identificação do aplicativo deverá conter o CNPJ do responsável pela transmissão, sem necessidade de ser o mesmo CNPJ do estabelecimento emissor da NFAg, e deverá ter a extensão Extended Key Usage com permissão de “Autenticação Cliente”.
3. Geração do QR Code: o certificado utilizado para a assinatura da NFAg deverá ser utilizado para assinar a chave de acesso na geração do QR Code na hipótese de emissão off-line.

3.2.4. Padrão da Assinatura Digital

As mensagens enviadas ao Ambiente Autorizador são documentos eletrônicos elaborados no padrão XML e devem ser assinados digitalmente com um certificado digital que contenha o CNPJ do estabelecimento matriz ou do estabelecimento emissor da NFAg objeto do pedido.

Os elementos abaixo estão presentes no certificado do contribuinte e não devem ser representados individualmente no arquivo XML:

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

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

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

O Projeto NFAg utiliza um subconjunto do padrão de assinatura XML definido em www.w3.org/TR/xmldsig-core/, com o seguinte leiaute:

A assinatura do contribuinte na NFAg será feita na TAG <infNFAg>, identificada pelo atributo Id, cujo conteúdo deverá ser um identificador único, a chave de acesso precedida do literal “NFAg”. O identificador único precedido do literal “#NFAg” deverá ser informado no atributo URI da TAG <Reference>. Para as demais mensagens a serem assinadas, o processo será o mesmo, mantendo sempre um identificador único para o atributo Id na TAG a ser assinada.

O contribuinte não deve fornecer a Lista de Certificados Revogados, pois ela será montada e validada no Ambiente Autorizador no momento da conferência da assinatura digital.

A assinatura digital do documento eletrônico deverá atender aos seguintes padrões:

• padrão “XML Digital Signature”, formato “Enveloped”;
• certificado digital emitido por AC credenciada na ICP-Brasil;
• cadeia de certificação EndCertOnly, incluindo apenas o certificado do usuário final;
• certificado A1 ou A3, sendo recomendado o uso de HSM;
• chave criptográfica compatível com certificados A1 e A3, de 1024 bits;
• função criptográfica assimétrica RSA;
• função de message digest SHA-1;
• codificação Base64;
• transformações Enveloped e C14N.

3.2.5. Validação da Assinatura Digital pelo Ambiente Autorizador

Para a validação da assinatura digital, serão adotadas as seguintes regras:

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 de cada certificado da cadeia;
4. validar o uso da chave utilizada para aceitar somente certificados do tipo A, não sendo aceitos certificados do tipo S;
5. garantir que o certificado utilizado é de usuário final e não de Autoridade Certificadora;
6. adotar as regras definidas pelo RFC 3280 para LCRs 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.

A conferência da LCR pode ser feita on-line ou por download periódico. As assinaturas digitais serão verificadas considerando a lista de certificados revogados disponível no momento da conferência da assinatura.

3.2.6. Resumo dos Padrões Técnicos

3.3. Modelo Operacional

As solicitações de serviços da NFAg seguem o modelo de implementação síncrona, são processadas imediatamente e o resultado do processamento é obtido em uma única conexão.

A seguir, o fluxo simplificado de funcionamento:

Etapas do processo ideal:

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

3.4. Padrão de Mensagens dos Web Services

3.4.1. Área de Dados das Mensagens

A informação armazenada na área de dados <Body> da mensagem SOAP é um documento que deve atender ao leiaute definido na documentação do Web Service acessado.

Para os serviços de recepção, a mensagem deverá ser compactada no padrão GZip e o resultado convertido para Base64, reduzindo o tamanho da mensagem em aproximadamente 70%:

<soap12:Body>
  <nfagDadosMsg xmlns="http://www.portalfiscal.inf.br/NFAg/wsdl/NFAgRecepcao">string</nfagDadosMsg>
</soap12:Body>

Para os demais serviços, Consulta, Recepção de Eventos e Status, a mensagem deverá utilizar XML sem compactação:

<soap12:Body>
  <nfagDadosMsg xmlns="http://www.portalfiscal.inf.br/NFAg/wsdl/NFAgRecepcaoEvento">xml</nfagDadosMsg>
</soap12:Body>

A área referente ao SOAP Header não deverá ser informada.

3.4.2. 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 são controladas pela atribuição de um número de versão para a mensagem.

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

A validação da estrutura XML é realizada por um analisador sintático, que verifica se a mensagem atende às definições e regras de seu Schema. Qualquer divergência provoca um erro de validação.

A primeira condição para que a mensagem seja validada com sucesso é que ela seja submetida ao Schema XML correto. O aplicativo do contribuinte deve estar preparado para gerar as mensagens no leiaute em vigor e informar a versão da estrutura XML na TAG correspondente:

<NFAg xmlns="http://www.portalfiscal.inf.br/nfag">
  <infNFAg Id="NFAg43081808467115000100750010757245731000000010" versao="1.00">
    ...
  </infNFAg>
</NFAg>

3.4.3. Schemas XML das Mensagens dos Web Services

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

A versão dos Schemas é identificada pelo acréscimo do número da versão no nome do arquivo, precedido do literal “_v”, como em:

NFAg_v1.00.xsd
tiposGeral_v1.00.xsd

A maioria dos Schemas XML utiliza definições de tipos básicos ou complexos definidos em outros Schemas. Nesses casos, a modificação do Schema básico será repercutida no Schema principal.

Por exemplo, se o tipo numérico de 15 posições com duas decimais definido em tiposGeralNFAg_v1.00.xsd for modificado, todos os Schemas que utilizem esse tipo deverão ter a versão atualizada e as declarações import ou include deverão apontar para o nome do Schema básico atualizado.

As modificações podem ser causadas por necessidades técnicas ou por alteração de legislação. Alterações legais deverão ser implementadas nos prazos da norma; modificações técnicas serão divulgadas pela Coordenação Técnica do ENCAT e poderão ocorrer quando necessárias.

3.5. Versão dos Schemas XML

3.5.1. Liberação das Versões dos Schemas para a NFAg

Os Schemas válidos serão disponibilizados no sítio nacional do Projeto, dfe-portal.svrs.rs.gov.br/NFAg, após autorização da equipe de Gestão do Projeto formada pelos Líderes dos Projetos nos Estados e representante das Empresas.

A cada nova liberação será disponibilizado um arquivo compactado com o conjunto de Schemas a ser utilizado pelas empresas. Esse “Pacote de Liberação” terá a mesma numeração da versão compatível do Manual de Orientações e será identificado por “PL_NFAg” seguido do número da versão.

Por exemplo, PL_NFAg_1.00.zip representa o pacote compatível com o Manual de Orientações do Contribuinte versão 1.00.

Os Schemas XML são identificados pelo nome seguido da versão. Para o Schema XML de NFAg, corresponderá um arquivo “.xsd” como NFAg_v9.99.xsd, em que v9.99 corresponde à versão do Schema.

Para identificar os Schemas alterados em determinado pacote, deve-se comparar o número de versão de cada Schema com o pacote anterior.

3.5.2. Correção de Pacote de Liberação

Pode surgir a necessidade de corrigir um Schema XML por erro de implementação de regra de validação, obrigatoriedade de campo ou nome de tag divergente do leiaute, sem modificar a estrutura do Schema XML nem exigir alteração dos aplicativos de autorização ou dos contribuintes.

Nessa situação, será divulgado novo pacote com o Schema corrigido, sem alterar o número da versão do PL, para manter a compatibilidade com o Manual vigente. Os pacotes corrigidos serão identificados pelo acréscimo de letras minúsculas, como NFAg_PL_1.00a.ZIP, primeira versão corrigida de NFAg_PL_1.00.ZIP.

3.5.3. Divulgação de Novos Pacotes de Liberação

A divulgação de novos pacotes ou atualizações será realizada através da publicação de Notas Técnicas no Portal Nacional da NFAg, com as informações necessárias para implementação.

3.5.4. Controle de Versão

O controle de versão de cada Schema válido compreende uma definição nacional sobre a versão vigente e as versões anteriores ainda suportadas.

Esse controle permite a adaptação dos sistemas das empresas em datas diferentes; algumas empresas poderão utilizar leiaute mais atualizado, enquanto outras ainda operam com versão anterior.

Não estão previstas mudanças frequentes de leiaute e as empresas deverão ter prazo razoável para implementar as mudanças, conforme acordo operacional. Mensagens recebidas com versão não suportada serão rejeitadas com mensagem de erro específica na versão de leiaute de resposta mais recente em uso.

3.6. Sistema de Registro de Eventos

O Sistema de Registro de Eventos da NFAg - SRE é o modelo genérico que permite o registro de evento de interesse da NFAg originado pelo próprio contribuinte ou pela administração tributária.

Um evento é o registro de um fato relacionado com o documento fiscal eletrônico e pode ou não modificar a situação do documento, como no cancelamento, ou até mesmo substituí-lo por outro.

O serviço será disponibilizado pelo Ambiente Autorizador através de Web Service de processamento síncrono e será propagado para os demais órgãos interessados pelo mecanismo de compartilhamento de documentos fiscais eletrônicos. As mensagens utilizarão o padrão XML do Projeto NFAg e conterão a assinatura digital do emissor do evento, contribuinte ou Fisco.

O registro do evento requer a existência da NFAg vinculada no Ambiente Autorizador; contudo, alguns tipos poderão ser registrados sem que a NFAg exista na base, conforme as regras de negócio do evento.

O modelo de mensagem deverá conter um conjunto mínimo de informações:

• identificação do autor da mensagem;
• identificação do evento;
• identificação da NFAg vinculada;
• informações específicas do evento;
• assinatura digital da mensagem.

O Web Service será único e tratará eventos genericamente, facilitando a criação de novos eventos sem novos serviços e com poucas alterações na aplicação do Ambiente Autorizador.

O leiaute da mensagem conterá uma parte genérica, comum a todos os eventos, e uma parte específica, na qual será inserido o XML de cada tipo de evento em uma tag do tipo any. As regras da parte genérica constam da parte geral do sistema; as validações específicas constam da página de cada evento. O Pacote de Liberação deverá conter o leiaute da parte genérica e um Schema para cada leiaute específico.

3.6.1. Relação dos Tipos de Evento

Os eventos serão construídos gradativamente pelo Ambiente Autorizador, e novos eventos poderão ser acrescentados em futuras versões do MOC.

3.6.2. Eventos de Marcação

Serão criados eventos de marcação de NFAg para os casos em que um documento referenciar outro, por exemplo, Autorizada NFAg de Faturamento Conjunto.

Esses eventos serão gerados automaticamente pelo Fisco no momento da autorização dos documentos e serão assinados digitalmente com certificado digital da SEFAZ Virtual autorizadora da NFAg.

Os eventos gerados nas NFAg referenciadas deverão constar da consulta pública desses documentos.

3.7. Data e Hora de Emissão e Outros Horários

Todos os campos que representam Data e Hora no leiaute das mensagens da NFAg seguem o formato UTC completo com a informação do TimeZone, representação tecnicamente adequada para um país com dimensões continentais como o Brasil.

Serão aceitos horários de qualquer região do mundo, na faixa UTC de -11 a +12, e não apenas as faixas do Brasil.

Exemplo: no formato UTC para campos Data-Hora, “TZD” pode ser -02:00 em Fernando de Noronha, -03:00 em Brasília ou -04:00 em Manaus; no horário de verão, serão -01:00, -02:00 e -03:00. Exemplo completo: 2010-08-19T13:00:15-03:00.

3.8. SEFAZ Virtual

Os serviços da SEFAZ Virtual compreendem os Web Services descritos no Modelo Conceitual da Arquitetura de Comunicação.

O credenciamento de contribuintes e a autorização de uso dos serviços de determinada SEFAZ Virtual são de responsabilidade da Administração Tributária de circunscrição desses contribuintes.

4. Atualizações Técnicas Consolidadas

Os tópicos seguintes apresentam apenas o contexto operacional introduzido pelas Notas Técnicas posteriores ao MOC v.1.00k. Os campos, leiautes, regras de validação e eventos correspondentes serão mantidos nas páginas técnicas específicas.

4.1. Vinculação da Transação de Pagamento

A vinculação entre o documento fiscal eletrônico e a transação financeira sujeita ao split payment é necessária para a correta apuração dos débitos do fornecedor e concessão de créditos ao adquirente.

No split payment, há duas formas de o contribuinte indicar a vinculação:

1. transmitindo a chave do documento fiscal ao prestador de serviço de pagamento no início da transação financeira;
2. informando os dados da transação financeira em campos ou evento do documento fiscal eletrônico.

A NT NFAg 2026.001 detalha a segunda forma, mediante inserção dos dados da transação financeira em campos da NFAg ou em evento.

Nas transações sujeitas ao procedimento padrão do split payment e originadas por fornecedor ou recebedor, a vinculação é necessária antes da liquidação financeira para viabilizar o split payment superinteligente. Quanto maior a demora para reportar o vínculo, menores as chances de sua execução. Se não for possível executá-lo, será utilizado o split inteligente off-line, com posterior devolução de valores retidos a maior no prazo de três dias úteis.

Exemplos não exaustivos de vinculação por campos ou evento:

1. o fornecedor emite boleto antes da NFAg; ao emitir o documento, informa os campos relativos à transação financeira;
2. o fornecedor emite a NFAg e depois gera QR Code Pix dinâmico sem a chave do documento; para efetivar o vínculo, emite evento atrelado à NFAg com os dados do Pix;
3. o adquirente paga por TED e informa incorretamente a chave; o fornecedor emite evento atrelado à NFAg com os dados da transação financeira.

A implantação do split payment está prevista para 2027. Os campos têm caráter preparatório; não há exigência de preenchimento ou uso no ambiente de produção das empresas em 2026. A ativação efetiva ocorrerá quando o mecanismo entrar em vigência, com orientações e cronogramas adicionais a serem divulgados pelos canais oficiais do CGIBS e da RFB.

4.2. Antecipação de Pagamento

A NT NFAg 2026.002 apresenta evoluções da Reforma Tributária do Consumo e contempla Antecipação de Pagamento, obrigatoriedade das informações de IBS e CBS, percentual de devolução de tributos, alíquota zero da CBS em Área de Livre Comércio e melhorias na redação de regras de validação.

Na antecipação de pagamento em notas-fatura, a tabela de classificação de produtos passa a diferenciar prestação continuada de não continuada, com as opções: 0 - Não se aplica; 1 - Continuada; 2 - Não continuada; 3 - Ambos.

4.2.1. Antecipação de Serviço Não Continuado

• a nota de antecipação informa o tipo de pagamento antecipado para serviços não continuados;
• todos os itens indicam classificação de serviço não continuado;
• a nota de fornecimento posterior pode conter itens normais e itens que referenciam a nota de pagamento antecipado;
• cada item de serviço já pago referencia a chave de acesso da nota de antecipação;
• o item não aceita a Classificação Tributária 820008, destinada à tributação realizada em fatura anterior.

4.2.2. Antecipação de Serviço Continuado

• a nota de antecipação informa o pagamento de serviços continuados antes da prestação;
• todos os itens indicam classificação de serviço continuado;
• a nota de fornecimento posterior pode conter itens normais e itens que referenciam a nota de pagamento antecipado;
• cada item de serviço já pago referencia a chave de acesso da nota de antecipação;
• o item deverá utilizar a Classificação Tributária 820008.