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.

São Paulo mantém o emissor próprio, mas integra os dados nacionais

A página oficial da reforma tributária da Nota Fiscal Paulistana afirma que o município manterá seu emissor. Na prática, empresas estabelecidas na capital continuam usando o sistema eletrônico municipal ou o WebService da Prefeitura, conforme sua operação. Essa decisão preserva a integração já utilizada por muitos prestadores, mas não congela o leiaute: a NFS-e municipal precisa receber informações do IBS e da CBS e compartilhar os dados necessários com o Ambiente de Dados Nacional (ADN).

O ISS também não desaparece do documento em 2026. A Prefeitura informa que sua sistemática de arrecadação permanece inalterada durante o ano, enquanto a nota passa a comportar os dados dos novos tributos. Isso cria uma convivência entre informações municipais e nacionais. Para o ERP, a consequência é manter regras do ISS e acrescentar estruturas de IBS/CBS sem tratar um conjunto como simples substituto do outro.

Essa arquitetura é coerente com o modelo nacional: aderir ao padrão e compartilhar documentos não significa necessariamente abandonar o emissor local. O sistema precisa identificar quem autoriza o documento, qual leiaute rege o envio e em que etapa ocorre a transmissão ao ambiente nacional. Para compreender como essa transição se relaciona ao software fiscal, vale também consultar o guia sobre como adaptar um ERP em Delphi à reforma tributária de 2026.

O que a atualização do XSD realmente representa

XSD é o esquema que descreve a estrutura de um XML. Ele determina nomes e tipos de elementos, cardinalidade, ordem dos grupos e restrições de formato. Quando a Prefeitura publica uma nova versão, ela fornece um contrato verificável por máquina. O comunicado reproduzido pelo Portal Contábeis registra que o arquivo incorpora alterações ligadas às Notas Técnicas SE/CGNFS-e nº 003 e nº 004 e que o Manual de WebService foi atualizado para a versão 3.3.

Os campos mais visíveis são o Código de Situação Tributária (CST) e o Código de Classificação Tributária (cClassTrib), citados pela própria Prefeitura. Eles não devem ser tratados como dois textos livres. São códigos de domínio que expressam o enquadramento da operação e influenciam as informações exigidas e as validações posteriores. O cadastro fiscal precisa guardar o código aplicável, sua vigência e a justificativa da regra usada para selecioná-lo, em vez de espalhar decisões fixas pelo código-fonte.

O manual e o XSD cumprem papéis complementares. O manual explica serviços, mensagens, agrupamentos e exemplos; o XSD rejeita estruturas incompatíveis. Já as tabelas de domínio e as notas técnicas esclarecem valores permitidos e transições. Uma integração robusta precisa versionar esse conjunto, porque validar apenas contra um arquivo local antigo pode produzir um XML bem-formado que o ambiente atual já não aceita.

Leiaute novo não significa obrigatoriedade imediata de todos os campos

A existência de um grupo no esquema não prova, por si só, que ele deve ser enviado em qualquer emissão. O portal municipal mantém uma área de orientações para a emissão da NFS-e em 2026, e o cronograma sofreu ajustes durante a implantação. Além disso, há tratamento específico para empresas do Simples Nacional: a exigência do sistema nacional para ME e EPP foi adiada para 1º de novembro de 2026.

Por isso, a aplicação deve decidir a regra por competência, regime, município, tipo de operação e versão efetivamente ativa no ambiente. Usar apenas a data do relógio do servidor é frágil: uma nota substituída ou emitida para competência anterior pode seguir regra diferente. O ideal é manter uma matriz de vigência configurável, com fonte normativa e data de início, e registrar no documento qual versão das regras tomou a decisão.

Também é importante distinguir opcionalidade estrutural de validade fiscal. Um elemento marcado como opcional no XSD apenas pode ser omitido sem quebrar o esquema; uma regra de negócio pode torná-lo necessário em determinada operação. O inverso também ocorre: preencher um grupo permitido pode acionar validações de conteúdo adicionais. O validador local deve combinar esquema, tabelas e regras de negócio, sem prometer que a aprovação sintática garante autorização.

Como organizar a adaptação no ERP

