Se eu tivesse que resumir o Split Payment em uma frase bem honesta seria:

o imposto deixa de ser um “cálculo contábil” e vira um “evento do pagamento”.

E isso muda o jogo do fluxo de caixa.

Muita gente ainda fala “Split Payment” como se fosse um conceito genérico, quase um “vou pagar imposto automático e pronto”. Só que a legislação brasileira está desenhando esse negócio com regras operacionais: quem inicia a transação, quem informa o quê, quem segrega, quem recolhe, quem apanha se der errado.

A boa notícia: seu artigo original acertou o macro.
A notícia importante: agora o governo está cravando o micro — e é aí que mora o risco (e também a chance de se preparar melhor que a concorrência).

O que é Split Payment na prática

Split Payment é um mecanismo em que, no momento da liquidação financeira (quando o dinheiro “fecha” no pagamento), o valor do tributo é segregado e recolhido automaticamente, enquanto a empresa recebe o valor líquido.

Isso tem um impacto óbvio: o caixa muda de comportamento.
O imposto não “fica passeando” até o vencimento; ele tende a ser separado no ato.

E aqui entram detalhes que pouca gente comenta — mas que valem ouro:

• Acontece na liquidação financeira, e não “na emissão da nota”.
• Em vendas parceladas, a segregação tende a ser proporcional em cada liquidação (cada parcela).
• Em transações iniciadas por plataformas digitais, a lógica exige troca de informações para viabilizar a segregação (não é mágica; é integração).

Tradução: Split Payment não é só fiscal. É pagamentos + fiscal + tecnologia + processo.

O que a LC 214/2025 já tinha deixado claro (o “macro”)

A Lei Complementar 214/2025 colocou o Split Payment como mecanismo relevante dentro do ecossistema CBS/IBS, descrevendo a lógica de recolhimento atrelada à liquidação financeira, com participação de agentes de pagamento quando aplicável.

Essa lei é o alicerce: ela já deixava claro que o “caminho do dinheiro” muda.

Só que… faltava o manual do “quem faz o quê”, principalmente do lado dos intermediários do pagamento.

O que mudou com a LC 227/2026 (o “micro” ficou mais sério)

Aqui é onde a conversa ficou adulta.

A LC 227/2026 institui o Comitê Gestor do IBS (CGIBS) e, mais importante pra este artigo, refina o Split Payment com definições operacionais e responsabilização.

1) Procedimento padrão e procedimento simplificado

A LC 227/2026 passa a detalhar que o Split Payment pode ter procedimento padrão e procedimento simplificado.

Isso não é um detalhe “jurídico”: isso abre portas para modelos diferentes de operação conforme tipo de transação, maturidade do ecossistema e viabilidade técnica.

Meu conselho: trate isso como um sinal de que haverá fases e exceções operacionais. Quem achar que será “um único modelo para tudo” vai tropeçar cedo.

2) Quem é o “originador da transação de pagamento”

A lei traz definições do tipo:

• quem é o originador da transação;
• diferença entre transações iniciadas pelo recebedor vs pelo pagador.

Isso é um divisor de águas para processos. Porque você começa a ter perguntas bem concretas:

• Quem inicia o pagamento na sua operação?
  (PDV? e-commerce? link de pagamento? cobrança recorrente? portal B2B? marketplace?)
• Em que momento os dados fiscais “grudam” na transação?
  (antes de pagar? no checkout? no antifraude? no conciliador? no adquirente?)

Sem responder isso, você não “implanta Split Payment”. Você só coleciona hipóteses.

3) Penalidades e responsabilização do lado do pagamento

A LC 227/2026 traz um capítulo com penalidades administrativas no contexto do Split Payment para prestadores de serviço de pagamento / sistemas envolvidos.

E ainda delimita quando a responsabilidade do PSP pode ser excluída — por exemplo, quando a informação veio errada de outros elos (fornecedor/adquirente/plataforma).

Tradução bem direta:
o governo começou a apertar os parafusos do lado de quem processa pagamento.

E adivinha quem vai ter que escolher bem esse parceiro, exigir relatório, exigir trilha de auditoria e desenhar integração? Pois é.

2026 é o ano perfeito pra preparar (porque o impacto real vem quando a cobrança começar)

