Seu ERP ganhou mais dois meses. Não desperdice.

Para ME e EPP optantes pelo Simples que prestam serviços sujeitos à NFS-e, a data federal da obrigatoriedade do Emissor Nacional passou de 1º/09/2026 para 1º/11/2026. Isso não transforma dois meses em folga: a prontidão ainda depende de adaptar ERP e API, validar DPS/XML e preparar rejeições, timeouts, recuperação, reprocessamento e conciliação.

Por Reynier Rivero·Engenheiro de software·17 de setembro de 2026

Às 8h17, a pessoa responsável pelo faturamento abre o ERP para emitir a próxima nota. Em outra janela, há uma DPS de teste, um XML que passou pela validação local e uma resposta de timeout que ainda não diz se a NFS-e foi criada.

Essa cena é hipotética, mas a pergunta é concreta: se o envio ficar indeterminado, o sistema sabe o que fazer?

Primeiro, a obrigatoriedade federal estava prevista para setembro.

Agora, o prazo federal do escopo citado é novembro.

Parece uma boa notícia.

Dois meses extras para continuar fazendo exatamente o que já estava funcionando.

O problema é que novembro vai chegar do mesmo jeito.

Em 14/08/2026, a Receita Federal informou que a obrigatoriedade federal do Emissor Nacional da NFS-e foi prorrogada para 1º/11/2026. O escopo citado é específico: ME e EPP optantes pelo Simples que prestam serviços sujeitos à NFS-e, com emissão pela aplicação Web ou por integração via API.

O aviso do Portal da NFS-e publicado em 11/08/2026 trata o prazo adicional como uma oportunidade para municípios e contribuintes realizarem testes de integração e emissão.

É aí que a notícia deixa de ser apenas uma data no calendário.

O prazo não é uma linha única

Antes de abrir um chamado para trocar endpoint, monte uma matriz simples. Ela evita que uma regra federal seja interpretada como se fosse um calendário universal para toda empresa, todo município e todo emissor.

A comunicação da Receita Federal documenta a obrigatoriedade federal do Emissor Nacional em 1º/11/2026 para ME e EPP optantes pelo Simples que prestam serviços sujeitos à NFS-e.

O Decreto Municipal nº 17.913/2026 de Juiz de Fora, publicado em 30/07/2026, documenta o marco municipal de 1º/09/2026 para prestadores estabelecidos no município, com emissão pelo Emissor Nacional e canais Web, Mobile e API.

A comunicação da Receita Federal também separa a agenda para optantes pelo Simples Nacional relacionada a CBS e IBS, com efeitos indicados a partir de 01/01/2027.

A comunicação federal da Receita Federal fala em ME e EPP optantes pelo Simples. Não use esse texto para incluir MEI por inferência.

A matriz do projeto precisa cruzar, no mínimo, município de estabelecimento, regime da empresa, tipo de serviço, canal de emissão, ambiente técnico e parâmetros municipais aplicáveis.

O marco citado é federal. A configuração que faz a nota funcionar continua tendo endereço, cadastro e contexto municipal.

A emissão é um fluxo, não um botão

O Perguntas e Respostas publicado pelo Portal da NFS-e em 16/09/2026 reúne 30 temas e mais de 170 questões sobre parametrização, acesso, cadastro e operação. É um guia operacional útil, não uma substituição do texto normativo.

O FAQ técnico v1.00, datado de 08/09/2026 entra justamente nas áreas que costumam quebrar dentro de um ERP: DPS, XML, XSD, APIs, Produção Restrita, rejeições e recuperação.

Isso muda o desenho do trabalho.

1. Parametrização antes do payload

O ERP precisa saber qual empresa está emitindo, para qual município, com qual serviço, em qual cenário e por qual canal.

O índice oficial de APIs, atualizado em 20/08/2026 separa serviços de Produção Restrita e Produção e lista APIs relacionadas a contribuintes e parâmetros municipais.

Antes de gerar XML, mapeie esses dados em um modelo interno consistente. Não esconda regra municipal em uma condição espalhada por cinco telas do sistema.

2. DPS, XML e XSD precisam conversar

A DPS não é apenas um formulário que o usuário preenche. Ela é a origem de um documento que será serializado, validado e enviado.

A documentação atual de Produção, atualizada em 15/08/2026 lista manuais, esquemas XSD e anexos de layout relacionados à DPS e à NFS-e.

Na prática, o ERP deveria conseguir:

• gerar uma DPS a partir de um modelo de dados tipado;
• validar o XML contra o XSD antes de chamar o endpoint;
• registrar a versão do schema usada na emissão;
• preservar o XML enviado e a resposta recebida;
• apresentar a rejeição em linguagem útil para a operação.

O objetivo não é apenas evitar um XML inválido. É saber qual parte da informação precisa ser corrigida e se a tentativa pode ser repetida com segurança.

3. CNPJ, certificado e ambiente

A NT 009, de 04/06/2026 documenta a mudança dos campos de CNPJ de numérico para caractere para contemplar o novo formato alfanumérico.

