Split Payment não é um problema de VARCHAR

•Michael•26 min de leitura

Quem retém é o PSP, sobrou pra você a parte difícil.

Todo mundo escreveu o mesmo artigo, troque o CNPJ pra VARCHAR, use DECIMAL(18,2), atualize o schema da NF-e, pronto, só que nada disso é o que vai quebrar em produção.

Desde que a Receita Federal e o CGIBS publicaram o Manual de Integração da Plataforma Pública do Split Payment (Ato Conjunto RFB/CGIBS nº 2/2026, DOU de 03/06/2026), o LinkedIn e outras redes viraram uma esteira de posts e artigos idênticos, alguns corretos, todos rasos, parando exatamente onde o problema começa.

O padrão é sempre o mesmo: explica CBS e IBS, cita o "fim do float fiscal", lembra que o CNPJ virou alfanumérico, recomenda DECIMAL(18,2), avisa que o lote é atômico e fecha com "comece a estudar a documentação", é a versão release notes de uma mudança que é, na prática, uma reescrita do modelo transacional de qualquer sistema que movimenta dinheiro.

Eu trabalho com sistemas bancários - ledger de partidas dobradas, liquidação, conciliação, Elixir/OTP em cima de Postgres, vou escrever o artigo que eu queria ter lido: o que efetivamente quebra, e por quê.

Aviso de escopo: isto é um texto de engenharia, não parecer tributário, onde a norma admite leitura, eu digo, onde o código não admite, eu insisto.

Image description

Fig. 1 - O caminho do dinheiro depois do Split Payment, alinha pontilhada da esquerda é a que quebra na maioria dos sistemas.

Primeiro: você provavelmente não vai fazer split nenhum

O erro conceitual mais comum nos artigos que li é tratar "implementar Split Payment" como uma tarefa do time de backend do ERP, não é.

Quem retém, segrega e recolhe é o PSP - a instituição financeira, o adquirente, o subadquirente, o banco que liquida o boleto, o PSP que liquida o Pix, quem entrega o valor líquido ao vendedor e o valor do tributo ao Fisco é essa camada, não a sua aplicação, a Plataforma Pública é um canal entre PSPs e Fisco.

Então o que sobra pra quem constrói ERP, e-commerce, marketplace, sistema de gestão?

Sobra a parte difícil: fornecer a identidade fiscal da operação de um jeito que o PSP consiga casar o pagamento com o documento.

Isso não é uma coluna nova, é um problema de propagação de chave através de sistemas que nunca foram projetados pra carregar essa chave, e é aí que sangra: em qualquer arquitetura onde o módulo fiscal e o módulo de pagamento não compartilham identificador, a chave morre no meio do caminho - e a maioria das arquiteturas que eu já vi é assim.

O problema real nº 1: o casamento pagamento <--> documento fiscal

O split "inteligente" - o modelo padrão da LC 214/2025 - depende de uma consulta em tempo real que devolve o valor exato a reter naquela liquidação, já líquido dos créditos da cadeia, pra isso funcionar, a plataforma precisa saber qual documento fiscal aquele pagamento está liquidando.

O manual estrutura isso por arranjo de pagamento, e cada arranjo tem um identificador diferente:

ArranjoIdentificadorCiclo
Boletoidentificação do títulociclo completo (cobrança ----> liquidação)
Pix dinâmicotxIdciclo completo
Pix automáticotxIdciclo completo
Pix estáticoE2Eliquidação direta
TEDnumCtrlTEDliquidação direta
TEFnumCtrlTEFliquidação direta

Repare na coluna da direita, ela é a coisa mais importante do manual inteiro e quase ninguém comentou.

Image description

Fig. 2 - A escolha do arranjo de pagamento virou uma decisão fiscal.

Ciclo completo significa que existe um objeto de cobrança criado antes do pagamento, ao qual você pode amarrar a chave de acesso da NF-e, o PSP recebe o pagamento e já sabe o que ele liquida, Split inteligente, valor exato, todo mundo feliz.

Liquidação direta significa que o dinheiro chega sem contexto, um Pix estático é um QR Code colado no balcão, um TED é um TED, não existe cobrança prévia, o PSP tem um crédito na conta do vendedor e nenhuma ideia de qual nota aquilo paga - ou se paga alguma.

