Reforma Tributária e Simples Nacional: o que muda para quem desenvolve ERP e sistemas fiscais

A Reforma Tributária do Consumo deixou definitivamente de ser um assunto restrito ao departamento contábil.

Para quem desenvolve ERP, sistemas fiscais, plataformas de faturamento, PDV, e-commerce, integrações contábeis, emissores de NF-e, NFC-e e NFS-e, as alterações publicadas pelo Comitê Gestor do Simples Nacional representam mudanças que atingem diretamente modelagem de dados, regras de negócio, motores tributários, cadastros, emissão fiscal, apuração e integrações.

Em agosto de 2026, o Comitê Gestor do Simples Nacional atualizou sua regulamentação para incorporar CBS — Contribuição sobre Bens e Serviços e IBS — Imposto sobre Bens e Serviços às regras do regime.

As alterações decorrem principalmente das Resoluções CGSN nº 190 e nº 191/2026, dando continuidade à adaptação da Resolução CGSN nº 140/2018 às Leis Complementares nº 214/2025 e nº 227/2026. Em regra, as mudanças da Resolução nº 190 produzirão efeitos a partir de 1º de janeiro de 2027.

Para o programador, porém, a data importante não é janeiro de 2027.

A data importante é agora.

Porque sistema tributário não pode começar a ser desenvolvido no dia em que a legislação entra em vigor.

O primeiro erro que o desenvolvedor precisa evitar: tratar o Simples Nacional como uma simples flag

Durante muitos anos, vários sistemas trabalharam com estruturas semelhantes a:

OPTANTE_SIMPLES = "S"
REGIME_TRIBUTARIO = 1

E, a partir dessas informações, inúmeras regras tributárias eram determinadas.

Esse modelo começa a se tornar insuficiente.

A regulamentação permite que uma empresa continue optante pelo Simples Nacional e, ao mesmo tempo, escolha recolher CBS e IBS pelo regime regular, fora do DAS.

Empresa do Simples não significa necessariamente CBS e IBS dentro do Simples.

Para arquitetura de software, isso é extremamente importante.

O regime tributário da empresa deixa de poder ser interpretado simplesmente como uma condição binária.

O cadastro tributário precisa evoluir

Um ERP preparado para 2027 deveria conseguir representar, no mínimo:

empresa não optante pelo Simples Nacional;
empresa optante pelo Simples com CBS e IBS dentro do regime;
empresa optante pelo Simples com CBS e IBS pelo regime regular;
período de validade da escolha;
data de início;
data de término;
eventual continuidade ou renúncia da opção.

Tecnicamente, seria pouco recomendável criar simplesmente:

SIMPLES_HIBRIDO = "S"

Uma estrutura baseada em vigência seria muito mais adequada.

REGIME_EMPRESA
--------------
codigo_empresa
regime_geral
data_inicio
data_fim


REGIME_IBS_CBS
--------------
codigo_empresa
forma_recolhimento
data_inicio
data_fim
origem_alteracao
usuario_alteracao
data_alteracao

Assim, o software consegue responder à pergunta realmente importante:

Qual era o regime tributário aplicável a esta empresa na data desta operação?

E não apenas:

Qual é o regime tributário atual da empresa?

Essa diferença será fundamental em reprocessamentos, devoluções, notas complementares, auditorias e consultas históricas.

Regra tributária precisa ter temporalidade

A Reforma Tributária reforça algo que bons sistemas fiscais já deveriam fazer:

regra fiscal não pode ser hardcoded apenas pelo estado atual da legislação.

O sistema deve considerar elementos como:

tributo
vigencia_inicial
vigencia_final
tipo_operacao
regime_empresa
classificacao_tributaria
produto
servico
destino
origem
consumidor_final
contribuinte
aliquota
reducao
beneficio
credito

Isso será cada vez mais importante porque teremos um período de transição tributária em que regras antigas e novas conviverão durante vários anos.

Portanto, estruturas semelhantes a:

IF Simples
	CalculaSimples()
