Pipeline de NF-e na SEFAZ: arquitetura, rejeições mais comuns e como cortar o tempo de resposta em produção

Toda empresa brasileira que vende emite NF-e. Poucas fazem isso bem.

Em 2025, foram emitidas no Brasil mais de 11 bilhões de NF-e/NFC-e (Painel da NF-e do CONFAZ). É o sistema de documentos fiscais mais volumoso do mundo. E é o gargalo técnico mais comum em ERPs e PDVs brasileiros, tanto pela complexidade do XML quanto pelas inconsistências entre as 27 SEFAZs estaduais.

Os sintomas em produção que aparecem:

• PDV trava 3–8 segundos por venda esperando autorização SEFAZ
• Cliente espera no caixa com fila pra trás (péssimo)
• Rejeição vai e volta sem motivo claro (ou com motivo críptico)
• SEFAZ fica offline e a empresa não tem contingência
• Erros fiscais acumulam e o contador descobre 2 meses depois
• Auditoria fiscal abre processo por inconsistência de dados

Esse post é o blueprint técnico de pipeline NF-e/NFC-e robusto: arquitetura, padrões, top códigos de rejeição comuns e como reduzir SLA real de minutos para segundos.

A arquitetura de pipeline NF-e que funciona em produção

[ Aplicação (PDV/ERP) ]
         ↓ envia venda
[ Validador local (motor fiscal) ]
         ↓ XML pré-validado
[ Fila assíncrona (RabbitMQ / SQS) ]
         ↓ pula pra produção
[ Worker SEFAZ ]
         ↓ requisição
[ SEFAZ UF ] ← retry com backoff exponencial
         ↓ resposta
[ Persistência (status, protocolo) ]
         ↓ notificação
[ Aplicação (UI atualiza) ]

Os componentes críticos:

1. Validador local antes de mandar pra SEFAZ

A SEFAZ rejeita em 200ms quando o erro é de schema (XML mal formado, CST inválido, NCM inexistente). Validar localmente antes elimina 60–80% das rejeições e economiza idas/voltas no servidor SEFAZ.

Ferramentas:

• XSD validation (schema oficial SEFAZ por estado)
• Motor fiscal próprio com tabela atualizada (CFOP, CST, CSOSN, MVA, IBPT)
• Validação de dígito verificador de chave NFe, CPF/CNPJ do destinatário
• Validação de regras de negócio (operação de saída com CFOP de entrada = erro)

2. Fila assíncrona

Sob hipótese alguma o usuário deve esperar a SEFAZ responder. A UI confirma a venda e a fila cuida do envio. Tempo médio do usuário no caixa cai de 4–8s para 100–300ms.

Implementação típica:

• RabbitMQ (auto-hospedado) ou SQS (AWS managed)
• Visibility timeout de 30s
• Dead Letter Queue após 5 retries
• Idempotência via chave da NF (não emite duplicado)

3. Worker SEFAZ com retry inteligente

Não é simples "tenta de novo". Cada erro tem comportamento diferente:

Tipo erro	Retry?	Estratégia
Timeout de rede	SIM	Backoff exponencial (1s, 2s, 4s, 8s, 16s)
SEFAZ offline (HTTP 503)	SIM	Backoff + após 3 tentativas, contingência SCAN/EPEC
Rejeição por dado inválido	NÃO	Notifica usuário, exige correção
Rejeição por certificado	NÃO	Alerta para equipe de operação
Cota excedida (DoS protection)	SIM	Backoff longo (60s+)

4. Contingência (SCAN ou EPEC)

Quando SEFAZ fica offline, a SEFAZ Virtual (SVAN, SVRS) ou EPEC (Evento Prévio de Emissão em Contingência) entram. Empresa que tem contingência continua vendendo. Empresa sem contingência trava operação.

Detalhes do EPEC (modelo mais moderno):

• Cliente gera NF localmente com mesma chave que iria pra SEFAZ
• Manda evento prévio para SEFAZ Virtual com hash da NF
• Vende e entrega
• Quando SEFAZ principal volta, sincroniza estado real
• Cliente recebe DANFE em contingência

EPEC reduz "tempo offline da operação" de horas para zero. Toda PDV/ERP sério em 2026 implementa EPEC.

5. Persistência e cronograma

Cada NF emitida precisa ser:

