A pergunta de arquitetura não é “como calcular o novo imposto?”. É: o que acontece quando uma regra do domínio muda o próprio significado de “pagamento concluído”?

Nota de escopo: este artigo considera a documentação técnica disponível até agosto de 2026. O desenho operacional do split payment ainda está em evolução; no portal oficial do CGIBS, o Manual de Integração V1 e o OpenAPI estão publicados, enquanto outros materiais operacionais ainda aparecem como minutas.

Em agosto de 2026, o Comitê Gestor do IBS informou novos avanços na Plataforma Pública do Split Payment e reforçou que a documentação técnica já está disponível para que instituições financeiras, prestadores de serviços de pagamento e desenvolvedores preparem suas soluções.

À primeira vista, isso parece assunto para fiscal, contabilidade e financeiro.

Só que o desenho técnico oficial conta outra história.

O Manual de Integração descreve uma plataforma que recebe mensagens de transação, expõe endpoints HTTP, usa contratos baseados em OpenAPI, exige e propaga identificadores de correlação, devolve identificadores de controle como ResourceId, mantém trilhas de auditoria e define comportamento para erros transitórios, retries, backoff exponencial e circuit breakers.

Ou seja: a Reforma Tributária chegou ao território de sistemas distribuídos.

1. O que mudou de verdade

O split payment é um mecanismo em que valores de IBS e CBS podem ser segregados no fluxo da liquidação financeira da operação, em vez de toda a quantia seguir necessariamente para o fornecedor para que o tributo seja tratado apenas posteriormente.

A regulamentação da CBS, pelo Decreto nº 12.955/2026, e a do IBS, pela Resolução CGIBS nº 6/2026, preveem implementação gradual do split payment, em no mínimo duas etapas.

Em 2026, a implementação está em fase de testes, adaptação de sistemas e validação dos fluxos de informação.

Esse período ainda não representa a operação financeira plena e generalizada do split payment. Pelas regras de transição, há dispensa de recolhimento de IBS e CBS nas condições estabelecidas para o ano de testes.

O próprio contexto regulatório de agosto reforça essa característica de transição: em 6 de agosto de 2026, Receita Federal e CGIBS esclareceram o adiamento de determinadas regras de validação dos campos de IBS e CBS nos documentos fiscais eletrônicos.

Isso importa porque a mudança não adiciona apenas “mais dois campos tributários”.

Ela aproxima dois domínios que historicamente podiam ser tratados em momentos diferentes:

o fato fiscal e a liquidação do pagamento.

E essa aproximação muda o desenho dos sistemas.

2. Um pagamento de R$ 100 parece simples — até deixar de ser

Use um exemplo deliberadamente simplificado.

Os valores e a decomposição abaixo são apenas didáticos. Não representam alíquota, procedimento de cálculo nem todas as regras de determinação do valor efetivamente segregado.

A intenção é visualizar o impacto arquitetural, não reproduzir o algoritmo normativo do split payment.

ANTES — modelo mental simplificado

Cliente paga R$ 100
        |
        v
Pagamento aprovado
        |
        v
Liquidação
        |
        v
Empresa recebe
        |
        v
Fiscal / Financeiro / Contabilidade

Agora introduza, conceitualmente, uma segregação no momento da liquidação:

COM SPLIT PAYMENT — abstração arquitetural

Cliente paga R$ 100
        |
        v
Liquidação
     +-------+
     v       v
Empresa   IBS/CBS
R$ 82     R$ 18

R$ 100 = R$ 82 + R$ 18

O detalhe importante não é o R$ 18.

Na operação real, o valor efetivamente segregado depende das regras aplicáveis ao procedimento, podendo considerar, entre outros fatores, valores já extintos e ajustes previstos na regulamentação.

Para a arquitetura, o ponto relevante é outro:

valor da venda

valor pago

valor segregado

e

valor recebido

deixam de ser sinônimos convenientes.

Esse é o tipo de mudança aparentemente pequena que começa no domínio e termina atravessando boa parte da arquitetura.

3. A premissa escondida

Existe uma premissa particularmente interessante:

