Reforma Tributária e Split Payment: Novos Atos Técnicos e Padrões Integrados para 2026/2027
A Reforma Tributária do Consumo (RTC) entrou em sua fase mais decisiva e prática. O cenário de incertezas que pairava sobre os departamentos fiscais e os times de engenharia de software começou a se dissolver com as publicações oficiais ocorridas na virada de setembro para outubro de 2026. Com a edição dos Atos Técnicos Conjuntos RFB/CGIBS nº 7 e nº 8, o ecossistema fiscal brasileiro passa por uma das maiores padronizações operacionais de sua história.
Até recentemente, empresas, desenvolvedores de sistemas ERP e instituições financeiras ou Prestadores de Serviços de Pagamento (PSPs) enfrentavam um dilema complexo: como adaptar arquiteturas legadas e meios de pagamento às exigências de apuração do Imposto sobre Bens e Serviços (IBS) e da Contribuição sobre Bens e Serviços (CBS)? A ausência de leiautes unificados e de regras operacionais para o modelo de Split Payment gerava gargalos e insegurança jurídica na preparação dos sistemas.
A resposta governamental veio de forma coordenada. A Secretaria Especial da Receita Federal do Brasil (RFB) e o Comitê Gestor do Imposto sobre Bens e Serviços (CGIBS) estabeleceram o arcabouço definitivo para a emissão de todos os documentos fiscais eletrônicos e definiram o funcionamento técnico da Plataforma Pública de Split Payment. A seguir, analisamos os 5 destaques mais impactantes dessas novas diretrizes técnicas.
1. A Unificação Técnica Total: Do Gás à Energia Elétrica, Tudo Muda
O Ato Técnico Conjunto RFB/SUFIS/CGIBS nº 8, de 29 de setembro de 2026, consolidou a padronização das especificações técnicas da CBS e do IBS para praticamente toda a infraestrutura de documentos fiscais eletrônicos do país. Em paralelo, o Ato Técnico Conjunto nº 7/2026 definiu as diretrizes relativas à Nota Fiscal de Serviço Eletrônica (NFS-e) e NFS-e Via.
A abrangência da norma é irrestrita e contempla os seguintes modelos de documentos fiscais:
- NF-e (modelo 55) e NFC-e (modelo 65)
- CT-e (modelo 57)
- NFCom (modelo 62)
- BP-e (modelo 63)
- NF3e (modelo 66)
- NFAg (modelo 75)
- NFGas (modelo 76)
Entre os instrumentos técnicos aprovados para a NF-e e NFC-e, destacam-se a NT 2025.002 v1.52 (Adequações RTC), NT 2026.002 v1.11 (Vendas presenciais/não presenciais com DANFE Simplificado Tipo 2), NT 2026.007 v1.10 (Emissão por Contribuinte exclusivo do IBS/CBS), NT 2026.008 v1.00 (Valor Líquido do Produto), NT 2026.010 v1.00 (DANFE Reforma Tributária) e o Informe Técnico 2025.002 v1.70 (Tabelas de CCT, CST e Crédito Presumido). Para os demais modelos (CT-e, NFCom, BP-e, NF3e, NFAg e NFGas), foi aprovada a Nota Técnica 2026.004 v1.00.
Esta cobertura universal — estendendo-se de contas de luz e saneamento ao transporte de passageiros e fornecimento de gás encanado — demonstra que o fisco não deixará "zonas cinzentas". A uniformização garante regras idênticas para a fiscalização, vedando brechas e estabelecendo critérios matemáticos rígidos para a apropriação e validação de créditos de IBS e CBS.
"Art. 1º Fica aprovada a documentação técnica a seguir indicada, cujas especificações se aplicam à CBS e ao IBS, constituída pelos seguintes instrumentos: I - относительно à Nota Fiscal Eletrônica - NF-e, modelo 55, e à Nota Fiscal de Consumidor Eletrônica - NFC-e, modelo 65..." (Ato Técnico Conjunto RFB/SUFIS/CGIBS nº 8/2026)
2. Split Payment: Arquitetura Leve, Baixo Acoplamento e Alta Escala
Desenvolvida pelo Serpro para a Receita Federal e para o CGIBS, a Plataforma Pública de Split Payment teve seus requisitos detalhados no Manual de Integração Versão 1.0. A arquitetura foi concebida sob rigorosos princípios de engenharia de software: baixo acoplamento e alta coesão.
A plataforma atua estritamente como um HUB de comunicação centralizado e ponto único de contato entre as instituições operadoras de sistemas de pagamento/PSPs (produtores de dados) e os entes governamentais (RFB e CGIBS). Ela não implementa regras de negócio nem executa a arrecadação direta ou a apuração assistida dos tributos; sua função primária é receber eventos, aplicar validações sintáticas e semânticas, registrar dados de auditoria e retransmitir informações ao destino adequado.
A API mapeia seus fluxos através de verbos e endpoints HTTP específicos:
- Informe de Transação Iniciada: Transmitido via método
`POST`
(ex:
`/api/v1/boleto`
,
`/api/v1/pix-dinamico`
,
`/api/v1/pix-automatico`
). * Informe de Transação Atualizada: Atualizações cadastrais enviadas via método
`PATCH`
(ex:
`/api/v1/boleto`
,
`/api/v1/pix-dinamico`
). * Informe de Baixa (Excepto por Pagamento): Registro de cancelamento ou expiração enviado via método
`POST`
(
`/api/v1/{arranjo}/baixa-exceto-pagamento`
). * Informe Preliminar de Pagamento: Notificação de pagamento no PSP via método
`POST`
, englobando os arranjos Boleto, Pix Dinâmico, Pix Automático, Pix Estático, TED e TEF. * Informe de Segregação (transação financeira liquidada): Ocorre em três etapas via chamadas
`POST`
para abertura (
`/segregacao`
), envio de lotes (
`/segregacao/{idInfSegr}/lotes`
) e finalização (
`/segregacao/finalizacao`
).
Do ponto de vista volumétrico, o manual estabelece uma restrição técnica objetiva: cada informe enviado via API poderá conter, no máximo, 1.000 transações por requisição no objeto `TRANSACAOES [1..n]`. Envios que superem esse limite serão sumariamente rejeitados. Essa escolha arquitetural traz extrema previsibilidade técnica, garante escalabilidade para bilhões de transações diárias e reduz drasticamente os custos de desenvolvimento ao centralizar os padrões de integração.
"A Plataforma Pública de Split Payment funcionará como um HUB de comunicação entre as instituições operadoras de sistemas de pagamento ou prestadoras de serviços de pagamento eletrônico (PSPs) e os entes governamentais – Comitê Gestor do IBS (CGIBS) e Receita Federal do Brasil (RFB)... A Plataforma não implementa regras de negócio, seguindo os princípios de baixo acoplamento e alta coesão." (Manual de Integração - Plataforma Pública de Split Payment, Versão 1.0)
3. Operações Especiais: Regras Claras para Vendas Futuras, Perdas e Devoluções
O Ajuste SINIEF nº 49/2025 (com alterações consolidadas pelos Ajustes SINIEF 8/26, 15/26, 20/26 e 27/26) padronizou a emissão de documentos fiscais em cenários cotidianos que historicamente geravam divergências entre os estados.
As rotinas foram estruturadas com exigências de campos específicos para auditoria:
- Venda para Entrega Futura com Pagamento Antecipado: Exige a emissão de NF-e de saída utilizando o campo
`finNFe=6`
(Nota de Débito), o campo
`tpNFDebito=06`
(Pagamento antecipado), a descrição de natureza de operação
`natOp`
= "Venda para entrega futura - Pagamento antecipado" e CFOP 5.922 ou 6.922, emitida sem destaque do ICMS. Na saída efetiva da mercadoria, emite-se a NF-e normal (
`finNFe=1`
), referenciando no campo
`refNFe`
a chave de acesso da nota de débito original e aplicando o destaque do tributo. * Perda em Estoque (extravio, furto, roubo ou deterioração): O contribuinte deve emitir NF-e de saída (destinada a si mesmo) com
`finNFe=6`
(Nota de Débito),
`tpNFDebito=07`
(Perda em estoque), CFOP 5.927 e
`natOp`
= "Baixa de Estoque". É obrigatório o preenchimento do campo
`infAdFisco`
("Informações Adicionais de Interesse do Fisco") contendo a justificativa detalhada da baixa. Quanto ao ICMS, a redação original previa emissão sem destaque até 02/08/2026; a partir de 03/08/2026, por força do Ajuste SINIEF 20/26, passa a ser obrigatório o destaque do ICMS. * Redução de Valores ou Quantidades: Quando impossibilitado o cancelamento da NF-e original, o remetente emite NF-e de entrada como Nota de Crédito (
`finNFe=5`
), informando
`tpNFCredito=04`
(Redução de valores ou quantidades),
`natOp`
= "Redução de valores ou quantidades", preenchimento obrigatório da motivação em
`infAdFisco`
, vinculação da chave de acesso em
`refNFe`
e utilização do CFOP inverso. * Retorno por Recusa ou Não Localização: O remetente emite NF-e de entrada com
`finNFe=5`
(Nota de Crédito) e preenche o campo
`tpNFCredito`
com o código
`03`
(Retorno por Recusa Total na Entrega ou Por Não Localização do Destinatário na Tentativa de Entrega) ou
`06`
(Retorno por Recusa Parcial na Entrega).
Conforme estabelecido pela Cláusula Quinta-A (acrescida pelo Ajuste SINIEF 27/26), a observância desse ajuste passa a ser obrigatória a partir de 1º de janeiro de 2027, com produção de efeitos operacionais a partir de 3 de agosto de 2026. Essa uniformização exige uma revisão profunda nos Motores Fiscais dos ERPs, eliminando procedimentos manuais heterogêneos.
4. Long Polling e Tokens de Posição: Como os PSPs Lerão os Dados Fiscais
Para viabilizar o consumo contínuo de dados do "Super Inteligente" pelas instituições financeiras, a Plataforma Pública do Split Payment adotou a arquitetura de "pull-based event streaming". Essa decisão de design resolve um grande gargalo de infraestrutura: evita a necessidade de expor endpoints do tipo webhook nos PSPs, eliminando a complexidade de liberação de portas de firewall e os riscos de segurança associados ao recebimento não solicitado de chamadas governamentais.
O consumo ocorre por meio de requisições HTTP long polling estruturadas em fases:
- O PSP envia uma requisição
`GET`
para a URL de abertura
`/start`
. 2. A API responde com um
`streamId`
, as mensagens disponíveis (ou status
`204 - No Content`
caso a janela expire sem eventos) e um token de posição. 3. Para continuar o consumo, o PSP realiza chamadas
`GET`
subsequentes passando o token na URL:
`/stream/{token}`
. 4. Quando o PSP decidir encerrar o ciclo, envia uma requisição
`DELETE`
.
Para a recuperação de dados em cenários de reconexão ou perda de pacotes, a plataforma disponibiliza a Consulta Retroativa Super Inteligente, permitindo buscas por intervalo de NSU (parâmetros `fromNsu` e `toNsu`) ou por ID de stream especificamente mantida.
A resiliência do sistema baseia-se no padrão RFC 7807 (`application/problem+json`). Em momentos de limites de carga (rate limit — HTTP Status `429 Too Many Requests`), a API orienta o cliente via cabeçalho `Retry-After: 60`. Em instabilidades temporárias (`503 Service Unavailable`), retorna `Retry-After: 30`. Caso a fila interna do serviço fique indisponível, o mecanismo de Circuit Breaker é acionado: o circuito abre, e a API retorna `503 Service Unavailable` acompanhado dos headers `X-Circuit-Breaker: open` e `X-Retry-Allowed: false`, exigindo que as engenharias dos bancos apliquem rotinas rigorosas de exponential backoff.
5. Rastreabilidade de Ponta a Ponta: A Era do `correlationId`
Para assegurar auditabilidade irrefutável e viabilizar a rastreabilidade entre o fluxo financeiro do pagamento e o documento fiscal emitido, a Plataforma Pública de Split Payment definiu um conjunto estrito de cabeçalhos (headers) HTTP obrigatórios para todas as chamadas da API:
- `messageId`
: Identificador único da requisição no formato UUID v4 com comprimento exato de 36 caracteres (ex:
`550c8400-e29b-41d4-a716-446655440000`
), utilizado para prevenção de duplicidade de processamento. * `correlationId`
: String de controle para correlacionar múltiplos eventos da mesma transação, sujeita a uma restrição de formato rígida de exatamente 19 caracteres (Alfanumérico 19/19, ex:
`txn-20251222-abc123`
). * `tenantId`
: CNPJ do PSP ou instituição financeira cliente, formatado com 14 caracteres, garantindo suporte nativo a ambientes
multi-tenancy
. * `timestamp`
: Registro temporal no padrão ISO 8601 com 25 caracteres (ex:
`2025-12-22T14:30:45-03:00`
).
Além da obrigatoriedade de registrar esses cabeçalhos em logs de auditoria, as especificações exigem que as ferramentas de observabilidade das instituições (como OpenTelemetry) capturem esses campos para propagação distribuída de `traceId` e `spanId`. Essa arquitetura de rastreabilidade de ponta a ponta elimina divergências entre os dados do meio de pagamento e do documento fiscal, servindo de base para auditorias 100% automatizadas do fisco.
Conclusão
A publicação simultânea dos Atos Técnicos Conjuntos pela Receita Federal do Brasil e pelo Comitê Gestor do IBS, aliada às especificações do Serpro para o Split Payment e à consolidação das normas do Ajuste SINIEF 49/2025, encerra a fase de incertezas conceituais da Reforma Tributária do Consumo. As regras do jogo estão formalmente postas na forma de contratos de API, schemas JSON e diretrizes operacionais de baixo nível, exigindo uma transformação imediata na arquitetura dos sistemas de gestão e de meios de pagamento.
Para consultar a documentação técnica atualizada e efetuar o download dos schemas de validação, as organizações devem utilizar os repositórios oficiais centralizadores informados nas normas: o Portal SVRS (`dfe-portal.svrs.rs.gov.br`) e o Portal da NF-e (`www.nfe.fazenda.gov.br`). Considerando que os efeitos operacionais iniciam em 2026 e a obrigatoriedade plena passa a vigorar em 1º de janeiro de 2027, a sua empresa, sistema ERP ou instituição financeira já possui um plano de ação estruturado para integrar os conectores de streaming do Split Payment e adequar as novas rotinas fiscais a tempo?
Este texto tem caráter informativo e não substitui uma análise jurídica individualizada do caso concreto.