O primeiro passo é inventariar o fluxo atual. Identifique onde o XML é montado, qual arquivo XSD está embarcado, como o sistema seleciona o endpoint, onde guarda protocolos e se o retorno bruto é preservado. Integrações antigas às vezes misturam regra tributária, serialização e transporte em uma única rotina; nesse desenho, uma pequena alteração de grupo aumenta o risco de regressão em operações que não usam IBS/CBS.

Em seguida, modele a tributação separadamente do XML. Uma estrutura interna pode representar CST, cClassTrib, base de cálculo, alíquotas, valores e indicadores com tipos adequados, independentemente do nome final de cada tag. Um adaptador específico da versão transforma esse modelo no leiaute municipal. Assim, a regra fiscal continua testável sem conexão externa e uma futura revisão do XSD exige menos alterações no núcleo do ERP.

Um roteiro prático de implementação deve incluir:

1. baixar o XSD e o manual somente na área de manuais da Nota Fiscal Paulistana e registrar data, versão e hash dos arquivos usados;
2. comparar os esquemas antigo e novo por elementos, tipos, cardinalidade e ordem, sem confiar apenas em comparação visual;
3. revisar a origem de CST e cClassTrib, evitando valor padrão silencioso quando o cadastro estiver incompleto;
4. validar o XML localmente contra a versão correta do XSD antes do envio;
5. testar cenários com e sem grupos de IBS/CBS, regimes distintos, valores nulos, arredondamento e competência de transição;
6. guardar XML enviado, resposta, protocolo, versão do leiaute e regra tributária aplicada para auditoria;
7. ativar a mudança por configuração e cliente, com capacidade de retorno controlado enquanto os ambientes são atualizados.

O versionamento merece atenção especial. Não substitua o arquivo antigo com o mesmo nome e suponha que toda emissão passou a usar o novo contrato. Mantenha versões identificáveis e uma resolução explícita, como layout-sp-2-v3.3, vinculada à vigência e ao ambiente. Isso permite reproduzir uma falha, reprocessar um documento histórico e explicar por que duas notas semelhantes foram serializadas de modos diferentes.

Testes que encontram falhas antes da produção

O conjunto mínimo começa com testes de contrato: XML válido, elemento fora de ordem, código fora do domínio, casas decimais excedentes e grupo incompleto. Depois entram testes tributários, nos quais uma combinação conhecida de serviço, regime e classificação deve produzir os códigos e valores esperados. Por fim, testes de integração verificam autenticação, assinatura, lote, resposta, consulta e tratamento de indisponibilidade no ambiente disponibilizado pela Prefeitura.

Casos de borda importam mais do que um exemplo feliz. Inclua tomador no exterior, ausência de inscrição municipal, retenção de ISS, valores com desconto, cancelamento ou substituição, lote parcialmente rejeitado e reenvio após timeout. Se o cliente opera em mais de um município, garanta que o adaptador paulistano não contamine o gerador de outros provedores. Os novos campos pertencem ao mesmo sistema tributário, mas os contratos municipais podem continuar diferentes.

Na observabilidade, não registre apenas “erro ao emitir”. Guarde código e mensagem da rejeição, etapa, versão do esquema e identificador interno, retirando credenciais e dados pessoais desnecessários. Métricas por versão ajudam a perceber uma elevação de rejeições logo após a ativação. Retentativas devem ocorrer apenas para falhas transitórias; reenviar cegamente uma requisição após resposta incerta pode duplicar a operação se não houver consulta ou mecanismo de idempotência.

Contabilidade e desenvolvimento precisam compartilhar a mesma regra

O preenchimento não pode ser decidido exclusivamente pela equipe de software. A contabilidade define o enquadramento da operação; o sistema transforma essa decisão em dados consistentes e rastreáveis. Uma boa tela de cadastro deve exibir a descrição do código, vigência e origem da tabela, além de impedir combinações conhecidamente incompatíveis. Quando faltar informação, é melhor bloquear com uma mensagem acionável do que escolher um código genérico que autorize a nota e gere uma apuração incorreta.

Esse cuidado se conecta à apuração assistida da CBS por APIs. A qualidade da apuração começa no documento fiscal: classificações, bases e eventos enviados de forma inconsistente reaparecem como divergência na conciliação. A emissão não deve ser considerada encerrada apenas porque recebeu autorização municipal; é necessário acompanhar compartilhamento, eventos posteriores e reflexos nos módulos fiscais.

