Reforma tributária e NFS-e: o que muda, para quem, e a partir de quando

O que muda na nota de serviço:

A nota de serviço ganha um grupo novo de informações, com os códigos do IBS e da CBS. Ele não substitui nada do que já existe: o valor, a alíquota do ISS, o item de serviço e a discriminação continuam onde estavam. O grupo entra ao lado, no fim da declaração.

São três códigos obrigatórios quando o grupo é enviado, e dois indicadores que têm valor padrão:

• CST: o código de situação tributária do IBS e da CBS, com três posições.
• Classificação tributária: seis posições.
• Indicador de operação: o código indicador da operação de fornecimento, seis posições.
• Indicador de destinatário: 0 quando o destinatário é o próprio tomador da nota, 1 quando não é. Omitido, vale 0.
• Uso e consumo pessoal: 0 para não, 1 para sim. Omitido, vale 0.

Esses códigos saem do enquadramento da empresa, não do software. Quem informa é o contador, e é por isso que a parte mais demorada desta mudança não é técnica: é conseguir os três números antes do prazo.

Para quem, e a partir de quando:

Há duas datas, e elas separam quem está no Simples Nacional de quem não está. Até lá, o grupo é opcional: omitir é válido e a nota sai normalmente.

A referência é o Ato Conjunto RFB/CGIBS número 4 de 2026. A data é da norma, não é nossa, e não é algo que o TexFiscal possa adiar para o seu cliente: no dia em que o provedor passar a exigir o grupo, a nota enviada sem ele volta recusada pela prefeitura.

Repare no que isso quer dizer para quem vende software. Se a sua base tem empresas do Simples e empresas de fora, você tem dois prazos para administrar, e o primeiro já passou de ser planejamento e virou calendário.

O que fazer agora, em quatro passos:

A ordem importa, porque o passo mais lento é o primeiro e ele não depende de você.

1. Peça os três códigos ao contador de cada empresa. CST, classificação tributária e indicador de operação. Não existe valor padrão razoável e ninguém pode adivinhar por ele: a classificação depende da atividade e do enquadramento.
2. Decida onde eles ficam. Os três podem ficar no cadastro do emissor, e aí toda nota daquele CNPJ sai com eles sem o seu sistema mudar nada. Ou podem ir em cada pedido, quando o mesmo CNPJ fatura atividades com classificação diferente.
3. Emita em homologação com o grupo ligado. A homologação fala com o ambiente de teste da prefeitura, é ilimitada e não custa nada. É aqui que um código no formato errado aparece, e aparece de graça.
4. Ligue em produção antes da data da empresa. Não espere o prazo virar: o grupo é aceito hoje, enquanto é opcional, e emitir com ele antes da obrigação é a forma barata de descobrir problema.

Como o TexFiscal trata o grupo hoje:

O grupo é aceito, validado e montado no XML, no formato que o schema do provedor define, e isso foi conferido em bancada contra o schema que traz o grupo. Ele entra como último elemento da declaração, que é o que a sequência do schema exige: fora de posição, o documento inteiro é recusado.

Três comportamentos valem a pena conhecer antes de integrar.

O grupo é tudo ou nada. Mandar CST sem a classificação tributária não passa no schema do provedor, e descobrir isso na prefeitura custa um RPS: a numeração é consumida e a nota volta recusada. Por isso a recusa acontece aqui, antes de reservar número, com a mensagem dizendo exatamente qual campo faltou.

O pedido vence o cadastro. Se os três códigos estão no cadastro do emissor e o pedido manda outros, valem os do pedido. Isso existe porque um mesmo CNPJ pode faturar atividades com classificação diferente, e travar no cadastro obrigaria a abrir um segundo emissor.

Máscara não derruba a nota. Ponto e traço nos códigos são limpos antes da conferência. O que é recusado é o número de posições errado, porque aí o dado está mesmo errado.

POST /v2/nfse?ref=venda-000123
Authorization: Basic base64("SEU_TOKEN:")
Content-Type: application/json

{
  "tomador": { "...": "..." },
  "servico": {
    "valor_servicos": 150.00,
    "aliquota": 2.00,
    "item_lista_servico": "4.10",
    "discriminacao": "Consulta nutricional mensal.",
    "ibs_cbs": {
      "cst": "000",
      "classificacao_tributaria": "000001",
      "indicador_operacao": "100101",
      "indicador_destinatario": "0",
      "uso_consumo_pessoal": "0"
    }
  }
}

{
  "codigo": "requisicao_invalida",
  "mensagem": "A requisição não passou na validação.",
  "erros": [
    {
      "codigo": "servico.ibs_cbs",
      "mensagem": "Grupo de IBS e CBS incompleto: falta servico.ibs_cbs.classificacao_tributaria.",
      "correcao": "O grupo é tudo ou nada: informe os três códigos, ou omita servico.ibs_cbs por inteiro enquanto ele for opcional. Os três também podem ficar no cadastro do emissor."
    }
  ]
}

O que não fazemos, e por quê:

Não escolhemos CST, classificação tributária nem indicador de operação por ninguém, e não há valor padrão embutido em lugar nenhum. A razão é direta: um padrão no código seria autorizado em silêncio pela prefeitura e só apareceria na apuração, meses depois, como diferença de tributo. Quem responde por enquadramento é o contador da empresa, e o nosso papel é não atrapalhar.

Também não antecipamos nem adiamos prazo. A data é da norma. O que fazemos é aceitar o grupo desde já, enquanto ele é opcional, para que ninguém precise fazer essa mudança na véspera.

E não afirmamos mais do que medimos: o que está provado hoje é que o XML com o grupo valida contra o schema do provedor, que ele fica na posição que a sequência exige e que o XML sem o grupo continua válido. Quando o provedor passar a exigir o grupo, nada muda do lado do seu sistema, desde que os códigos estejam preenchidos.