O alerta de fluxo de caixa continua 100% válido — só que o impacto de verdade tende a ficar mais sensível quando a cobrança estiver rodando com força.

Então eu enxergo 2026 como o ano da vantagem competitiva: não é o ano de “sofrer”, é o ano de “testar e blindar”.

E aqui entra uma realidade que eu vejo todo dia em projeto de ERP:
empresa que deixa preparação fiscal pra “virada do ano” sempre paga caro.

O que eu recomendo fazer agora (sem drama, com método)

1) Faça o “mapa do dinheiro” da sua empresa

Eu faria um desenho simples (pode ser até em papel) com:

• canais de venda (loja, e-commerce, B2B, marketplace, cobrança recorrente…)
• meios de pagamento (PIX, cartão, boleto, link…)
• quem inicia a transação (pagador x recebedor)
• onde nasce o dado fiscal (ERP? PDV? plataforma? integrador?)

Se você não consegue desenhar isso em 30 minutos, seu Split Payment não vai ser um “projeto fiscal”. Vai ser uma novela.

2) Transforme a escolha de gateway/PSP em decisão de compliance

A partir de agora, não é só taxa e prazo de recebimento.

Eu passaria a pedir do PSP/gateway:

• como ele vai operar Split Payment (padrão x simplificado)
• quais informações ele precisa receber (e de quem)
• como ele devolve relatórios de segregação e trilha de auditoria
• como fica conciliação: nota → pagamento → segregação → extinção do débito

Se o parceiro de pagamento não souber responder isso com clareza, ele não é “barato”. Ele é “caro escondido”.

3) ERP: prioridade não é “ter campo novo”, é ter dado certo

Split Payment + apuração assistida (e a tendência de automação) têm um efeito colateral inevitável:

dado ruim vira imposto ruim, no automático.

Então, do lado de ERP, eu focaria em:

• saneamento de cadastro (produtos/serviços, classificação, regras)
• governança de parametrização fiscal (quem muda regra, como testa, como aprova)
• conciliação ponta a ponta (nota → pagamento → segregação → débito extinto)

No mundo SAP Business One, isso normalmente vira um projeto em três trilhas:

1. localização fiscal
2. integração com meios de pagamento
3. BI/conciliação e auditoria

E sim: sempre vai ter alguém tentando vender internamente como “é só atualizar”.
Esse é o caminho mais rápido pra dor de cabeça.

4) Simule cenários de caixa com mais precisão

Você já falou disso, e eu reforço com o tempero certo:

Simule por:

• condição de pagamento (à vista x parcelado)
• canal (PIX x cartão x boleto)
• cliente (B2B x B2C)
• margem (onde qualquer mordida vira sangramento)

Split Payment mexe no timing do dinheiro. E fluxo de caixa é um bicho que odeia surpresas.

Checklist rápido (pra você e sua equipe não se perderem)

• Eu sei todos os meus canais de venda e meios de pagamento
• Eu sei quem inicia a transação (pagador vs recebedor) por canal
• Eu sei onde o dado fiscal nasce e onde ele se conecta ao pagamento
• Meu PSP/gateway consegue explicar Split Payment e entregar trilha de auditoria
• Meu ERP está com cadastros e regras sob governança (mudança controlada)
• Eu consigo conciliar nota → pagamento → segregação
• Eu rodei simulação de caixa por cenário (à vista/parcelado, PIX/cartão/boleto etc.)

Se você marcou pouca coisa, melhor saber agora do que no susto.

Conclusão: Split Payment é mais “pagamentos + processo” do que “fiscal”

A LC 214/2025 trouxe a base.
A LC 227/2026 começou a dar forma operacional e responsabilidade.

O Split Payment vai premiar empresas que tratam isso como transformação de processo (com tecnologia e governança), não como “ajuste de imposto”.

Eu acompanho esse tipo de mudança bem de perto porque, no fim do dia, quem sofre ou vence com isso é a operação: faturamento, tesouraria, fiscal, TI, comercial — todo mundo no mesmo barco.

Se você quiser, eu te ajudo a montar esse mapa do dinheiro e traduzir isso em plano de ação de ERP + meios de pagamento, sem terrorismo e sem achismo. É literalmente sentar, mapear, priorizar e testar. Me chama!