“Primeiro recebemos o dinheiro. Depois resolvemos o imposto.”

Talvez ninguém tenha escrito isso em uma especificação.

Mesmo assim, ela pode estar embutida em código, tabelas, ETLs, relatórios e integrações construídas durante anos.

Um sistema legado pode usar um único campo:

amount

e interpretar:

SETTLED

como:

todo o valor da operação já está disponível para a empresa.

Um data warehouse pode somar todos os pagamentos liquidados e chamar isso de cash_received.

Uma conciliação pode procurar correspondência 1:1 entre venda e crédito financeiro.

Quando o domínio muda, todos esses modelos podem continuar tecnicamente válidos.

A aplicação compila.

A query executa.

O dashboard abre.

Só que o significado do dado mudou.

E bugs semânticos têm uma característica perigosa:

o sistema pode continuar funcionando perfeitamente enquanto responde à pergunta errada.

Conceitualmente, algo que antes poderia ser modelado como:

const netReceived = payment.amount;

passa a precisar de algo mais explícito:

const settlement = {
  grossAmount: 100,
  taxSegregatedAmount: 18,
  netSettlementAmount: 82
};

Esse código também é apenas um exemplo de modelagem.

A mudança importante não está no cálculo.

Está no modelo de domínio.

4. Onde o problema técnico começa: correlação

Para separar corretamente valores no fluxo financeiro, não basta saber que houve um pagamento.

É necessário saber: a qual operação esse pagamento pertence?

E quais informações fiscais estão associadas a ela?

Aqui aparece um problema clássico de sistemas distribuídos.

Pedido, documento fiscal, pagamento, PSP, liquidação e ERP normalmente não compartilham um único identificador universal.

O Manual de Integração deixa essa necessidade evidente ao exigir headers como messageId e correlationId, além de identificadores presentes nos payloads de negócio, como txId, e2eId, docFiscal, idRepasse e idLote, conforme o fluxo.

É importante separar dois conceitos.

O correlationId tem papel técnico: ajuda a correlacionar múltiplos eventos e chamadas e deve ser propagado entre serviços para favorecer rastreamento distribuído.

Já a correlação de negócio depende dos identificadores que permitem relacionar operação comercial, documento fiscal, pagamento e demais registros do fluxo.

Separadamente, a Plataforma Pública devolve um ResourceId, que funciona como número de controle do recurso recebido e apoia sua rastreabilidade. Na V1 do manual, o mecanismo de consulta desse recurso ainda seria detalhado em versões posteriores.

Conceitualmente:

Pedido
  orderId=ORD-91827
      |
      v
Documento fiscal
  docFiscal=...
      |
      v
Pagamento
  txId=TX-77182
      |
      v
Plataforma Pública
      |
      +-- controle técnico:
      |   ResourceId=RES-...
      |
      v
Informe / fluxo de segregação

A capacidade de correlacionar operação comercial, documento fiscal e transação de pagamento deixa de ser apenas uma conveniência técnica e passa a ser requisito do próprio fluxo.

O correlationId contribui para o rastreamento distribuído, enquanto os identificadores presentes nos payloads e nos sistemas internos permitem estabelecer as relações de negócio necessárias entre esses registros.

5. O blast radius de uma regra tributária

Se você olhar apenas para o cálculo do imposto, o impacto parece localizado.

Se acompanhar a transação ponta a ponta, fica diferente:

Domínio
  |
  v
Checkout / Pedido
  |
  v
Documento fiscal
  |
  v
Pagamento / PSP
  |
  v
Plataforma Pública do Split Payment
  |
  v
Liquidação e segregação
  |
  v
Conciliação
  |
  v
ERP / Financeiro / Contabilidade
  |
  v
ETL / Data Lake / Analytics

Esse é o blast radius real.

Checkout e pedido

Talvez não sejam responsáveis pelo split em si.

Mas precisam preservar contexto suficiente para que a operação possa ser correlacionada posteriormente.

Perder contexto no começo da jornada pode transformar a conciliação em um problema impossível de resolver no final.