ELSE
	CalculaNormal()
ENDIF

tendem a ficar rapidamente insuficientes.

O motor tributário precisará responder a um conjunto muito maior de condições.

O chamado “Simples híbrido” exige atenção do ERP

Embora “Simples híbrido” seja uma expressão informal, ela descreve bem uma situação que o desenvolvedor precisa compreender.

A empresa poderá continuar no Simples Nacional para determinados tributos, enquanto CBS e IBS poderão ser apurados pelo regime regular.

Imagine:

Empresa XYZ

Regime:
Simples Nacional

IRPJ     -> Simples
CSLL     -> Simples
CPP      -> Simples
CBS      -> Regime Regular
IBS      -> Regime Regular

Perceba a consequência.

O sistema não poderá mais simplesmente perguntar:

A EMPRESA É SIMPLES?

Talvez tenha que responder primeiro:

QUAL O REGIME DO TRIBUTO?

Essa mudança conceitual é enorme.

O regime passa a ser potencialmente definido por tributo

Uma arquitetura mais preparada deveria permitir uma estrutura conceitualmente semelhante a:

Empresa
   |
   +-- IRPJ -> Simples Nacional
   |
   +-- CSLL -> Simples Nacional
   |
   +-- CPP  -> Simples Nacional
   |
   +-- CBS  -> Regime Regular
   |
   +-- IBS  -> Regime Regular

Naturalmente, a implementação final deverá acompanhar os layouts e regras oficiais.

Mas, do ponto de vista de engenharia de software, separar regime da empresa de regime aplicável ao tributo passa a ser uma decisão arquitetural importante.

Cuidado com tabelas de empresa excessivamente simplificadas

Muitos ERPs possuem atualmente algo parecido com:

CRT = 1

e grande parte da tributação deriva desse único campo.

O CRT continuará tendo sua importância na documentação fiscal conforme os layouts oficiais, mas internamente o ERP precisará armazenar informações adicionais para determinar corretamente a tributação.

A estrutura fiscal não deveria depender exclusivamente de um único campo.

EMPRESA
   ↓
REGIME TRIBUTÁRIO
   ↓
REGIME DO IBS/CBS
   ↓
OPERAÇÃO
   ↓
ITEM
   ↓
NCM / NBS / CLASSIFICAÇÃO
   ↓
CST
   ↓
cClassTrib
   ↓
ALÍQUOTA
   ↓
REDUÇÕES
   ↓
BASE DE CÁLCULO
   ↓
CRÉDITOS
   ↓
DOCUMENTO FISCAL

Quanto mais regras forem colocadas diretamente na tela de emissão da NF-e, mais difícil será manter o sistema.

O motor tributário deve ficar separado do emissor fiscal

Essa é uma recomendação especialmente importante para desenvolvedores de ERP.

Não transforme o código que gera XML em seu motor tributário.

São responsabilidades diferentes.

O motor tributário deveria determinar:

Base CBS
Alíquota CBS
Valor CBS

Base IBS
Alíquota IBS
Valor IBS

CST
cClassTrib
Redução
Diferimento
Crédito
Benefício
Fundamentação

Depois disso, outro componente transforma o resultado nos campos exigidos pelo documento fiscal.

Uma arquitetura saudável seria:

VENDA
   ↓
MOTOR TRIBUTÁRIO
   ↓
RESULTADO FISCAL
   ↓
GERADOR NF-e/NFC-e/NFS-e
   ↓
XML

E não:

VENDA
   ↓
IF CST == ...
IF SIMPLES == ...
IF UF == ...
IF NCM == ...
   ↓
XML

O segundo modelo rapidamente se transforma em uma enorme coleção de condicionais difíceis de testar, auditar e manter.

Faturamento vinculado ao documento fiscal

Outro ponto extremamente relevante para quem programa ERP é a vinculação do faturamento utilizado na apuração do Simples Nacional à emissão do documento fiscal que formaliza a operação ou prestação.

A regulamentação também alcança operações para entrega futura e documentos que alterem ou complementem valores anteriormente registrados.

