O que significa “regime dual” no checkout B2B

Regime dual significa que entre janeiro de 2027 e 2029, você precisa rodar dois sistemas de cálculo de imposto simultaneamente. Um pedido pode estar sujeito a CBS (novo), ou ICMS (antigo), ou CBS + ICMS, ou nem um nem outro dependendo do produto e cliente.

Definição técnica

Regime dual é o período de transição onde o RFC permite que contribuintes usem os dois regimes conforme a regra de produto e localização de cliente. Um produto vendido para CNPJ em MG pode estar em ICMS, enquanto o mesmo produto para CNPJ em SP pode estar em CBS, enquanto produto diferente pode estar em regime misto (e um terço do imposto em CBS e dois terços em ICMS, por exemplo).

Motor fiscal não pode ignorar isso. Não pode simular. Precisa calcular os dois, registrar os dois, e deixar o checkout decidir qual usar baseado em regra de negócio (qual regime estou obrigado a usar hoje para esse cliente).

Por que dual e não substituição direta

Se fosse simples substituir ICMS por CBS, seria uma chamada de parametrização no ERP, feito. Mas não é. A Reforma dá um período de transição porque: 1. Nem todo produto está coberto por CBS em 2027. Alguns ficam em ICMS até 2029. 2. Nem todo estado adota CBS na mesma data. São transições cascata por estado. 3. Alguns clientes têm privilégio tributário (ex: produtor rural). Precisam calcular diferente. 4. Alguns produtos têm alíquota reduzida que só vale para ICMS, não para CBS.

Por isso existe transição. Motor precisa saber se está em regime dual, calcular ambos, registrar ambos.

Se você tenta simples “trocar de regime”, descobrir em auditoria que cálculo estava errado custa passivo tributário + multa + juros.

Arquitetura do motor dual

Aqui está como um motor fiscal roda regime dual sem quebrar performance.

Pipeline de cálculo

1. Checkout envia request:
   {
     cliente_cnpj: "123...",
     uf: "SP",
     produto_id: "456",
     quantidade: 5,
     valor_base: 1000,
     timestamp: "2026-05-06T14:30:00Z"
   }

2. Motor fiscal recebe e inicializa dois cálculos paralelos:
   - Thread 1: calcula ICMS conforme alíquota SP para produto 456
   - Thread 2: calcula CBS conforme alíquota federal para produto 456

3. Motor consulta regra de vigência:
   - ICMS ainda vale para produto 456 em SP até 31/12/2029?
   - CBS já vale para produto 456 em SP desde 01/01/2027?

4. Motor aplica alíquota vigente:
   - ICMS 7% (se vigente) = R$70
   - CBS 8% (se vigente) = R$80

5. Motor escolhe qual usar:
   - Baseado em "data de vigência" da regra
   - Produto 456 migra para CBS em 15/06/2026 (data que RFC publicou)
   - Antes: usa ICMS. Depois: usa CBS.

6. Motor registra ambos:
   - Log A: "ICMS 7% - motivo: vigência até 31/12/2029"
   - Log B: "CBS 8% - motivo: vigência desde 01/01/2027"
   - Resultado final: R$80 (CBS é o vigente)

7. Motor retorna ao checkout:
   {
     valor_tributo: 80,
     regime_aplicado: "CBS",
     icms_fallback: 70,
     timestamp_regra: "2026-06-15T00:00:00Z"
   }

8. Checkout exibe preço ao cliente: R$1.080 (base + tributo)

Tudo isto em menos de 50ms.

Cache e performance

Performance dual vem de cache agressivo.

O motor não consulta dados vigentes a cada request. Em vez disso: 1. Snapshot de regras: a cada meia-noite, motor baixa todas as regras de alíquota, datas de vigência, produtos cobertos. Armazena em cache em memória (Redis). 2. Lookup em cache: quando request chega, motor não vai a banco de dados. Vai para cache em memória. Hit rate é ~99%. 3. Fallback a banco de dados: se regra não está em cache (porque RFC publicou mudança que motor ainda não capturou), motor vai a banco, valida, cacheia, e responde.

