Emissão automática de NF-e e NFS-e integrada ao sistema

Se a sua equipe fatura copiando dados do pedido para um emissor, confere CFOP de cabeça e reenvia nota rejeitada no fim da tarde, o problema não é falta de atenção. É um processo que depende de digitação justamente onde qualquer erro vira retrabalho fiscal.

Automatizar parece simples: o pedido fecha, o sistema gera a nota. Na prática, emitir é a parte fácil. O que separa uma integração boa de uma que só cria outra fila de pendências é como ela trata o que acontece depois do envio: rejeição, SEFAZ fora do ar, cancelamento fora do prazo, certificado vencido.

Faturar é mais do que apertar um botão de emitir

Uma nota fiscal eletrônica só existe quando o fisco a autoriza, e cada estado dessa vida precisa ser tratado pelo sistema:

• Gerada e transmitida, aguardando resposta.
• Autorizada, com protocolo. Só a partir daqui o documento tem validade e a mercadoria pode circular.
• Rejeitada, com um código que diz o que precisa ser resolvido antes de reenviar.
• Denegada, por irregularidade cadastral do emitente ou do destinatário. A numeração é consumida e a nota não pode ser usada.
• Cancelada ou corrigida por um evento posterior.

Emissor que só conhece "enviou" e "deu erro" empurra todo o resto para uma pessoa. Por isso a primeira decisão de projeto é modelar o ciclo de vida da nota como uma máquina de estados explícita, com histórico de cada transição. Isso vale mais do que qualquer tela bonita.

NF-e, NFC-e e NFS-e: por que são mundos diferentes

Muita empresa descobre no meio do projeto que "emitir nota" significa três integrações diferentes.

A NF-e e a NFC-e seguem um leiaute nacional, atualizado por notas técnicas. Os web services mudam conforme o estado, mas o XML é o mesmo. Trabalhoso, mas previsível.

A NFS-e é outra história. Por muitos anos, cada prefeitura escolheu seu próprio sistema: algumas seguem o modelo ABRASF, outras têm variações que só aparecem na homologação. O padrão nacional da NFS-e, com emissor e ambiente de dados nacionais, surgiu para reduzir essa fragmentação e ganhou força com a reforma tributária. A adesão, porém, avança município a município; confirme com a contabilidade o que vale onde a sua empresa está e presta serviço.

Se você emite as três, trate-as como integrações irmãs: uma interface comum no seu sistema e implementações separadas por baixo.

Do pedido à nota sem digitação: regras fiscais parametrizadas

O coração da automação não é a transmissão. É decidir o que vai dentro da nota sem que alguém precise pensar.

Para mercadoria, o sistema precisa definir CFOP, NCM, CST ou CSOSN, base de cálculo, alíquotas, substituição tributária e diferencial de alíquota. Para serviço, o código da lista de serviços, o município de incidência do ISS e as retenções do tomador. Tudo depende de uma combinação de fatores: regime tributário, UF de origem e destino, cliente contribuinte ou consumidor final, natureza da operação (venda, remessa, devolução, bonificação) e benefícios fiscais.

O erro clássico é escrever isso como uma cascata de if no código. Funciona no primeiro mês e vira campo minado no segundo, porque toda mudança fiscal exige desenvolvedor e deploy.

O caminho que defendemos é um motor de regras fiscais parametrizável:

1. Regras como dados, não como código. Uma tabela de cenários (origem, destino, tipo de cliente, operação, grupo de produto) aponta para o tratamento tributário.
2. Vigência em cada regra. Quando a legislação muda, você cadastra a nova versão sem apagar a antiga, e notas passadas continuam reproduzíveis.
3. Aprovação por quem responde pela regra. Só a contabilidade ou o fiscal altera tratamento tributário, com autor e data registrados.
4. Simulação antes de emitir. Monta-se um pedido fictício e vê-se a nota que sairia, campo a campo. É assim que a contabilidade valida sem depender de nota real.
5. Bloqueio quando não há regra. Cenário sem tratamento definido vai para uma fila de pendência com o motivo, em vez de sair com um CFOP chutado.

Com isso, a emissão passa a ser consequência do pedido. Se os pedidos chegam de uma loja virtual, loja, ERP e fiscal precisam estar coerentes entre si, como detalhamos em como integrar ERP e e-commerce sem planilha no meio.