Isso merece muita atenção.

Existem sistemas que ainda utilizam:

data_pedido

ou:

data_venda

ou:

data_fechamento

como referência genérica para relatórios fiscais.

Essa prática precisa ser cuidadosamente revista.

Documento fiscal passa a ter importância ainda maior no reconhecimento da receita

Considere o seguinte exemplo:

Pedido:
28/01/2027

Faturamento interno:
30/01/2027

NF-e:
02/02/2027

Qual competência deve ser utilizada?

Não é prudente que o programador responda essa pergunta simplesmente observando o campo data_venda.

O ERP precisa diferenciar claramente eventos como:

data_pedido
data_negociacao
data_faturamento_interno
data_emissao_documento
data_autorizacao
data_saida
data_cancelamento
data_contabilizacao

Misturar tudo em um único campo chamado:

DATA_VENDA

é cada vez mais perigoso.

Entrega futura exige tratamento específico

A regulamentação também trata expressamente de operações para entrega futura.

Isso significa que sistemas que trabalham com:

faturamento antecipado;
venda para entrega futura;
remessas;
faturamento parcial;
notas complementares;
ajustes;
devoluções;

precisam manter uma relação documental consistente entre os eventos.

Uma venda não deveria ser simplesmente um registro isolado.

Ela pode possuir uma verdadeira árvore documental:

PEDIDO 12345
│
├── NF-e faturamento 1001
│
├── NF-e remessa 1057
│
├── NF-e remessa 1062
│
├── NF-e complementar 1080
│
└── NF-e devolução 1122

O ERP precisa saber que todos esses documentos pertencem à mesma operação econômica.

Notas complementares tornam a rastreabilidade indispensável

Se um documento fiscal altera ou complementa valores anteriormente registrados, o sistema precisa conseguir identificar:

qual documento originou a operação;
qual documento foi complementado;
qual valor original;
qual valor foi alterado;
qual tributo sofreu alteração;
em qual período ocorreu;
qual impacto deve ser produzido na apuração.

Uma estrutura explícita de relacionamento documental é muito mais segura do que tentar reconstruir tudo futuramente através da leitura dos XMLs.

RBT12 e FS12 também entram na revisão

A regulamentação atualiza conceitos relacionados à empresa em início de atividade, data de início de atividade, Receita Bruta Acumulada dos 12 meses anteriores — RBT12 — e Folha de Salários dos 12 meses anteriores — FS12.

Para desenvolvedores de sistemas contábeis ou fiscais, isso significa que rotinas consideradas estáveis precisam ser novamente avaliadas.

Especial atenção deve ser dada aos sistemas que mantêm cálculos próprios de:

RBT12
FS12
fator R
faixa do Simples
alíquota efetiva

Não basta atualizar apenas uma tabela de alíquotas.

É preciso revisar a origem de cada variável do cálculo.

Bens materiais, imateriais, direitos e serviços

A regulamentação passa a mencionar expressamente receitas decorrentes de operações com:

bens materiais;
bens imateriais;
direitos;
serviços.

Isso é outro sinal importante para desenvolvedores.

O tradicional cadastro:

TIPO_ITEM:
P = Produto
S = Serviço

pode se tornar conceitualmente pobre para determinadas soluções.

Dependendo do segmento atendido pelo ERP, a modelagem poderá precisar distinguir:

Produto físico
Serviço
Direito
Licença
Software
Assinatura
Bem digital
Ativo
Locação
Cessão

A classificação tributária oficial deverá sempre seguir as tabelas e regras publicadas pelos órgãos competentes, mas a modelagem interna precisa permitir essa evolução.

Juros, multas, gorjetas, acréscimos e encargos não podem ficar esquecidos

A atualização normativa também esclarece o tratamento de valores como:

gorjetas;
juros;
multas;
acréscimos;
encargos.

Esse é um alerta para sistemas que possuem somente:

valor_produto
desconto
frete
total_nota

O ERP precisa conhecer semanticamente a composição financeira da operação.