E aí a consequência: a escolha do arranjo de pagamento virou uma decisão fiscal.

Quando não dá pra identificar a operação com precisão, o sistema não trava - ele degrada, e é importante saber para onde, não é para o split simplificado: esse é o regime do B2C, escolhido pelo perfil do adquirente (não contribuinte de IBS/CBS), com percentual preestabelecido por ato conjunto da RFB e do CG-IBS, o que te pega quando a consulta é inviável é a contingência - retenção com base no que está disponível, tipicamente o destaque do próprio documento fiscal, sem dedução dos créditos da cadeia, com ajuste depois.

Do ponto de vista de caixa, isso significa reter na cabeça e esperar restituição, e aqui vale ler o prazo com cuidado: os até três dias úteis previstos para devolução do excedente contam da conclusão da apuração, não da retenção, ou seja, o dinheiro fica parado o resto do período de apuração e mais três dias, é um empréstimo compulsório que o seu financeiro não pediu, com prazo bem menos curto do que a expressão "três dias úteis" sugere, causado por uma decisão que hoje é tomada por hábito no checkout.

Se o seu produto oferece Pix estático porque é mais simples de implementar, essa decisão de engenharia agora tem preço em capital de giro, se o seu marketplace deixa o vendedor escolher o meio de recebimento, você acabou de dar a ele um botão que muda o regime de retenção dele.

O trabalho real aqui: rastrear, do checkout até a liquidação, se a chave de acesso do DFe sobrevive ao trajeto, na maioria dos sistemas ela não sobrevive - porque o módulo fiscal e o módulo de pagamento foram escritos por times diferentes, em épocas diferentes, e se comunicam por um pedido_id que só existe no seu banco.

O problema real nº 2: DECIMAL(18,2) é a resposta certa pra pergunta errada

O conselho circulando é: use DECIMAL(18,2), evite FLOAT, certo, óbvio, e insuficiente.

DECIMAL(18,2) te protege de erro de representação binária, ele não te protege de nada do que realmente acontece num split.

Nos ledgers em que trabalhei, dinheiro é integer - centavos, não decimal, não float, integer, o motivo é chato e definitivo: valor monetário não é um número real, é uma quantidade discreta de unidades indivisíveis, e todo bug de conciliação que eu já cacei nasceu de alguém tratando os dois como a mesma coisa, DECIMAL(18,2) no schema é um piso; o tipo dentro da aplicação importa mais.

Mas o ponto central não é o tipo, é a invariante:

valor_bruto = valor_líquido + valor_ibs + valor_cbs

Exatamente, sempre, sem tolerância de arredondamento, se essa igualdade não fechar, você tem um centavo órfão - e centavo órfão em sistema financeiro não some, ele se acumula, aparece na conciliação do mês seguinte e alguém vai passar um domingo procurando.

E é fácil quebrar essa invariante sem perceber, considere o art. 34, II, da LC 214/2025: em venda parcelada, a segregação e o recolhimento são proporcionais à liquidação financeira de cada parcela, não se retém o tributo inteiro na primeira.

Operação de R$ 100,00 de base, alíquota estimada de 26,5%.1 Como IBS e CBS são calculados por fora, o cliente é cobrado em R$ 126,50, dos quais R$ 26,50 são tributo, três parcelas de R$ 42,17, R$ 42,17 e R$ 42,16 - e o tributo dentro delas precisa somar exatamente R$ 26,50.

26,50 / 3 = 8,8333...
arredonda --> 8,83 por parcela
8,83 × 3 = 26,49

Um centavo a menos, onde ele vai?

Essa pergunta não tem resposta técnica - tem resposta arbitrada. E ela precisa ser a mesma no seu sistema, no do PSP e na conferência do Fisco, não pode ser emergente do arredondamento default da linguagem.

A regra determinística que você quer aloca o resíduo de forma estável:

Image description

distribuir(2650, 3) -> [884, 883, 883], soma: 2650, fecha.

por_maior_resto(2650, [50, 30, 20]) -> [1325, 795, 530], soma: 2650, fecha.