Resultado: 95% dos cálculos saem do cache em <5ms. Até 50ms é limite confortável.

Auditoria e logging

Cada cálculo é registrado em dois bancos separados.

Banco A: Log de cálculo (para debug interno) - Query: “motor calculou ICMS de quanto para cliente X em data Y?” - Resposta: logs de cada transação com todos os números intermediários - Usado por time técnico para entender o quê deu errado se algo errar

Banco B: Log de auditoria (para RFC se auditar) - Query: “em janeiro de 2027, produto Z estava em qual regime?” - Resposta: log estruturado (assinado, imutável) mostrando regra vigente, cálculo feito, resultado - Usado por auditor para reproduzir cálculo e validar

Ambos rodam em paralelo. Não é “depois captura”. É simultâneo.

Como o Syntax (motor Mastery) faz isso em produção

Syntax é o motor fiscal da Mastery que operacionaliza regime dual.

Stack técnica

Syntax foi desenhado sabendo que precisaria rodar em regime dual. Não é retrofit de sistema legado.

Tempo médio de resposta

Medida em produção (dados reais de clientes): - P50 (mediana): 8ms - P95: 25ms - P99: 45ms - P99.9: 52ms (ainda no SLA)

SLA do Mastery é <100ms. Mas operação real fica em 8ms a 45ms por 99.9% das requisições.

SLA de disponibilidade

Isso importa porque um erro tributário é erro fiscal. Erro fiscal custa multa. Multa vira P&L.

Casos de borda: produtos com tratamento especial

Regime dual fica complicado quando você tem produtos que não cabem em “ICMS até 31/12/2029 depois CBS”.

Imposto Seletivo + IBS/CBS + ICMS-ST

Alguns produtos (bebida, energia, combustível) têm Imposto Seletivo. Imposto Seletivo é um terceiro sistema. Pode ser aplicado junto com IBS, junto com CBS, ou junto com ICMS dependendo da data.

Exemplo: cerveja vendida para distribuidora em MG em setembro de 2028. - Imposto Seletivo: 25% (sempre aplica) - ICMS: 7% (ainda vigente em MG até 31/12/2029) - CBS: não aplica (porque ICMS ainda vale)

Motor precisa saber que produto é “cerveja”. Saber que data é “setembro 2028”. Saber que cliente é “MG”. Calcular: 25% Seletivo + 7% ICMS, não aplica CBS.

Mês depois, outubro 2028, mesma operação. Pode ser que RFC publicou que CBS passa a valer para bebida. Motor recalcula automaticamente.

Por isso motor não é “configurar uma vez e esquecer”. É adaptação contínua conforme regras saem.

Vendas interestaduais com DIFAL

DIFAL é um cálculo especial para venda entre estados. Simplificado: imposto é dividido entre UF de origem e UF de destino.

Quando a Reforma sair, DIFAL vai ter versão IBS-izada também. Mas durante transição, pode ser que DIFAL valha para alguns estados em ICMS-ST (substituto tributário), enquanto em outros estados não vale porque CBS já cobriu.

Motor precisa saber a régua de DIFAL por estado e por data. Calcular correto.

Isso é detalhe que quebra implementação simples. Por isso não é “cálculo em spreadsheet”, é sistema.

Como fazer o A/B test interno entre os dois sistemas

Antes de colocar regime dual em produção real, você quer validar que motor está calculando certo.

Técnica: shadow mode.

  1. Rota 1: checkout chama motor Mastery com regime dual. Motor retorna preço final.
  2. Rota 2 (shadow): checkout também chama sistema antigo (ICMS-only) com mesmo input. Recebe preço antigo.
  3. Comparação: backend registra ambas as respostas e compara. - Se preço final é o mesmo (porque ICMS ainda é vigente), test passou. - Se preço final é diferente (porque CBS deveria valer), motor precisa ser ajustado.

Shadow mode roda por 2 a 4 semanas. Você vê 100% das transações em paralelo. Nenhuma transação real usa o novo motor ainda. Você só está observando.