Crie ainda um procedimento de atualização documental. Alguém deve monitorar a página municipal, a documentação técnica nacional da NFS-e e a seção específica da Reforma Tributária do Consumo. Cada mudança relevante deve abrir uma tarefa com análise de impacto, testes, versão do adaptador e comunicação aos clientes. Isso transforma a manutenção fiscal em processo, em vez de corrida emergencial a cada novo arquivo.

Cuidados para não interpretar além das fontes

A atualização anunciada confirma novos artefatos técnicos, mas não autoriza afirmar que todos os campos são obrigatórios em todas as operações ou que o emissor nacional substituiu o municipal. Também não basta copiar exemplos do manual para produção: dados de identificação, códigos e cálculos dependem do caso concreto. Quando houver divergência entre notícia, manual, XSD e orientação posterior, a equipe deve consultar a fonte oficial mais recente e registrar a decisão.

As especificações continuam sujeitas a evolução ao longo da transição. Por isso, o objetivo técnico não deve ser criar um XML “definitivo”, e sim uma integração capaz de absorver versões com segurança. Separar regra tributária, modelo interno, serializador e transporte custa algum trabalho agora, mas reduz o impacto de novas notas técnicas e torna os testes mais precisos.

Conclusão

A nova versão do XSD e o Manual de WebService 3.3 mostram que a NFS-e paulistana está avançando na compatibilidade com IBS e CBS sem abandonar o emissor próprio. Para o ERP, a mudança deve ser tratada como evolução versionada de contrato: códigos tributários precisam de governança, o XML deve ser validado contra o esquema correto e a ativação deve respeitar competência, regime, ambiente e cronograma oficial.

A ação mais importante é não reduzir a adaptação à inclusão de tags. Uma implementação confiável combina fonte oficial, modelo tributário separado, matriz de vigência, testes de contrato e rastreabilidade do documento. Com essa base, novas revisões deixam de exigir correções improvisadas e passam a seguir um processo controlado, compreensível tanto para desenvolvimento quanto para contabilidade.

Referências

BRASIL. Portal Nacional da Nota Fiscal de Serviço eletrônica. Documentação técnica atual. Brasília, DF, [s. d.]. Disponível em: https://www.gov.br/nfse/pt-br/biblioteca/documentacao-tecnica/documentacao-atual. Acesso em: 17 set. 2026.

BRASIL. Portal Nacional da Nota Fiscal de Serviço eletrônica. Reforma Tributária do Consumo: documentação técnica. Brasília, DF, [s. d.]. Disponível em: https://www.gov.br/nfse/pt-br/biblioteca/documentacao-tecnica/rtc. Acesso em: 17 set. 2026.

MACARIO, Lívia. RTC em São Paulo: novo arquivo da NFSe com campos de IBS/CBS é disponibilizado. Portal Contábeis, 10 set. 2026. Disponível em: https://www.contabeis.com.br/noticias/79332/sp-atualiza-nfs-e-com-alteracoes-nos-campos-de-ibs-e-cbs/. Acesso em: 17 set. 2026.

SÃO PAULO (Município). Secretaria Municipal da Fazenda. Orientações sobre a emissão de NFS-e a partir de 1º de janeiro de 2026. São Paulo, [2026]. Disponível em: https://prefeitura.sp.gov.br/web/fazenda/w/nfs-e_orientacoes. Acesso em: 17 set. 2026.

SÃO PAULO (Município). Secretaria Municipal da Fazenda. Reforma tributária: novo layout de emissão de NFS-e. Nota Fiscal Paulistana, [2026]. Disponível em: https://notadomilhao.sf.prefeitura.sp.gov.br/reforma-tributaria/. Acesso em: 17 set. 2026.

SÃO PAULO (Município). Secretaria Municipal da Fazenda. Simples Nacional: exigência de emissão da NFS-e pelo sistema nacional é adiada para 1º/11/2026. Nota Fiscal Paulistana, 31 ago. 2026. Disponível em: https://notadomilhao.sf.prefeitura.sp.gov.br/noticias/exigencia-de-emissao-da-nfs-e-pelo-sistema-nacional-e-para-1o-de-novembro-de-2026/. Acesso em: 17 set. 2026.