Emissor próprio ou API especializada de emissão

Há dois caminhos técnicos para conversar com o fisco, ambos legítimos.

Emissor próprio significa que o seu sistema monta o XML, assina, chama os web services da SEFAZ ou da prefeitura e interpreta as respostas. Você controla tudo e não depende de terceiro. Em troca, assume a manutenção: cada nota técnica, cada mudança de endpoint e cada município peculiar vira trabalho da sua equipe.

API especializada de emissão é um serviço de terceiro que recebe os dados da nota num formato simplificado e cuida de montar, assinar, transmitir e acompanhar. A variedade de municípios passa a ser problema do fornecedor. Em troca, você depende da disponibilidade e da continuidade dele, e o custo tende a acompanhar o volume emitido.

Na prática, a decisão costuma seguir alguns critérios:

• Variedade de NFS-e. Serviço prestado em muitos municípios pede API. Um município só, ou um que já opera no padrão nacional, torna o emissor próprio razoável.
• NF-e com operação estável. Leiaute nacional e poucos estados de destino tornam o emissor próprio viável para quem tem equipe para mantê-lo.
• Onde a nota já nasce hoje. Se o seu ERP (TOTVS, SAP, Omie, Bling e tantos outros) já emite bem, muitas vezes o melhor projeto é integrar seu sistema ao emissor do ERP. Emissão própria faz sentido quando a venda acontece num sistema seu (portal, plataforma, app) e passar pelo ERP só para emitir cria atraso e duplicidade.

Qualquer que seja a escolha, isole a emissão atrás de uma interface. O resto do código pede "emitir a nota deste pedido" e recebe estados e eventos. Trocar de API ou internalizar a emissão no futuro vira troca de adaptador, não reescrita.

Rejeição, contingência, cancelamento e carta de correção

É aqui que a maioria das integrações falha. Para quem emite volume, esses fluxos acontecem toda semana.

Rejeição

Parte das rejeições é de dado (inscrição estadual inválida, NCM inexistente, total que não fecha) e precisa de correção humana. Outra parte das falhas é transitória, como serviço paralisado ou queda de comunicação, e deve ser retentada automaticamente com intervalo crescente. O sistema separa os dois casos e manda o primeiro para uma fila, com a mensagem traduzida para quem vai corrigir.

O cuidado mais importante: nunca reenviar com nova numeração quando a resposta não chegou. Se a transmissão estourou o tempo, a nota pode ter sido autorizada do lado de lá. Consulte a situação pela chave de acesso antes de qualquer reenvio; pular essa etapa é o caminho mais curto para nota duplicada e buraco na numeração.

Contingência

SEFAZ fica indisponível, e isso não pode parar o faturamento. Para NF-e existem modalidades previstas na legislação, como a SEFAZ Virtual de Contingência e o EPEC. Para NFC-e, a emissão offline permite vender e transmitir depois, dentro do prazo legal. O sistema detecta a indisponibilidade, entra em contingência de forma controlada e regulariza as notas quando o serviço volta, sem depender de alguém lembrar.

Cancelamento e inutilização

O cancelamento é um evento com prazo definido pela legislação. Dentro dele, é simples; fora dele, o caminho é outro, com orientação da contabilidade. O sistema deve conhecer o prazo, avisar quem tenta cancelar fora dele e registrar o motivo. Números pulados sem gerar nota precisam ser inutilizados, e essa rotina também pode ser automática.

Carta de correção

A carta de correção eletrônica ajusta informações que não mudam o cálculo nem as partes da operação. Ela não corrige valores, impostos, quantidades nem troca o destinatário. Deixe isso explícito na tela, porque é comum achar que a carta resolve qualquer coisa.

Todos esses eventos mexem com pedidos, títulos e estoque. Nota cancelada que continua gerando cobrança é um problema clássico, e o vínculo entre nota, título e recebimento é o que torna possível a conciliação bancária automática.

Certificado digital ICP-Brasil, XML e guarda dos documentos

Toda nota é assinada com o certificado digital da empresa, emitido dentro da ICP-Brasil. Para emissão automática em servidor, o tipo usual é o A1, um arquivo com validade de um ano. O A3, em token ou cartão, depende de hardware físico e não combina com servidor na nuvem.