A resposta de engenharia é direta: trate CNPJ como string. Revise banco de dados, validadores, integrações, exportações, logs e relatórios que assumem que o identificador terá apenas números.

A Receita Federal informou em 31/07/2026 que o primeiro CNPJ alfanumérico foi gerado e que os CNPJs existentes continuam válidos. Isso não elimina a necessidade de compatibilidade futura.

A mesma NT 009 documenta o grupo gPgtoVinc com ocorrência 0-1 e lista Pix entre os meios de pagamento. O grupo é opcional; Pix é um meio listado, não obrigatório para o ERP.

Também não trate a NT 009 como se todo o seu conteúdo já estivesse em Produção. A página de RTC do Portal da NFS-e, atualizada em 15/07/2026 registra que versões e datas de disponibilização devem ser acompanhadas oficialmente. A homologação realizada entre 31/08 e 03/09/2026, publicada em 05/09/2026, confirma testes e validação — não produção completa.

Certificados, credenciais e endpoints também precisam ser tratados como configuração por ambiente. Um certificado funcionando na Produção Restrita não prova que o processo de troca para Produção está pronto.

4. Rejeição, timeout e recuperação

O fluxo precisa ter estados claros. Por exemplo:

rascunho → validando → enviado → autorizado

E também:

enviado → rejeitado

ou:

enviado → indeterminado → consultando → autorizado/rejeitado

Se o endpoint retornar rejeição, o ERP deve guardar código, mensagem, payload e contexto. Se retornar timeout, não deve reenviar cegamente a mesma DPS até criar uma duplicidade.

O sistema precisa distinguir pelo menos quatro situações:

• o XML era inválido antes do envio;
• o serviço rejeitou a operação;
• o envio pode ter sido aceito, mas a resposta não chegou;
• a nota foi autorizada, mas ainda não foi conciliada no ERP.

Recuperação é consultar o status quando houver essa capacidade, reprocessar somente quando a operação for segura e reconciliar o resultado com o protocolo, a chave e o registro financeiro interno.

Uma integração fiscal sem conciliação é apenas uma fila de incertezas com aparência de automação.

Como usar os dois meses

Use o prazo estendido para produzir evidências técnicas, não apenas para adiar o projeto.

Feche o escopo

Registre quais empresas entram, quais municípios precisam ser tratados, quais serviços estão no escopo e quais canais serão usados. Se uma empresa puder emitir pela Web em um cenário e por API em outro, isso deve aparecer na matriz.

Congele o contrato de dados

Defina o modelo interno da DPS, a conversão para XML, a validação XSD e o tratamento de campos que podem evoluir. Faça o CNPJ atravessar o sistema como texto antes que um cadastro alfanumérico encontre um campo numérico.

Teste os dois ambientes

Separe claramente Produção Restrita e Produção. Teste credenciais, certificados, endpoints, headers, payloads, respostas e logs em cada ambiente. Um teste verde no ambiente restrito é evidência de avanço, não autorização automática para liberar produção.

Simule o que costuma ser esquecido

Provoque rejeição, XML inválido, certificado indisponível, timeout, resposta duplicada e queda durante o reprocessamento. Depois verifique se o operador consegue entender o estado sem consultar cinco bancos de dados diferentes.

Concilie o final

Compare o que o ERP acredita ter enviado com o que o ambiente nacional registrou. A autorização precisa voltar para o fluxo financeiro, o documento precisa ficar recuperável e uma nota indeterminada não pode desaparecer em uma caixa de erro.

Se essa integração fizer parte de um produto maior, trate-a como produto: com estados, observabilidade, documentação e uma experiência operacional previsível. A discussão sobre integração como parte do produto ajuda a enxergar esse tipo de conexão além do conector isolado.

O prazo é o relógio; a prontidão é evidência

O problema não é que novembro esteja longe. É que a data pode mudar sem reduzir a complexidade do sistema.

Dois meses não compram uma integração. Compram a chance de descobrir a integração antes da primeira nota real.

A pergunta decisiva é simples: se uma DPS for enviada às 23h58 e o endpoint retornar timeout, seu ERP sabe consultar, reprocessar ou reconciliar?

Se a resposta for “depende de alguém lembrar o que aconteceu”, o projeto ainda não está pronto.

Aviso importante

Este artigo é informativo e trata de arquitetura de software, integração e operação técnica. Não constitui aconselhamento jurídico, fiscal ou contábil. Confirme o enquadramento da empresa, a obrigação aplicável e o cronograma municipal com o responsável fiscal e os canais oficiais do município.

Próximo passo

Se a matriz já mostra os municípios, serviços e endpoints envolvidos, mas ainda não existe uma prova de rejeição, recuperação e conciliação, o próximo passo é transformar essa incerteza em backlog testável.

A Prontavel pode ajudar a desenhar essa camada sobre o ERP existente por meio de uma arquitetura de automações e integrações ou de software sob medida. A meta é chegar a novembro com evidência técnica — não apenas com a esperança de que o botão “Enviar” continue azul.

O serviço de que fala este artigo: Pare de mover dado na mão