Image description

Fig. 3 - O centavo órfão, um por venda parcelada, todo dia, até a conciliação do mês.

E como isso não é opinião, é invariante, ele merece property-based test - não exemplo:

Image description

Isso é o tipo de teste que vale mais que trinta casos escritos à mão, se você só tem asserção sobre R$ 100,00 dividido em 2, você não testou nada - testou o caso que já funcionava.

O problema real nº 3: isso não é uma coluna, é uma perna nova no ledger

Aqui é onde eu acho que a diferença entre "dev que leu a notícia" e "dev que mexe em dinheiro" fica mais visível.

Antes, uma liquidação era um evento de duas pernas:

débito   conta do pagador      100,00
crédito  conta do recebedor    100,00

Com Split Payment, ela tem no mínimo quatro - uma perna de débito e três de crédito:

débito   conta do pagador           126,50
crédito  conta do recebedor         100,00
crédito  tributos a recolher --- CBS     8,80
crédito  tributos a recolher --- IBS    17,70

Image description

Fig. 4 - Liquidação deixou de ser um par, todo código que assume from + to como par único vira dívida.

E existe uma sutileza que quase todo sistema vai errar na primeira tentativa: o valor retido nunca foi receita do vendedor.

A tentação é modelar o tributo como um desconto sobre o crédito - cria um campo valor_desconto_tributo, subtrai, credita o líquido, isso funciona no relatório e mente no extrato, se você lança R$ 126,50 na conta do vendedor e depois debita o tributo, você está afirmando que aquele dinheiro passou pelo patrimônio dele, não passou, ele nunca teve titularidade sobre aquele valor.

Isso importa por três motivos práticos, não filosóficos:

  1. Extrato, o cliente vai abrir o app e ver um crédito que ele nunca pôde usar, seguido de um débito, isso gera chamado, e o chamado tem razão.
  2. Base de cálculo derivada, qualquer coisa que você calcula sobre "volume creditado" - tarifa, comissão, limite, rendimento, score - passa a incidir sobre um valor inflado.
  3. Bloqueio e penhora, um saldo que existiu por 200ms no ledger é um saldo que existiu, pergunte ao jurídico o que ele acha disso.

A modelagem correta é a conta transitória: o valor tributário entra numa conta de terceiros/segregação, nunca na conta de titularidade do vendedor, em partidas dobradas isso é trivial de expressar - o que não é trivial é aceitar que a operação de liquidação deixou de ser binária, todo código seu que assume from_account_id + to_account_id como par único vai precisar virar N lançamentos numa mesma transação, com a invariante soma(débitos) == soma(créditos) validada dentro do commit, não depois.

Em Ecto, isso é uma Ecto.Multi com todas as pernas ou nenhuma, se hoje o seu fluxo faz dois Repo.insert/1 sequenciais e reza, agora ele tem quatro pernas pra rezar.

O problema real nº 4: o Fisco pode mudar o passado

Este ponto aparece nos artigos como uma frase solta - "a Receita poderá fazer correções nos valores depois do pagamento, prepare seus sistemas", só que "preparar seus sistemas" pra isso é uma decisão arquitetural, não um TODO.

Se o valor de IBS/CBS de uma liquidação já ocorrida pode ser corrigido, UPDATE é o seu inimigo, não porque é feio - porque destrói a única coisa que te salva numa fiscalização: a capacidade de responder "qual era o valor que eu conhecia no dia 12 de março?".

Duas propriedades que o seu modelo precisa ter, e que quase nenhum sistema de gestão tem hoje:

1, append-only no ledger, correção não altera lançamento, correção gera lançamento novo, de estorno ou complemento, referenciando o original, o saldo é derivado da soma, não armazenado como verdade primária, isso é caro em leitura - você compensa com snapshot de saldo diário, não abandonando o princípio.

2, bitemporalidade nas alíquotas, existem duas datas em jogo e elas não são a mesma:

  • a data do fato gerador (quando a operação ocorreu);
  • a data em que você soube daquele valor (quando o dado entrou no seu sistema).