O certificado A1 é, na prática, a assinatura da empresa. Trate-o assim:

• Guarde num cofre de segredos, nunca no repositório, numa pasta compartilhada ou em e-mail.
• Restrinja o acesso ao serviço de emissão e a poucas pessoas nomeadas, com registro.
• Monitore o vencimento com alertas semanas antes. Certificado vencido para o faturamento inteiro.
• Documente e teste a troca, para que ela não dependa de quem instalou o anterior.

O documento fiscal é o XML autorizado, não o DANFE em PDF. Guarde o XML e o protocolo de cada nota, além dos XMLs dos eventos, pelo prazo que a legislação tributária exige, em armazenamento com política de retenção e cópia em outra região. Disponibilize o XML ao destinatário e à contabilidade por rotina automática.

Guarde também as notas que você recebe. A manifestação do destinatário e a captura dos XMLs emitidos contra o seu CNPJ fecham o outro lado do ciclo, e pesam em compras e em logística, onde a NF-e convive com CT-e e MDF-e, assunto que aparece em sistema para transportadora sob medida.

Reforma tributária: um motor fiscal preparado para mudar

A reforma tributária sobre o consumo, aprovada pela Emenda Constitucional 132/2023 e regulamentada por lei complementar, substitui gradualmente ICMS, ISS, PIS e Cofins pelo IBS e pela CBS, com um longo período de convivência entre os dois modelos. Os documentos fiscais recebem novos campos por meio de notas técnicas, conforme a regulamentação avança.

Para quem está construindo emissão agora, isso significa:

• Nada de regra fixa no código. Um motor parametrizado, com vigência por regra, absorve a transição com cadastro e teste, não com reescrita, inclusive com dois conjuntos de cálculo convivendo por anos.
• Capacidade reservada para as notas técnicas. Se usa API de terceiro, pergunte como e com que antecedência ela incorpora as mudanças.
• Configuração, não promessa. O que depende de cada município ou de regulamentação em andamento fica parametrizável.

Os erros que mais vemos

• Emitir antes de o pedido estar realmente fechado, o que gera cancelamento em série.
• Pular o ambiente de homologação. As SEFAZ e boa parte das prefeituras oferecem um; use antes de cada mudança.
• Fila de pendências sem dono, que cresce em silêncio até o fechamento do mês.
• Nota desconectada da cobrança. Em modelos recorrentes, a nota de serviço deveria nascer do mesmo ciclo que gera a cobrança, como descrevemos em cobrança recorrente com Pix Automático.

Como medir se deu certo

Acompanhe poucos indicadores, toda semana:

• Tempo entre pedido confirmado e nota autorizada.
• Proporção de notas emitidas sem toque humano.
• Rejeições por motivo, para atacar a causa na origem: cadastro, regra fiscal ou integração.
• Cancelamentos e cartas de correção por erro interno.
• Pendências abertas no fim do dia, que deveriam ficar perto de zero.
• Dias até o vencimento do certificado.

Passo a passo para começar

1. Mapeie todos os tipos de nota que você emite, por estado e por município.
2. Liste os cenários fiscais com a contabilidade e valide cada um contra notas reais.
3. Decida entre emissor próprio, API ou integração com o ERP, cenário a cenário.
4. Modele o ciclo de vida da nota e os eventos antes de escrever a transmissão.
5. Construa o motor de regras com simulação e vigência.
6. Teste em homologação os caminhos ruins: rejeição, timeout, contingência, cancelamento.
7. Rode em paralelo com o processo atual por um período e compare nota a nota.
8. Só então desligue a digitação.

Do diagnóstico à primeira nota automática

Não existe emissão automática genérica. O que muda de uma empresa para outra é justamente o que dá trabalho: regime tributário, estados e municípios atendidos, onde o pedido nasce e o que o ERP já faz. Por isso começamos com um diagnóstico do faturamento atual, junto com a contabilidade, e só então propomos o desenho: protótipo das regras, MVP com os cenários principais e evolução a partir do uso real. O cronograma e o investimento são definidos sob consulta, depois de entender esse contexto. É um trabalho que fazemos dentro dos projetos de desenvolvimento web. Se o faturamento da sua empresa ainda passa por digitação, conte como ele funciona hoje.