Documento fiscal

O documento fiscal ganha importância na vinculação entre a operação tributável e a transação de pagamento, ainda que a forma e a obrigatoriedade dessa identificação variem conforme o fluxo e o arranjo.

Pagamento e PSP

O fluxo financeiro precisa transportar ou relacionar contexto tributário.

Isso aumenta a importância de:

• contratos;
• versionamento;
• schemas;
• validação;
• compatibilidade;
• rastreabilidade.

Conciliação

Talvez seja onde a mudança se torna mais fácil de visualizar.

Antes poderíamos imaginar:

Venda:       R$ 100
Recebimento: R$ 100

MATCH

Agora, em uma abstração conceitual:

Venda:             R$ 100
Valor segregado:    R$ 18
Recebimento:        R$ 82

100 = 82 + 18

MATCH

Conciliação deixa de significar apenas procurar igualdade.

Passa a significar explicar a decomposição de uma transação financeira.

ERP e financeiro

Os modelos internos precisam distinguir conceitos que talvez estivessem comprimidos em um único campo:

faturamento
pagamento
liquidação
segregação
recebimento líquido

Se tudo continuar chamado de valor_recebido, a complexidade não desaparece.

Ela reaparece em exceções.

Dados e analytics

O mesmo vale para métricas.

O que significa:

receita?
GMV?
cash-in?
valor pago?
valor liquidado?
valor segregado?
valor disponível em caixa?

Um dashboard pode continuar 100% verde enquanto mede um conceito que já não significa a mesma coisa.

6. A Plataforma Pública como hub: menos integrações, mais centralidade

Existe outro detalhe arquitetural muito interessante no desenho oficial.

O manual define a Plataforma Pública do Split Payment como um HUB de comunicação entre instituições operadoras de sistemas de pagamento/PSPs e os entes governamentais.

E diz explicitamente que a plataforma não pretende concentrar as regras de negócio do split payment, seguindo princípios de baixo acoplamento e alta coesão.

Arquiteturalmente, faz sentido.

Comparação arquitetural conceitual

Imagine uma integração ponto a ponto:

PSP A ---> RFB
PSP A ---> CGIBS

PSP B ---> RFB
PSP B ---> CGIBS

PSP C ---> RFB
PSP C ---> CGIBS

Agora compare com:

PSP A --+
PSP B --+---> Plataforma Pública ---> RFB / CGIBS
PSP C --+

Dentro desse fluxo, o desenho com HUB tende a reduzir integrações ponto a ponto que cada participante precisaria manter diretamente com os entes governamentais.

Padroniza integração.

Centraliza parte da comunicação.

Mas não existe arquitetura sem trade-off.

Reduzir acoplamento entre participantes não elimina dependências. Concentra parte delas em um componente que passa a exigir alta previsibilidade operacional.

Essa é uma interpretação arquitetural do desenho, não uma característica normativa declarada pela plataforma.

O HUB simplifica contratos.

Ao mesmo tempo, disponibilidade, capacidade, rastreabilidade e tratamento de falhas desse HUB tornam-se mais relevantes para o ecossistema.

7. “Pago” deixa de ser um estado suficiente

O manual não descreve apenas um único momento de “pagamento concluído”.

Ele separa diferentes tipos de informes, como:

• Informe de Transação Iniciada;
• Informe de Transação Atualizada;
• Informe de Baixa;
• Informe Preliminar de Pagamento;
• Informe de Segregação.

Arquiteturalmente, esses momentos sugerem um domínio que tende a ser melhor modelado com estados intermediários do que com um simples booleano de sucesso ou falha.

Exemplo conceitual de estados internos

Os estados abaixo não correspondem a uma máquina de estados oficial da Plataforma Pública. São apenas um modelo possível para uma aplicação que precise representar o lifecycle da operação.

INITIATED
   |
   +--> UPDATED
   |       |
   |       v
   |     PAID
   |       |
   |       v
   |  SETTLEMENT_PROCESSING
   |       |
   |       v
   |   SEGREGATED
   |       |
   |       v
   |   RECONCILED
   |
   +--> CLOSED / CANCELLED

