Tag: nfs-e

Conferência de 23 de outubro de 2026: o FAQ oficial continua identificado como versão 1.00, de 8 de setembro de 2026. O portal registra alterações em produção restrita em 20 de outubro: reposicionamento de CST/cClassTrib, novos fatos geradores e grupo vAjusteBC. Os anexos e XSD de homologação têm identificação 20261020; isso não deve ser confundido com o catálogo de produção. Consulte Atualizações e Implantações e a documentação de homologação para conferir o ambiente utilizado.

A evolução da NFS-e padrão nacional coloca desenvolvedores, software houses e áreas contábeis diante de uma tarefa que parece simples, mas exige método: distinguir o que é explicação operacional do que efetivamente representa uma mudança técnica aprovada e aplicável ao sistema emissor. Essa diferença importa especialmente na preparação para IBS e CBS, porque uma interpretação precipitada pode gerar desenvolvimento desnecessário, testes no ambiente errado ou comunicação fiscal inadequada ao cliente.

O ponto de partida é o material oficial de Perguntas e Respostas da NFS-e. No Portal consultado, o arquivo disponibilizado está identificado como versão 1.00, de 08/09/2026, e a página de publicação está datada de 16/09/2026. Ele ajuda a navegar por dúvidas sobre temas como cadastro, emissão, XML, APIs e IBS/CBS. Mas seu uso correto depende de reconhecer seus limites documentais.

Este artigo explica por que o FAQ é um instrumento útil de trabalho, como evitar conclusões além das evidências e de que forma equipes Delphi e profissionais da contabilidade podem estruturar uma rotina de conferência entre orientação, documentação técnica e regras fiscais.

A atualização da Nota Fiscal de Serviço eletrônica (NFS-e) para contemplar IBS e CBS não é apenas uma mudança de nomenclatura tributária. Ela alcança o contrato técnico entre emissor e ambiente nacional: tipos de dados, grupos de informação, regras de negócio, cenários de ajuste e validações. Para quem mantém um ERP em Delphi, isso significa revisar componentes de geração de XML, modelos de domínio, persistência e rotinas de integração. Para a contabilidade, significa acompanhar se o dado transmitido expressa corretamente a operação que está sendo documentada.

O marco analisado aqui é o Ato Técnico Conjunto RFB/SUFIS/CGIBS/Diretoria-Executiva nº 7, de 28 de setembro de 2026, disponibilizado pelo CGIBS em 1º de outubro de 2026. Ele aprova documentos técnicos para a NFS-e e a NFS-e Via aplicáveis à CBS e ao IBS. Este artigo percorre o que foi formalmente aprovado, as alterações técnicas confirmadas, o cronograma divulgado, a divergência documental identificada e uma forma prática de conduzir a adequação sem confundir leiaute com obrigação tributária material.

Uma atualização fiscal pode chegar ao sistema por caminhos diferentes: um ato aprova documentos, uma nota técnica descreve campos e um comunicado informa quando os ambientes serão atualizados. Quando esses papéis se confundem, a equipe pode implementar uma versão incorreta ou cobrar do cliente uma informação que ainda não está disponível no ambiente utilizado.

O Ato Técnico Conjunto RFB/SUFIS/CGIBS/Diretoria-Executiva nº 7, de 28 de setembro de 2026, reúne duas frentes que precisam ser acompanhadas separadamente: a Nota Fiscal de Serviço eletrônica de padrão nacional, a NFS-e, e a NFS-e Via, voltada à exploração de rodovias mediante cobrança de pedágio. Embora apareçam no mesmo ato, elas possuem documentação, alterações e cronogramas próprios.

Este artigo explica o alcance dessa aprovação, destaca mudanças que afetam cadastros e sistemas empresariais e mostra como organizar a adaptação. As datas e versões refletem a documentação conferida em 14 de outubro de 2026. Como o calendário recebeu atualização nessa mesma data, ele deve ser novamente conferido antes de cada implantação.