Alíquota vigente é função da primeira, se a sua tabela de alíquotas é consultada com WHERE now() BETWEEN vigencia_inicio AND vigencia_fim, você tem um bug que só se manifesta quando alguém reprocessar uma nota de seis meses atrás - e no cronograma de transição da reforma, com alíquotas mudando ano a ano até 2033, "reprocessar coisa antiga" vai deixar de ser exceção.

Image description

O EXCLUDE USING gist ali não é firula: ele impede fisicamente que duas alíquotas conflitantes coexistam pro mesmo tributo, esfera, ente e CST, é a diferença entre uma regra de negócio que o banco garante e uma que depende de todo mundo lembrar.

E repare no que o segundo eixo compra, com $7 = now(), a query responde qual alíquota vale hoje, com $7 = '2027-03-12', ela responde qual alíquota eu achava que valia naquele dia - mesmo que a Receita tenha corrigido o valor depois, é essa segunda resposta que a fiscalização pede, e é ela que some no instante em que alguém dá UPDATE numa linha vigente.

Guardar tudo isso não é opcional, prazo decadencial de tributo no Brasil é de cinco anos, o seu dado de segregação de 2027 precisa estar consultável em 2032, com o valor que valia em 2027 e com todas as correções aplicadas depois, isso é requisito de retenção, e requisito de retenção com volume vira requisito de particionamento.

O problema real nº 5: a atomicidade do lote não se resolve com try/catch

O conselho que circula é: "o lote é atômico, então tenha bom tratamento de exceção e logs detalhados", isso é um pouco como dizer que avião cai, então use cinto.

O fluxo de remessa do manual tem três etapas:

  1. Abertura - o PSP envia os metadados, a plataforma devolve um ResourceId.
  2. Transmissão - lotes de até 1.000 transações, vinculados ao ResourceId.
  3. Encerramento - a plataforma valida a somatória e fecha a remessa.

Todo o desenho é atômico: um item inválido invalida o lote inteiro, e o Informe de Segregação (idInfSegr) é o registro que atesta quanto foi destacado e quanto ficou como crédito líquido do vendedor.

Image description

Fig. 5 - Os três passos da remessa e o perigo não está no erro, está na ausência de resposta.

Os problemas de verdade não são "e se der erro", são estes:

A, timeout no encerramento não é erro, é ambiguidade, você mandou o encerramento e não recebeu resposta, a remessa foi fechada ou não? Se você reenviar, duplica, se não reenviar, fica pendente, a resposta não é retry - é consulta de estado antes de qualquer reenvio, e chave de idempotência estável, gerada na origem e persistida antes da primeira tentativa, chave de idempotência regenerada no retry não é chave de idempotência, é decoração.

B, envenenamento de lote, uma transação ruim derruba 999 boas, retry cego do lote inteiro reproduz a falha indefinidamente, o que funciona é quarentena com bisseção: falhou, parte em dois, reenvia as metades, isola o item problemático em algumas rodadas em vez de uma varredura linear, e o item isolado vai pra uma fila de exceção com intervenção humana, não pro esquecimento.

C, dupla escrita, você tem que gravar no seu banco e transmitir para a plataforma, não existe transação distribuída entre o seu Postgres e a API da Receita, se você faz Repo.transaction e dentro dela chama HTTP, você tem uma conexão de banco aberta pela latência da rede federal - e um rollback que não desfaz o que já foi transmitido.

O padrão é outbox: a transação de negócio grava a intenção de envio na mesma transação do dado, um worker separado lê a outbox e transmite, a transmissão pode falhar, repetir, atrasar - o dado local já está consistente e a entrega é garantida por reprocessamento, não por torcida.

Image description

Note que a chave de idempotência é derivada da liquidação - não é um UUID novo a cada tentativa, essa linha é a diferença entre reprocessar com segurança e recolher imposto em dobro.

O problema real nº 6: o recebível deixou de ser o que era

Este é o ponto que não apareceu em nenhum dos artigos que li, e é o que mais dói pra quem trabalha em banco.

A LC 214/2025 é explícita: antecipação de recebíveis não afasta a obrigação de segregação e recolhimento, o tributo é retido na liquidação, independentemente de o direito creditório ter sido cedido antes.