Quando o negócio adiciona estados intermediários e o software insiste em representar tudo como:

SUCCESS
FAILED

a complexidade não desaparece.

Ela migra para:

• flags;
• cron jobs;
• jobs de correção;
• planilhas;
• scripts;
• reprocessamento manual.

Estados explícitos tornam problemas explícitos.

8. A parte mais interessante do manual não é o happy path

A documentação da plataforma dedica uma seção à política de tratamento de erros.

Ela distingue erros permanentes de falhas transitórias e estabelece situações em que retry é ou não permitido.

O documento fala explicitamente em:

• observabilidade ponta a ponta;
• correlação;
• backoff exponencial;
• circuit breakers.

Para alguns cenários, aparecem respostas como:

400 — requisição inválida
422 — regra não aceita
503 — indisponibilidade temporária
504 — dependência externa indisponível

com comportamentos diferentes para cada situação.

Isso revela um princípio muito maior do que split payment:

Em um sistema distribuído crítico, o contrato de erro é tão importante quanto o contrato de sucesso.

Não basta especificar:

200 OK

É necessário definir:

O que faço com timeout?

Posso tentar novamente?

Depois de quanto tempo?

Esse erro é permanente?

O sistema recebeu minha mensagem?

E se recebeu, mas eu não recebi a resposta?

9. Retry, duplicidade e idempotência

Imagine:

PSP ---> Plataforma Pública

timeout

Há pelo menos dois cenários possíveis.

Cenário A

A plataforma nunca recebeu a requisição.

Cenário B

A plataforma recebeu.

Processou.

Mas a resposta se perdeu.

Do ponto de vista do cliente, os dois cenários podem parecer iguais:

timeout

Se ele simplesmente repetir a operação, pode existir risco de processamento duplicado.

A documentação oficial já exige que o messageId seja único por requisição, justamente para evitar duplicidade, além de estabelecer mecanismos de correlação e rastreabilidade.

Isso, porém, não equivale por si só a uma garantia completa de idempotência de negócio.

Uma API pode reconhecer mensagens distintas e ainda assim uma aplicação precisar responder a perguntas como:

Esta operação financeira já produziu efeito?

Posso executar novamente com segurança?

O retry deve retornar o resultado anterior?

Existe uma chave de negócio capaz de impedir efeitos duplicados?

Por isso, a estratégia de idempotência continua sendo uma preocupação arquitetural que merece tratamento explícito pela aplicação.

O princípio permanece:

Retry sem idempotência de negócio pode transformar uma estratégia de resiliência em uma estratégia de duplicação.

10. Até o processamento em lote carrega trade-offs

O manual prevê o envio de lotes de transações durante determinados fluxos de segregação.

Antes de aceitar um lote, a plataforma faz validações de formato e obrigatoriedade dos campos.

Se existir erro em um ou mais itens, o lote inteiro é rejeitado e deve ser corrigido e reenviado.

Exemplo:

LOTE #9182

tx 001  OK
tx 002  OK
tx 003  ERRO — campo obrigatório ausente
tx 004  OK

Resultado:

LOTE REJEITADO

Agora existe uma decisão arquitetural interessante.

Por que não aceitar três registros e rejeitar apenas um?

Porque isso introduziria outra complexidade:

quais foram aceitos?
quais não foram?
posso reenviar apenas os rejeitados?
como evitar duplicidade?
como conciliar um lote parcialmente processado?

Rejeitar o lote inteiro simplifica consistência.

Mas aumenta o custo de reprocessamento.

Aceitar parcialmente reduziria reprocessamento.

Mas aumentaria o custo de reconciliação.

Não existe escolha gratuita.

Arquitetura é gestão de trade-offs.

11. Parcelamento mostra por que o problema não cabe em um único request

A regulamentação da CBS e a do IBS preveem que, em operações com pagamento parcelado pelo fornecedor, a segregação ocorra proporcionalmente durante a liquidação das parcelas.

Então uma operação deixa de ser:

Pedido
  |
Pagamento
  |
Split