Depois de 2 a 4 semanas, se acurácia é >99.99%, você liga o novo motor para 10% do tráfego real. Acompanha por 1 semana. Depois 50%. Depois 100%.

Isso é “canary deployment”. Mitigou risco de erro em produção.

Erros comuns ao implementar regime dual e como evitá-los

Erro 1: ignorar datas de vigência

O que acontece: você implementa “CBS + ICMS simultâneos”, mas não valida quando cada um vale. Resultado: aplica CBS para clientes que ainda deveriam estar em ICMS.

Como evitar: toda regra de alíquota tem data de vigência associada. Validar a data no código. Teste com datas futuras (use mock de relógio do sistema).

Erro 2: não cachear regras

O que acontece: motor consulta banco de dados para cada transação para descobrir qual alíquota vale. Latência explode. Checkout fica lento.

Como evitar: implementar cache em memória. Snapshot de regras a cada meia-noite. Invalidar cache quando RFC publica mudança urgente (tem webhook para isso).

Erro 3: logar incompleto

O que acontece: você tem log, mas log não tem informação suficiente para RFC entender o cálculo. Auditor pede esclarecimento. Você não consegue responder porque log não capturou.

Como evitar: cada log precisa ter: input (cliente, produto, data), cálculos intermediários (qual alíquota foi buscada, por quê), output final, hash de validação. Estruturado, não texto livre.

Erro 4: não rodar teste de regressão

O que acontece: você muda uma regra para dar suporte a novo produto. Acaba mudando alíquota de outro produto por acidente. Produto antigo começa a calcular errado, ninguém percebe por 2 meses.

Como evitar: suite de testes automatizados. 500+ cenários. Cada alteração de regra roda suite completa. Só deploy se suite passa.

Erro 5: não ter contingência

O que acontece: motor cai. Checkout fica parado. Não consegue emitir pedidos. Empresa fica sem vender por 30 minutos até arrumar.

Como evitar: ter contingência. Se motor não responde em 100ms, checkout usa valor padrão (por exemplo, aplica ICMS com alíquota conservadora). Pedido sai, depois reconcilia. Nunca é 0 venda, é apenas reconciliação manual.

Perguntas frequentes

Como rodar IBS e ICMS simultâneos sem perder performance?

Usar cache agressivo de regras em memória, não em banco de dados. Cada alíquota é consultada do cache (~5ms). Banco é fallback (<50ms). SLA total <100ms. Syntax roda em 8ms mediana.

Qual a diferença entre regime dual e migração direta?

Regime dual significa você roda dois sistemas em paralelo e decide qual usar baseado em data de vigência de cada regra. Migração direta seria “trocar de ICMS para CBS de uma vez”, sem paralelo. Reforma não permite migração direta, por isso existe transição.

Como auditar cálculos em regime dual?

Cada transação tem log estruturado com: input, alíquota vigente na data, cálculo feito, resultado. Log é assinado (hash). Se RFC questiona número X, você abre log, mostra regra vigente na data, mostra cálculo, pronto. Reproduzível, não manual.

Quanto tempo o motor leva para calcular IBS e CBS no checkout?

Syntax (motor Mastery) entrega em mediana 8ms, P95 25ms, P99 45ms. SLA é <100ms. Performance dual não é pior que performance single-regime, porque usa cache. Latência vem do cache, não da complexidade do cálculo.

O que acontece com produtos sujeitos a Imposto Seletivo no regime dual?

Imposto Seletivo é um terceiro sistema que pode coexistir com ICMS, CBS, IBS. Motor calcula os três se necessário. Exemplo: cerveja tem Imposto Seletivo 25% + ICMS 7% (em 2027), depois Imposto Seletivo 25% + CBS 8% (em 2029). Motor sabe quando trocar.

Próximo passo: Ver demo do motor dual Mastery

Leituras relacionadas: - Reforma Tributária 2026 a 2032: roadmap operacional para e-commerce B2B - Como preparar seu e-commerce B2B para IBS/CBS sem refazer o ERP - Coexistência IBS/ICMS no checkout - Tecnologia Mastery