A virada para 2027 exige mais do que atualizar duas alíquotas no cadastro fiscal. Um sistema de gestão empresarial, ou ERP, precisa reconhecer a operação, selecionar seu tratamento tributário, emitir o documento correto e acompanhar os efeitos sobre pagamentos, créditos e apuração. Se essas etapas usarem regras de momentos diferentes, o problema pode aparecer apenas no fechamento fiscal, quando corrigir a origem já será mais trabalhoso.

Este artigo reúne os principais pontos para desenvolvedores, equipes fiscais e profissionais de contabilidade planejarem essa implantação. O recorte considera as fontes oficiais consultadas em 7 de outubro de 2026. Obrigações estabelecidas, cronogramas técnicos e recomendações de arquitetura são apresentados separadamente: uma funcionalidade anunciada para testes não equivale a uma exigência geral em produção.

A virada para 2027 não será uma simples troca de siglas no sistema fiscal. Empresas precisarão conviver com tributos antigos e novos, revisar cadastros e preços, adaptar documentos eletrônicos e conferir uma apuração cada vez mais dependente da qualidade das informações transmitidas. Para quem desenvolve um sistema de gestão empresarial (ERP) ou orienta uma carteira contábil, o problema começa quando essas mudanças são resumidas a uma frase: “em janeiro muda tudo”.

Não muda tudo ao mesmo tempo, nem da mesma maneira para todos. Algumas obrigações começaram em 2026; outras têm marco em janeiro de 2027; determinadas regras de validação entram depois. Uma nota técnica publicada também não significa que todos os seus campos sejam imediatamente obrigatórios em produção.

Este guia organiza a transição nacional e aprofunda cinco documentos: Nota Fiscal Eletrônica (NF-e), Nota Fiscal de Consumidor Eletrônica (NFC-e), Conhecimento de Transporte Eletrônico (CT-e), Conhecimento de Transporte Eletrônico para Outros Serviços (CT-e OS) e Nota Fiscal de Serviços Eletrônica (NFS-e). O objetivo é permitir que contador, empresa e desenvolvedor localizem a obrigação e a transformem em trabalho verificável.

Data de corte: 5 de outubro de 2026. Datas futuras abaixo são marcos documentados nessa data, não confirmação de implantação real. Regras locais, regimes setoriais e novos atos podem exigir complementação. Este é um guia nacional de consulta, não uma promessa de esgotar todas as situações tributárias possíveis.

Uma nota fiscal autorizada não é necessariamente uma nota tributariamente correta. Essa diferença, que já existia antes da reforma tributária, ganha importância com o Código de Classificação Tributária do IBS e da CBS, o cClassTrib. O autorizador consegue verificar se o código existe, se combina com o CST informado e se pode ser usado naquele modelo de documento. Ele não consegue, sozinho, conhecer todos os fatos da operação e decidir se o tratamento jurídico escolhido pelo contribuinte é o adequado.

O tema foi levantado no episódio “cClassTrib: o código que decide o imposto do item na nota”, do Radar Tributário. A ideia central é pertinente: deixar de receber uma rejeição não encerra a análise tributária. Mas algumas expressões usadas no vídeo, como “o código que decide o imposto”, precisam de contexto para não sugerir que um campo isolado substitui a interpretação da operação.

Neste artigo, explico o que o cClassTrib representa, o que as rejeições 1023, 1024 e 1025 realmente verificam, por que o NCM não produz um “de/para” universal e como contabilidade e desenvolvimento podem revisar a parametrização sem transformar uma tabela oficial em piloto automático.

A adaptação da Nota Fiscal de Serviço eletrônica (NFS-e) aos campos de IBS e CBS exige uma distinção que parece simples, mas tem efeito direto no desenvolvimento de sistemas e na rotina contábil: autorização técnica não é sinônimo automático de conformidade tributária. Uma nota pode passar pelo autorizador sem rejeição sistêmica e, ainda assim, estar sem uma informação que já se tornou obrigatória para aquela operação.

Para equipes que mantêm ERPs em Delphi, integrações fiscais e rotinas de escrituração, essa diferença muda a forma de priorizar o trabalho. Não basta testar se o XML ou a requisição é aceito. É preciso saber para quais operações o preenchimento é exigido, qual ambiente deve emitir o documento e como demonstrar a correção de inconsistências quando elas forem identificadas.