Traduzindo pra quem faz crédito, e prestando atenção em qual número é qual: um recebível de R$ 100 mil de face - o que o pagador efetivamente vai pagar - carrega o tributo por dentro desse total, com alíquota estimada de 26,5% calculada por fora, a parcela tributária é 100.000 × (26,5 / 126,5) ≈ R$ 20,9 mil, e o que sobra como garantia real gira em torno de R$ 79,1 mil.

Se o seu sistema registra R$ 100 mil como base e não como face, a operação vale R$ 126,5 mil e o tributo é R$ 26,5 mil, os dois cenários são defensáveis; o que não é defensável é o motor de crédito não saber qual dos dois ele guardou, essa ambiguidade sozinha já é uma diferença de 27% na garantia, e ela é invisível até a primeira liquidação bater diferente do esperado.

De um jeito ou de outro, a conclusão não muda: a parcela tributária nunca vai chegar ao cedente, ela é destacada na liquidação e vai pro Fisco.

Image description

Fig. 6 - O recebível não vale o que o sistema diz que vale.

As consequências em cascata:

  • Motor de crédito. Todo cálculo de LTV, haircut e elegibilidade que usa valor bruto de recebível está superestimando garantia, isso não é ajuste de parâmetro, é mudança de base de cálculo.
  • Registradoras e trava de domicílio. O recebível registrado tem valor bruto; o valor que efetivamente liquida é líquido, o descasamento entre o que está registrado e o que liquida precisa ser modelado explicitamente, não descoberto na conciliação.
  • Cessão e identidade fiscal. O crédito cedido carrega consigo a origem tributária da operação, a cessão troca o titular do direito, não apaga o fato gerador, contratos e sistemas que tratam recebível como valor fungível e anônimo têm uma premissa quebrada.
  • FIDC e estruturação. Carteira precificada com fluxo bruto tem sobreavaliação sistemática, não aleatória.

Se você constrói produto de crédito, antecipação, garantia ou factoring, este é o item da lista que muda o seu modelo de risco - não o VARCHAR do CNPJ.

O problema real nº 7: o cancelamento acontece depois do recolhimento

Toda a discussão até aqui assume que a operação seguiu em frente, mas venda cancela, mercadoria volta, serviço não é prestado - e agora o tributo já saiu do sistema, foi pro Fisco, e o vendedor nunca teve titularidade sobre ele.

A LC 227/2026 autorizou o regulamento a prever a transferência ao fornecedor do valor recolhido por split payment em caso de devolução ou cancelamento, do lado da CBS, isso está no art. 57, § 4º, do Decreto nº 12.955/2026; do lado do IBS, no art. 57, § 4º, da Resolução CGIBS nº 6/2026.

O caso simples é trivial: cancelou, o valor volta pro fornecedor que praticou a operação, o caso que quebra sistema é o cruzamento com a seção anterior - e se o recebível já foi cedido? O fornecedor indicado no Informe de Segregação pode já ter alienado o crédito e recebido o preço da cessão, para fins fiscais ele continua sendo o sujeito da operação original, e é pra ele que o valor retorna, só que o dinheiro do recebível está com outra pessoa.

O que isso significa em código:

  • Estorno não é DELETE nem UPDATE. É lançamento novo, com sinal contrário, referenciando o original - exatamente o append-only da seção 4, se você "cancelou" apagando linha, perdeu a capacidade de provar que o recolhimento existiu, e ele existiu.
  • A contraparte do estorno pode não ser a contraparte da operação. Devolução de tributo vai pro fornecedor; o crédito comercial foi pro cessionário, seu modelo precisa de duas contrapartes distintas no mesmo evento, e a maioria dos ledgers de marketplace tem só uma.
  • O estorno tem latência própria. Não é síncrono ao cancelamento, entre o cancelamento e o retorno do valor existe um período em que o seu balanço tem um ativo a receber do Fisco que nenhum relatório atual sabe representar.
  • Cancelamento parcial em venda parcelada combina esta seção com o rateio da seção 2, devolver metade de uma operação de três parcelas com resíduo de centavo já distribuído é o teste que ninguém escreveu.

Se você só for modelar um fluxo de exceção antes de 2027, modele este.

O problema real nº 8: e quando a plataforma cair?