Não é recomendável trabalhar apenas com um campo genérico como:

OUTRAS_DESPESAS

quando diferentes componentes podem possuir tratamentos tributários distintos.

CBS e IBS recolhidos pelo regime regular e a receita do Simples

Outro ponto relevante é que os valores de CBS e IBS recolhidos pelo regime regular não devem ser confundidos com a receita bruta considerada para fins do Simples Nacional.

Isso significa que o sistema precisa entender que:

Valor total da operação

não é necessariamente igual a

Receita considerada para determinado cálculo tributário

Em muitos sistemas antigos, o total da venda é reutilizado indiscriminadamente em diversas rotinas.

Um modelo mais seguro trabalha com grandezas distintas:

valor_operacao
valor_documento
receita_contabil
receita_simples
base_cbs
base_ibs
base_icms
base_iss

Cada uma deve possuir sua própria regra de formação.

Não derive tudo do total da nota

Evite uma lógica simplificada como:

ReceitaSimples := TotalNota

É mais seguro trabalhar com uma função conceitualmente semelhante a:

ReceitaSimples :=
	CalculaReceitaTributaria(
		Documento,
		Regime,
		Periodo,
		ComposicaoValores
	)

Porque o mesmo valor financeiro pode representar coisas tributariamente diferentes dependendo da composição da operação.

O sublimite de R$ 3,6 milhões entra novamente no radar do desenvolvedor

A regulamentação relaciona o sublimite de R$ 3,6 milhões ao recolhimento de IBS, ICMS e ISS dentro do Simples Nacional, além das regras próprias relativas às exportações.

Para sistemas, isso significa revisar rotinas que hoje verificam sublimites apenas pensando em ICMS ou ISS.

E existe uma recomendação importante:

não coloque limites legais diretamente espalhados pelo código-fonte.

Evite:

IF RBT12 > 3600000

Prefira algo conceitualmente semelhante a:

nSublimite := GetParametroFiscal(
	"SUBLIMITE_SIMPLES",
	dDataOperacao
)

Ou, melhor ainda, utilize tabelas tributárias versionadas.

Legislação fiscal possui três características conhecidas por qualquer desenvolvedor brasileiro:

muda;
possui vigência;
pode mudar novamente.

Portanto, parâmetros fiscais devem estar em dados e regras versionadas, e não espalhados por centenas de fontes.

Créditos de IBS e CBS entram definitivamente no radar do ERP

As novas regras também disciplinam situações relacionadas à apropriação de créditos de ICMS, IBS e CBS pelos adquirentes.

Isso significa que um ERP não pode enxergar uma nota de entrada apenas como:

Débito:
Fornecedor

Crédito:
Estoque

A aquisição pode produzir informações fiscais relevantes para aproveitamento de crédito.

Será cada vez mais importante armazenar a tributação por item.

Grave o resultado tributário do item

É arriscado calcular os impostos somente no momento da emissão e depois não manter os elementos utilizados para chegar ao resultado.

Uma estrutura fiscal de item deveria preservar informações suficientes para reconstruir o cálculo:

ITEM_FISCAL
-----------
produto
cfop
cst
cclass_trib

base_cbs
aliquota_cbs
valor_cbs

base_ibs
aliquota_ibs_uf
valor_ibs_uf

aliquota_ibs_municipio
valor_ibs_municipio

reducao
diferimento
credito
beneficio

regime_aplicado
versao_regra

Os campos finais dependerão naturalmente dos layouts oficiais.

O princípio é mais importante:

Nunca dependa exclusivamente de recalcular no futuro aquilo que foi efetivamente tributado no passado.

Versione as regras tributárias

Imagine uma venda realizada em 2027 sendo consultada em 2031.

Se o ERP recalcular essa operação utilizando regras de 2031, poderá apresentar um resultado diferente daquele utilizado na emissão original.

Considere armazenar algo semelhante a:

VERSAO_REGRA_FISCAL = "2027.01"