e passa a viver no tempo:

Pedido R$ 1.000

Parcela 1 ---> liquidação ---> segregação
Parcela 2 ---> liquidação ---> segregação
Parcela 3 ---> liquidação ---> segregação
Parcela 4 ---> liquidação ---> segregação

A partir daí surgem questões como:

• cancelamento parcial;
• estorno;
• diferenças de valores;
• meios de pagamento múltiplos;
• reconciliação de parcelas;
• reprocessamento.

Nem todas essas perguntas são regras oficiais da Plataforma Pública.

Elas são consequências arquiteturais que surgem quando uma operação comercial deixa de ser tratada como um único evento e passa a possuir um lifecycle financeiro mais longo.

A transação não é mais apenas um request.

Ela é um processo com lifecycle.

12. Como eu abordaria essa mudança dentro de uma empresa

A partir daqui, saímos do que a documentação oficial determina e entramos em uma possível abordagem de arquitetura interna.

Eu não começaria perguntando:

“Quais telas precisamos alterar?”

Começaria pelo fluxo de domínio.

1. Mapear o fluxo financeiro real

Algo como:

Order
  |
Documento Fiscal
  |
Payment
  |
Settlement
  |
Split
  |
Reconciliation

Depois identificaria:

• onde cada conceito nasce;
• quem é seu owner;
• quem o transforma;
• quem depende dele.

2. Definir correlação ponta a ponta

Podem existir identificadores diferentes:

{
  "orderId": "ORD-91827",
  "fiscalDocumentId": "NFE-88271",
  "paymentId": "PAY-71829",
  "txId": "TX-99182",
  "settlementId": "SET-38219"
}

Eles não precisam todos estar em todos os serviços.

Mas o ecossistema precisa conseguir navegar entre eles de forma determinística.

3. Tornar os valores semanticamente explícitos

Eu evitaria um campo:

amount

tentando significar tudo.

Preferiria algo conceitualmente mais próximo de:

type Settlement = {
  grossAmount: Money;
  taxSegregatedAmount: Money;
  netSettlementAmount: Money;
};

Isso é uma recomendação de modelagem, não um contrato imposto pela Plataforma Pública.

Quanto mais financeiro o domínio, mais cara fica a ambiguidade semântica.

4. Modelar estados intermediários

Pagamento confirmado não significa necessariamente:

PROCESS_FINISHED

Uma implementação interna poderia trabalhar com algo como:

PAYMENT_CONFIRMED
SETTLEMENT_PENDING
SPLIT_PENDING
SPLIT_CONFIRMED
RECONCILIATION_PENDING
RECONCILED

Novamente: esses nomes são exemplos de estados internos, não status oficiais do CGIBS/RFB.

O valor da modelagem está em tornar explícitos momentos do processo que, do contrário, poderiam ficar escondidos em flags e tratamentos ad hoc.

5. Tratar idempotência e reprocessamento como requisitos de negócio

Para cada operação deveria estar claro:

• o que acontece se ela chegar duas vezes;
• o que acontece se a resposta se perder;
• o que acontece se precisar ser reenviada;
• como descobrir se já foi processada;
• qual chave de negócio impede efeitos duplicados.

6. Projetar observabilidade de negócio

Não monitoraria apenas:

CPU
memory
HTTP 500
latência

Monitoraria também, conforme o desenho interno da empresa:

pagamentos liquidados sem segregação esperada

segregações pendentes

divergências de conciliação

tempo entre pagamento e segregação

retries

lotes rejeitados

operações presas em estados intermediários

Porque infraestrutura pode estar 100% saudável enquanto dinheiro está no estado errado.

7. Revisar contratos e consumidores antes de mudar schemas

Adicionar um campo é fácil.

Descobrir quem inferia comportamento do schema antigo é difícil.

O blast radius precisa incluir:

Frontend
API
Serviços
Eventos
Banco
ETL
Analytics
Integrações externas

É aí que normalmente moram as premissas invisíveis.

13. O maior risco pode estar onde ninguém está olhando: nos sistemas legados