Dario Durigan, ministro da Fazenda, afirmou em julho de 2026 que o sistema terá volume cerca de 170 vezes o do Pix, com projeção de aproximadamente 70 bilhões de documentos fiscais por ano e R$ 2 bilhões investidos só em 2026, vale reparar no detalhe: a estimativa do próprio Fisco era de 150 vezes e foi revista para cima durante o desenvolvimento.

Duas leituras possíveis, a otimista: é um investimento de infraestrutura de escala nacional, a de quem já operou integração com sistema público em dia de pico: é um ponto de dependência externa no caminho crítico da sua liquidação.

A pergunta que todo artigo evitou: o que o seu sistema faz quando a Plataforma Pública não responde?

Isso não é pergunta de infraestrutura, é pergunta de produto, e a resposta precisa estar decidida antes do incidente, porque no meio do incidente você vai ter que escolher entre três coisas ruins:

  1. Segurar a liquidação até a plataforma voltar, cliente não recebe, suporte pega fogo.
  2. Liquidar o valor cheio e resolver o tributo depois, você acabou de assumir risco fiscal e de crédito contra um vendedor que talvez já tenha sacado o dinheiro.
  3. Reter por estimativa (contingência) e acertar depois, cliente recebe menos, você gera um passivo de restituição e um processo de conciliação.

Não existe opção boa, existe a opção que você escolheu conscientemente e documentou, do lado de engenharia, o mínimo é: timeout agressivo, circuit breaker com estado observável, modo degradado explícito e alarmável, e - crítico - um caminho de reconciliação que assume que o estado remoto é desconhecido, não falho, timeout não significa "não aconteceu", significa "não sei", sistema financeiro que trata timeout como falha duplica operação.

O problema real nº 9: volume, particionamento e a tabela que vai te engolir

70 bilhões de documentos por ano no agregado nacional, a sua fatia é menor, obviamente - mas os seus registros de segregação, informes, retentativas e correções crescem em múltiplos do seu volume de transações, não em paridade, cada liquidação vira: lançamento(s) de ledger + registro de segregação + informe + eventuais correções posteriores.

Um par de coisas que valem mais que qualquer otimização de query depois:

Image description

Quatro coisas nesse DDL que não são estilo:

  • bigint em centavos. Sem ponto flutuante em lugar nenhum do caminho, e sem numeric onde o valor é intrinsecamente inteiro.
  • A CHECK de igualdade. É a mesma invariante da seção 2, agora garantida pelo banco, desigualdade (>=) deixaria passar exatamente o centavo órfão que o artigo inteiro persegue, regra de negócio que o banco garante não depende de code review.
  • chave_dfe nullable. Porque liquidação direta sem casamento existe e é legítima - modelar como obrigatória força alguém a inventar um valor, e valor inventado em campo fiscal é dívida técnica com juros.
  • PRIMARY KEY (id, data_fato_gerador). Não é preferência: partição declarativa exige que a chave da partição faça parte de toda constraint de unicidade, consequência que morde depois - id sozinho não é único garantido pelo banco.

E o id_transacao como text genérico com o arranjo ao lado, em vez de quatro colunas específicas: os identificadores têm formatos e regras diferentes por arranjo, e você vai consultar sempre pelo par (arranjo, identificador).

E aqui o artigo precisa fazer justiça ao próprio título, existe um lugar onde tipagem morde de verdade, e não é o CNPJ solto numa coluna: é a chave de acesso.

Até hoje, a regra de validação em qualquer sistema brasileiro é a mesma: 44 posições, todas numéricas, isso acabou, pela NT Conjunta DF-e 2025.001, a chave mantém as 44 posições, mas passa a aceitar letras maiúsculas nas 12 posições centrais - exatamente as 12 primeiras do CNPJ do emitente, que é a parte que pode ter letra, o layout vira [0-9]{6}[A-Z0-9]{12}[0-9]{26}, e os primeiros CNPJ alfanuméricos estão previstos para julho de 2026.

Então sim: todo bigint, todo char(44) assumindo dígito, todo parser que faz to_number no caminho da chave vira migração, era um problema de VARCHAR - só que não o que os artigos disseram, e não pelo motivo que eles deram.