Ou relacionar cada cálculo diretamente à regra utilizada:

Operação
   ↓
Regra Tributária
   ↓
Versão
   ↓
Resultado

Isso cria auditabilidade.

MEI também exigirá ajustes nos sistemas

A regulamentação também amplia regras relacionadas à emissão de documentos fiscais pelo MEI.

Nas prestações de serviços continuará sendo utilizada a NFS-e de padrão nacional, enquanto para mercadorias e determinadas prestações de transporte a regulamentação prevê a utilização preferencial da Nota Fiscal Fácil — NFF.

Para desenvolvedores de soluções voltadas ao MEI, isso pode exigir revisão de:

emissores;
integrações;
APIs;
fluxos de faturamento;
armazenamento dos documentos;
sincronização das vendas.

DEFIS deixa de existir como obrigação separada

Outra mudança relevante é a incorporação das informações socioeconômicas e fiscais ao próprio PGDAS-D, deixando a DEFIS de existir como obrigação separada conforme a nova regulamentação.

Para sistemas contábeis isso significa revisar:

exportações
relatórios
obrigações acessórias
calendário fiscal
controle de pendências
integrações

Rotinas denominadas simplesmente:

GERAR DEFIS

precisarão ser reavaliadas conforme os novos procedimentos e layouts oficiais.

A arquitetura fiscal dos ERPs precisa mudar

Durante muitos anos, uma parte significativa dos sistemas fiscais brasileiros foi construída acumulando condições:

IF UF == "SP"
IF CST == "060"
IF CFOP == "5405"
IF Simples
IF ConsumidorFinal
IF NCM == ...

Cada nova exceção acrescentava outro IF.

A Reforma Tributária torna esse modelo ainda mais difícil de sustentar.

O caminho mais saudável é evoluir para um motor tributário orientado a regras.

ENTRADA

Empresa
Produto
Cliente
Operação
Origem
Destino
Data
Regime

      ↓

CLASSIFICAÇÃO

NCM
NBS
CST
cClassTrib
Natureza da operação

      ↓

MOTOR TRIBUTÁRIO

Regra vigente
Tributo
Base
Alíquota
Redução
Crédito
Benefício

      ↓

RESULTADO

CBS
IBS
ICMS
ISS
demais tributos

      ↓

DOCUMENTO FISCAL

Essa separação facilita manutenção, testes, evolução e auditoria.

Programadores precisarão conversar ainda mais com contadores

Existe também uma mudança cultural importante.

Programador não deve decidir sozinho a interpretação tributária.

Da mesma forma, a orientação contábil não deveria se limitar a frases como:

“Coloque CST X.”

A especificação ideal deveria informar:

OPERAÇÃO:
Venda de mercadoria adquirida de terceiros

REGIME:
Simples Nacional

CBS/IBS:
Regime regular

DESTINO:
Consumidor final

CLASSIFICAÇÃO:
...

CST:
...

cClassTrib:
...

BASE:
...

ALÍQUOTA:
...

CRÉDITO:
...

FUNDAMENTO:
...

A partir disso, o desenvolvedor transforma regra tributária em regra computacional.

Legislação não deve virar código diretamente

Esse é um princípio fundamental.

A legislação diz:

O que deve acontecer.

O contador ou especialista fiscal interpreta:

Como a regra se aplica à operação da empresa.

O analista transforma isso em:

Regra de negócio.

E o programador implementa:

Algoritmo.

Quando essas etapas são misturadas, surgem sistemas fiscais cheios de exceções e difíceis de explicar.

Testes automatizados serão cada vez mais indispensáveis

Um motor tributário para a nova realidade deveria possuir testes para cenários como:

TESTE 001
Empresa Simples
CBS/IBS dentro do Simples
Venda interna
Resultado esperado: ...


TESTE 002
Empresa Simples
CBS/IBS regime regular
Venda interna
Resultado esperado: ...


TESTE 003
Empresa Simples
CBS/IBS regime regular
Venda interestadual
Resultado esperado: ...