Os sistemas novos já nascerão sabendo que IBS, CBS e split payment existem.

Os antigos não.

Considere um ETL:

SELECT
    SUM(payment_amount) AS cash_received
FROM payments
WHERE status = 'SETTLED';

A query pode continuar funcionando.

Pode continuar passando nos testes.

Pode continuar alimentando o dashboard.

Mas se SETTLED não significar mais:

todo o valor da venda entrou no caixa da empresa

então cash_received mudou de significado.

Esse tipo de problema é especialmente perigoso porque não produz necessariamente exceção.

Não gera stack trace.

Não derruba pod.

Não dispara health check.

O dado apenas passa a representar outra coisa.

Mudanças de domínio são perigosas porque o software antigo pode continuar funcionando perfeitamente — só que respondendo à pergunta errada.

14. A lição maior: arquitetura também precisa sobreviver ao mundo mudando

Quando falamos em arquitetura, normalmente pensamos em:

• escala;
• performance;
• disponibilidade;
• cloud;
• segurança.

Mas existe outra fonte enorme de mudança.

O próprio domínio.

Governos mudam regras.

Empresas mudam modelos de negócio.

Meios de pagamento surgem.

Parceiros mudam contratos.

Identificadores crescem.

Processos que eram síncronos tornam-se assíncronos.

Aquilo que parecia constante vira variável.

Por isso, uma pergunta particularmente útil em arquitetura é:

“O que este sistema está assumindo que nunca vai mudar?”

No caso do split payment, uma possível resposta é:

“Primeiro recebemos o pagamento. Depois tratamos o imposto.”

Quando essa premissa muda, o blast radius pode atravessar:

Domínio
 |
Checkout
 |
Documento fiscal
 |
Pagamento
 |
PSPs
 |
Liquidação
 |
Conciliação
 |
ERP
 |
Contabilidade
 |
Dados
 |
Analytics

A notícia é tributária.

A consequência é arquitetural.

Conclusão

O split payment não deveria chegar aos times de tecnologia como uma história do tipo:

“Precisamos adicionar os novos campos de IBS e CBS.”

Isso seria enxergar apenas a superfície.

A mudança cria novas relações entre operação comercial, documento fiscal e liquidação financeira.

Essas relações passam a exigir mais atenção a:

• contratos;
• correlação;
• estados intermediários;
• rastreabilidade;
• tratamento de falhas;
• reprocessamento;
• conciliação.

O mais interessante é que a própria documentação oficial já reflete boa parte dessa realidade.

Ela fala de HUB de integração, endpoints HTTP, OpenAPI, identificadores de correlação e controle, observabilidade, retries, backoff exponencial e circuit breakers.

No fim, a Reforma Tributária oferece uma boa lembrança para qualquer sistema, mesmo fora do setor financeiro:

Arquitetura não é apenas preparar software para receber mais tráfego. É preparar software para quando as regras do mundo real mudarem.

Não é apenas o imposto que está mudando. Algumas das premissas sobre as quais nossos sistemas foram construídos também estão.

Fontes oficiais

1. Lei Complementar nº 214/2025 — base legal do IBS, CBS e do mecanismo de split payment.
2. CGIBS — avanços da implementação da Plataforma Pública do Split Payment, 3 ago. 2026.
3. CGIBS/RFB — esclarecimento sobre adiamento das regras de validação dos DF-e, 6 ago. 2026.
4. CGIBS — página oficial de documentação do Split Payment.
5. CGIBS/RFB — Ato Conjunto nº 2/2026 — autorizou a publicação do Manual de Integração e da documentação Swagger/OpenAPI da Plataforma Pública.
6. CGIBS/RFB — Manual de Integração da Plataforma Pública de Split Payment V1.
7. Presidência da República — Decreto nº 12.955/2026 — Regulamento da CBS.
8. CGIBS — Resolução nº 6/2026 — Regulamento do IBS.
9. Receita Federal — Orientações da Reforma Tributária para 2026.
10. CGIBS/RFB — orientações para a transição de 2026.
11. Receita Federal — Entenda a Reforma Tributária do Consumo.