Mas o que realmente separa quem leu a nota técnica de quem leu o resumo dela é o parágrafo seguinte: o cálculo do dígito verificador também muda, cada caractere da chave passa a ser convertido pelo valor decimal da tabela ASCII, subtraindo 48, antes de aplicar o módulo 11, ou seja, quem trocou o tipo da coluna para text, respirou aliviado e não tocou no validador está com um algoritmo de DV silenciosamente errado - que continua aceitando as chaves numéricas antigas e vai rejeitar, ou pior, aceitar indevidamente, as novas.

Trocar o tipo é a parte que dá pra fazer com sed, o DV é a parte que exige entender o que se está validando.

Bônus: você já tem um split no seu código

Detalhe pequeno com potencial de estrago desproporcional.

Se o seu sistema é marketplace, gateway ou plataforma multi-seller, você já tem "split de pagamento" no domínio há anos: dividir o valor entre vendedor, plataforma e afiliados, provavelmente existe uma tabela splits, um SplitService, um campo split_rules.

Não é a mesma coisa, o split de marketplace é uma divisão comercial entre partes privadas, o Split Payment fiscal é uma retenção compulsória em favor do Fisco, com regime jurídico próprio, ordem de precedência e efeitos que a divisão comercial não tem.

Colocar os dois no mesmo namespace vai gerar, com certeza estatística, um bug em que a regra de rateio comercial incide sobre a base errada - ou pior, em que o tributo é rateado entre os participantes do marketplace como se fosse receita, separe o vocabulário agora, enquanto custa um rename, e não depois de o primeiro cliente reclamar do valor recebido.

O que fazer na segunda-feira

Sem checklist genérico, seis perguntas que, respondidas honestamente, dizem o tamanho do seu problema:

  1. A chave de acesso do DFe sobrevive do checkout até a liquidação? Se ela morre em algum hop, esse hop é o seu primeiro trabalho.
  2. Quais dos seus meios de recebimento são "liquidação direta"? Esses são os que vão cair em split simplificado ou contingência, quantifique o volume - é o seu custo de caixa estimado.
  3. O seu ledger aceita mais de duas pernas na mesma transação, com invariante validada no commit? Se não, esse é um refactor estrutural, não uma feature.
  4. Você consegue responder qual valor de tributo você conhecia numa data passada? Se a resposta envolve UPDATE, você não consegue.
  5. O que o seu sistema faz quando a venda é cancelada depois do recolhimento? Se a resposta é "a gente estorna o lançamento", releia a pergunta 4.
  6. Existe decisão escrita sobre o que acontece quando a plataforma não responde? Se não existe, ela vai ser tomada às 3h da manhã por quem estiver de plantão.

E duas datas que não são de 2027: 1º de agosto de 2026 encerra a dispensa de multa pelas informações de IBS e CBS nos documentos fiscais, e 3 de agosto de 2026 começa a rejeição em produção, a primeira pune o erro; a segunda impede a venda de faturar, se você está lendo isto em julho, esse é o prazo que importa antes de qualquer coisa que eu escrevi acima.

O ambiente de homologação está aberto e 2026 é o ano de teste operacional, com alíquota simbólica de 1% (0,9% CBS + 0,1% IBS), isso é uma janela generosa e ela não vai se repetir, só não confunda a janela com um prazo confortável: o split payment começa em 2027 de forma facultativa no B2B, com obrigatoriedade progressiva definida por atos conjuntos da RFB e do CG-IBS - ou seja, a data em que ele passa a ser obrigatório pra você ainda não existe, e vai sair por ato administrativo com antecedência que ninguém te garantiu, em 2033 os tributos antigos morrem de vez.

Use a janela pra descobrir que o seu ledger tem duas pernas, não pra descobrir que o CNPJ é VARCHAR.

Fontes

Footnotes

  1. A alíquota de referência ainda não foi fixada por resolução do Senado, uso 26,5% porque é a trava da nota técnica de 2024; as estimativas oficiais chegam perto de 28%, onde eu escrevo um número, leia "ordem de grandeza". ↩

#elixir#ledger#money#postgres#split payment#varchar
Loading comments...