• Armazenada por 5 anos mínimo (Decreto 6.022/2007)
• Indexada por chave, número, série, destinatário, data
• Acessível em < 1s para o front-end (cache)
• Sincronizada com SPED Fiscal, SPED Contribuições e EFD-Reinf mensalmente

Top 30 rejeições SEFAZ e como resolver

Em produção, em 2025, as 30 rejeições abaixo concentram 92% dos erros. Vamos passar:

Rejeições estruturais (XML/schema)

216: "Falha na validação do schema" → XSD validation local antes de enviar. 203: "Tags ausentes/incorretas" → Versão do schema desatualizada. 228: "Data de emissão atrasada > 30 dias" → Não emita NF retroativa, use NFCom. 252: "Modelo da NF inválido para a operação" → Use mod 55 para B2B, mod 65 para B2C.

Rejeições de identificação

539: "CNPJ destinatário inválido" → Validar dígito verificador localmente. 540: "CPF destinatário inválido" → Mesma coisa. 248: "Inscrição estadual destinatário inválida para operação interestadual" → Validar IE local + cadastro CCC. 409: "CFOP inválido para operação interna/interestadual" → Tabela CFOP local com regras UF.

Rejeições fiscais (mais complicadas)

611: "Valor total da NF não confere com soma de itens" → Bug de cálculo. Acumular centavos por linha pode dar diferença. Use BigDecimal/Decimal não Float. 620: "ICMS-ST não corresponde ao calculado pela SEFAZ" → Tabela MVA desatualizada. Atualizar via Confaz mensalmente. 632: "CST/CSOSN inválido para o regime tributário do emitente" → Simples Nacional usa CSOSN, demais usam CST. Não misturar. 666: "CFOP de venda interestadual com CSOSN do Simples" → Combinação inválida específica.

Rejeições de certificado

224: "Certificado expirado" → Monitorar validade. Renovar 30 dias antes. 225: "Certificado revogado" → Verificar OCSP/CRL. 226: "Cadeia de certificação incompleta" → Bundle de certs raízes (ICP-Brasil) atualizado.

Rejeições de protocolo

539: "NF já autorizada" → Idempotência! Não reenviar. Buscar protocolo anterior. 538: "Pendência judicial" → Bloqueio fiscal do emitente. Resolver com Receita.

Rejeições específicas de NFC-e

678: "Modo offline excede 5 minutos sem sincronizar" → Implementar EPEC ou contingência. 709: "Forma de pagamento sem detalhe obrigatório" → Cartão precisa informar adquirente.

A lista completa tem ~700 códigos, mas esses 30+ resolvem a maior parte. Cada um deve ter:

• Diagnóstico automatizado no sistema (não só "rejeitado")
• Mensagem clara pro usuário (não "rej 620 ICMS-ST")
• Sugestão de correção quando óbvio

Latência: SEFAZ não é a culpada (na maioria das vezes)

Diagnóstico de latência fim-a-fim de NF-e:

Etapa	Tempo típico
Aplicação cliente → fila	5–20ms
Worker pega da fila	1–10ms
Validação local	10–80ms
Assinatura digital (XML)	80–280ms
Conexão TLS para SEFAZ	80–200ms
SEFAZ processa	600–2500ms (mediana 1100ms)
Resposta TLS	60–150ms
Persistência + notificação	20–80ms
TOTAL fim-a-fim	800–3300ms

Note que a maior fatia é a SEFAZ em si (40–60% do tempo). Otimizar isso é impossível (não é seu sistema). Mas manter conexão TLS keep-alive e pré-aquecer pool de conexões pode cortar até 30% da latência cliente-SEFAZ.

Para PDV, o usuário não precisa esperar o ciclo todo. O caixa fecha a venda em 100ms (escreve na fila) e o pipeline SEFAZ acontece em background. Em < 3s a maioria das vendas foi autorizada. Se rejeitar, alerta pro caixa.

NFC-e: as particularidades que mudam tudo

NFC-e é a NF do varejo (modelo 65). Diferenças importantes:

1. Modo Offline obrigatório

Padrão CONFAZ exige que PDV continue vendendo mesmo se SEFAZ cair. Modo offline tem janela de 5 minutos antes de bloquear. Implementação via EPEC ou geração de QR Code de contingência.