Neste artigo, vamos separar os cronogramas aplicáveis em 2026, explicar o caso particular das microempresas e empresas de pequeno porte do Simples Nacional, traduzir o impacto para software houses e contabilidades e propor um roteiro de implantação. Como os marcos de outubro, novembro e dezembro de 2026 eram futuros na data da pesquisa que embasa este texto, a leitura deve ser prospectiva e acompanhada de revisão normativa antes da entrada em produção.

Uma informação repetida com convicção pode parecer norma antes mesmo de alguém abrir a norma. Foi o que aconteceu com a afirmação de que, a partir de 1º de janeiro de 2027, todas as notas fiscais de serviço eletrônicas só poderão ser emitidas pelo Portal Nacional. A frase mistura mudanças verdadeiras, públicos diferentes e datas distintas. O resultado é uma orientação equivocada para empresas, contadores e desenvolvedores.

A resposta curta é: não existe uma determinação geral para que todo contribuinte abandone o emissor municipal e passe a digitar notas exclusivamente no portal web nacional em 01/01/2027. Há, porém, obrigações específicas que não devem ser minimizadas. Este artigo separa os conceitos, identifica quem realmente deve usar o Emissor Nacional, organiza os marcos documentados de setembro de 2026 ao fim de 2027 e mostra como acompanhar novas alterações sem transformar previsão em fato.

A Secretaria Municipal da Fazenda de São Paulo disponibilizou, em setembro de 2026, um novo arquivo XSD para a Nota Fiscal de Serviço eletrônica (NFS-e), com alterações nos campos relacionados ao Imposto sobre Bens e Serviços (IBS) e à Contribuição sobre Bens e Serviços (CBS). Também atualizou o Manual de WebService para a versão 3.3. A notícia parece tratar de uma troca pontual de esquema, mas o efeito para quem mantém um ERP é maior: muda o contrato que define quais elementos podem ser enviados, em que ordem, com quais tipos e sob quais regras de validação.

O cuidado inicial é separar três assuntos que costumam aparecer misturados. São Paulo continuará com seu emissor municipal; o leiaute local está sendo compatibilizado com a reforma tributária; e as obrigações e datas de preenchimento dependem do cronograma oficial vigente. Portanto, baixar o XSD não basta, assim como não é seguro concluir que toda empresa paulistana passou a emitir diretamente no sistema nacional. Este artigo explica o que foi atualizado, como organizar a implementação e quais verificações reduzem o risco de rejeições e divergências fiscais.

O Portal Nacional da Nota Fiscal de Serviço eletrônica publicou, em setembro de 2026, a primeira versão de um documento com mais de 170 perguntas distribuídas em 30 temas. O material nasceu de dúvidas enviadas por municípios, contribuintes e empresas de desenvolvimento e cobre desde ativação municipal, cadastros e erros de CEP até APIs, cancelamento, locação, NFS-e Via e os novos grupos de IBS e CBS. São 125 páginas que mostram uma mudança maior do que a simples troca de um emissor.

A NFS-e nacional tornou-se uma infraestrutura de dados compartilhados. Municípios podem manter emissores próprios ou adotar os emissores públicos nacionais, mas precisam compreender o Ambiente de Dados Nacional (ADN), cadastros complementares, eventos e regras de interoperabilidade. Para as empresas e os ERPs, o desafio é distinguir obrigação de emitir, obrigação de compartilhar e obrigação de preencher os campos da reforma tributária. Este artigo organiza os pontos que merecem ação prática e indica onde a documentação oficial deve prevalecer sobre suposições do sistema antigo.

Recentemente, o Portal Contábeis divulgou que, segundo o Painel de Adesão da Receita Federal, 501 municípios brasileiros ainda não formalizaram sua adesão ao padrão da NFS-e Nacional. Embora possa parecer apenas um dado estatístico burocrático, para nós, desenvolvedores e gestores de Software Houses, esse número representa um alerta crítico sobre o cenário de fragmentação fiscal que ainda enfrentaremos no curto prazo.

Neste artigo, vamos dissecar o que esses dados significam, validar as referências legais por trás da obrigatoriedade e analisar o impacto direto no desenvolvimento de soluções fiscais em Delphi.