TESTE 004
Empresa não Simples
Regime regular
Resultado esperado: ...

Quando uma regra ou tabela tributária for atualizada, os testes precisam informar imediatamente quais cenários sofreram impacto.

Nunca teste apenas se a SEFAZ autorizou

Um dos erros mais comuns em desenvolvimento fiscal é considerar:

“A nota autorizou, então o cálculo está correto.”

Não necessariamente.

Autorização significa que o documento passou pelas regras de validação existentes naquele ambiente e naquele momento.

Isso não substitui validação tributária.

Um bom conjunto de testes precisa validar:

BASE
ALÍQUOTA
VALOR
CST
cClassTrib
TOTALIZAÇÃO
XML
ARREDONDAMENTO
REGIME
VIGÊNCIA

Auditoria precisa fazer parte do sistema

Com tantas regras, o usuário deveria conseguir perguntar:

Por que o sistema calculou este imposto?

E o ERP deveria ser capaz de responder.

CBS calculada: R$ 92,10

Base:
R$ 10.000,00

Alíquota:
0,921%

Regime:
Regular

Regra:
RT-CBS-000145

Vigência:
01/01/2027 a 30/06/2027

Classificação tributária:
000001

Isso muda completamente o suporte técnico.

Em vez de:

“O sistema calculou assim.”

passamos para:

“O sistema calculou assim porque esta regra foi aplicada.”

Log tributário será tão importante quanto log de sistema

Um sistema fiscal moderno deveria possuir um verdadeiro log tributário.

12/01/2027 14:32:18

Empresa: 000001
Documento: 000145

Regime Empresa:
Simples Nacional

Regime CBS/IBS:
Regular

Regra aplicada:
RT-000087

Versão:
2027.01

Usuário:
MARCIO

Resultado:
Base CBS = ...
CBS = ...
IBS = ...

Em auditorias, suporte técnico ou fiscalização, essas informações podem ser extremamente valiosas.

Parametrização não significa liberar tudo ao usuário

Existe ainda outro risco.

Alguns sistemas tentam resolver a complexidade permitindo que o usuário altere praticamente qualquer campo fiscal.

Isso pode ser tão perigoso quanto deixar tudo hardcoded.

Um ERP moderno precisa distinguir:

configuração permitida

de:

regra legal obrigatória.

Quando uma determinada combinação é incompatível com a operação, o sistema deveria bloquear ou alertar o usuário, em vez de simplesmente permitir qualquer parametrização.

Um bom ERP precisa trabalhar com três níveis

1. Regra legal

O sistema conhece as combinações permitidas e as situações incompatíveis.

2. Parametrização contábil

A contabilidade informa como determinada operação da empresa deverá ser tratada dentro das possibilidades legais.

3. Operação do usuário

O usuário realiza a venda, compra ou movimentação sem precisar conhecer dezenas de códigos tributários.

Esse modelo reduz significativamente erros.

Datas e opções tributárias também devem fazer parte do histórico

Para 2027 foram estabelecidos períodos específicos relacionados às opções do Simples Nacional e à escolha pelo recolhimento regular de CBS e IBS.

Isso reforça um conceito importante para desenvolvimento:

regime tributário precisa possuir histórico.

Evite simplesmente sobrescrever:

REGIME = NOVO

Prefira armazenar períodos:

01/01/2027 até 30/06/2027 -> REGIME A
01/07/2027 até ...        -> REGIME B

Checklist técnico para quem desenvolve ERP

Cadastro da empresa

regime tributário;
opção pelo Simples;
regime específico de CBS e IBS;
vigência das opções;
histórico das alterações.

Cadastro fiscal

CST;
cClassTrib;
NCM/NBS;
natureza da operação;
benefícios;
reduções;
créditos.

Motor tributário

CBS;
IBS;
ICMS;
ISS;
coexistência dos tributos durante a transição;
vigência das regras.

Documentos fiscais

NF-e;
NFC-e;
NFS-e;
documentos complementares;
devoluções;
operações de entrega futura;
relacionamento entre documentos.