2. QR Code obrigatório no DANFE

DANFE NFC-e tem QR Code que aponta pra portal da SEFAZ pra consulta. Cliente final precisa conseguir conferir.

3. Forma de pagamento detalhada

NFC-e exige detalhamento de forma de pagamento (cartão, Pix, dinheiro, voucher, troco). Cada PSP tem código próprio.

4. SAT em SP (modelo antigo)

São Paulo tem SAT (Sistema Autenticador e Transmissor) como alternativa à NFC-e. Em desuso, mas ainda existem instalações ativas. PDV moderno suporta os dois.

Os 9 erros arquiteturais mais comuns

1. Chamar SEFAZ sincronamente da UI

Cliente espera. Trava. Cabo desconecta no meio. Loop infinito.

2. Sem retry exponencial

Se SEFAZ retorna 503, sistema retenta imediatamente. SEFAZ retorna 503 de novo. Loop. Use backoff.

3. Sem fila de DLQ

NF rejeitada por motivo válido fica em loop infinito tentando. Move para DLQ após N retries para investigação humana.

4. Cálculo fiscal em Float

0.1 + 0.2 = 0.30000000000000004. Em fiscal, isso vira NF rejeitada por R$ 0,01 de diferença. Use BigDecimal (Java), Decimal (.NET/Python), decimal.js (Node).

5. Sem monitoramento de fila

Fila enche silenciosamente. 4 horas depois, ninguém percebeu, milhares de NFs paradas. Dashboard + alerta.

6. Certificado vencido sem aviso

Sistema para de funcionar em 0:00 do dia X. Monitorar validade, alertar 30 dias antes.

7. Sem versionamento de schema

SEFAZ publica novo schema (sempre publica). Sistema continua com versão antiga. Quando SEFAZ aposenta versão antiga, sistema quebra. Manter atualizado com pipeline de teste em sandbox.

8. Sem testes em sandbox SEFAZ

SEFAZ tem ambiente de homologação. Toda mudança de fiscal deve passar pelo sandbox antes de produção. Skipping vira passivo fiscal.

9. Sem inutilização de numeração

NF que rejeitou e foi corrigida pode deixar buraco na numeração. Buraco precisa ser inutilizado formalmente via webservice (NFeInutilizacao). Senão, fica inconsistente no SPED.

A integração que a Bradata constrói

Para nossos clientes de ERP e frente de caixa, o pipeline NF-e implementamos com:

• Validador local com tabelas CFOP/CST/CSOSN/NCM atualizadas mensalmente
• Fila (BullMQ se Node, Celery se Python)
• Worker com retry exponencial + DLQ
• EPEC para contingência automática
• Cache de protocolo (Redis) para consulta rápida
• Dashboard de pipeline (fila, taxa de rejeição, latência por UF)
• Alerta (Slack/Email/PagerDuty) por anomalia
• Compatibilidade multi-UF (cada SEFAZ tem variação)
• Suporte a SVAN/SVRS automaticamente
• Integração com SPED Fiscal/Contribuições mensalmente
• EFD-Reinf para INSS/IRPJ retidos

Veja como funciona na prática nas nossas soluções de PDV e ERP. Para projetos sob medida, conheça nossa abordagem em ERP sob medida.

Conclusão

Pipeline NF-e é infraestrutura crítica: falha = empresa para de vender. Pipeline com EPEC + validação local + monitoramento + retry inteligente funciona em produção com 99,5%+ de taxa de sucesso e SLA de 100–300ms pro usuário final.

Sistema com integração NF-e mal feita gera passivo fiscal, paralisação de venda, frustração de cliente. Sistema bem feito é invisível: funciona sempre.

Se você está construindo ou modernizando integração fiscal e quer avaliar arquitetura, fale conosco. A Bradata implementa integração SEFAZ robusta em todos os nossos projetos com componente fiscal.

A Bradata é uma software house brasileira com profundidade em fiscal, ERP, varejo e indústria. Veja nossos cases e soluções.

---

Fontes: Manual de Orientação do Contribuinte (MOC) NF-e v7.0 / NFC-e v6.0 / SVRS, Manual EPEC v2.0, Portal Nacional NF-e do CONFAZ, Painel da NF-e 2025, schemas XSD oficiais SEFAZ, projetos internos Bradata.