Faturamento

data da operação;
emissão fiscal;
competência;
cancelamentos;
complementos;
devoluções.

Simples Nacional

RBT12;
FS12;
sublimites;
fator R;
composição da receita;
tratamento da CBS e do IBS quando recolhidos pelo regime regular.

Auditoria

regra aplicada;
versão;
vigência;
resultado do cálculo;
usuário;
origem da parametrização.

Testes

testes unitários;
testes tributários;
XML de referência;
totalizadores;
arredondamentos;
cenários por regime.

A Reforma Tributária não é apenas uma alteração no XML

Esse talvez seja o principal recado para programadores.

Seria um erro pensar:

“Quando sair a nova Nota Técnica eu acrescento as tags de IBS e CBS.”

As tags são somente a camada externa.

Por baixo delas existe:

CADASTRO
   ↓
CLASSIFICAÇÃO
   ↓
REGRA
   ↓
CÁLCULO
   ↓
CRÉDITO
   ↓
APURAÇÃO
   ↓
DOCUMENTO
   ↓
CONTABILIDADE

Se o sistema apenas acrescentar campos ao XML sem modificar a inteligência tributária que existe por trás deles, estará apenas colocando uma nova interface sobre uma arquitetura antiga.

A oportunidade para os desenvolvedores de ERP

Existe também um lado extremamente positivo.

A Reforma Tributária está obrigando os sistemas brasileiros a evoluírem.

Durante décadas, muitos ERPs acumularam regras fiscais como exceções.

Agora existe uma oportunidade de transformar isso em algo muito mais estruturado:

um verdadeiro motor tributário.

Com:

regras versionadas;
vigências;
classificação tributária;
cálculo centralizado;
auditoria;
testes automatizados;
parametrização controlada;
histórico;
rastreabilidade.

Essa arquitetura não serve somente para IBS e CBS.

Ela prepara o ERP para qualquer alteração tributária futura.

Na Inteligence Gestão, estamos tratando a Reforma Tributária como mudança de arquitetura

Na Inteligence Gestão, nossa visão é que a Reforma Tributária não deve ser tratada apenas como inclusão de novos campos fiscais.

O objetivo é fazer com que o Inteligence ERP compreenda cada vez mais o contexto da operação e utilize regras de validação para evitar que combinações fiscais inconsistentes avancem até a emissão do documento.

O usuário não deveria precisar decorar todas as regras tributárias para realizar uma venda.

Ao mesmo tempo, o sistema também não pode substituir a orientação da contabilidade.

Por isso trabalhamos com uma divisão clara:

a legislação estabelece as possibilidades;
a contabilidade define o tratamento fiscal da empresa;
o Inteligence ERP transforma essa orientação em regras operacionais e validações;
e o usuário executa a operação com o máximo possível de segurança.

Para o programador, 2027 já começou

A legislação estabelece que diversas alterações produzirão efeitos a partir de 1º de janeiro de 2027.

Mas, para quem desenvolve software fiscal:

2027 já começou.

Porque antes da entrada em produção existem várias etapas:

Estudo
↓
Modelagem
↓
Desenvolvimento
↓
Integração
↓
Testes
↓
Homologação
↓
Treinamento
↓
Produção

E nenhuma dessas etapas deveria acontecer na última semana de dezembro.

A Reforma Tributária do Consumo não representa somente a chegada de IBS e CBS.

Para os desenvolvedores brasileiros ela representa uma mudança ainda maior:

Estamos deixando a era dos sistemas que apenas preenchem impostos e entrando na era dos sistemas que precisam compreender regras tributárias.

E provavelmente os ERPs que melhor atravessarão essa transição não serão simplesmente aqueles que conseguirem gerar o novo XML.

Serão aqueles capazes de explicar por que cada campo daquele XML foi gerado daquela forma.

Fonte: Receita Federal do Brasil — CGSN atualiza regras do Simples Nacional para adequação à Reforma Tributária do Consumo .

Inteligence - Gestão Empresarial Completa