Split payment em teste a partir de 15 de outubro: a conciliação que o contas a receber ainda não desenhou

Em 30 de setembro, a Receita Federal comunicou que, a partir de 15 de outubro, começa a fase de testes de integração entre os Prestadores de Serviços de Pagamento (PSPs) e a Plataforma Pública do Split Payment. O comunicado é explícito: trata-se de etapa técnica, em ambiente controlado, sem processamento definitivo de transações. O teste é dos bancos e das plataformas de pagamento. O desenho que falta, e que ninguém está testando por você, é a conciliação entre documento fiscal, contas a receber e liquidação segregada no seu próprio ERP.

Split payment parece projeto de banco. É projeto de conciliação.

O que o comunicado de 30 de setembro diz, e o que ele não diz

O comunicado da Receita Federal estabelece que, durante os testes, nenhuma transação será processada pelo Split Payment em caráter definitivo, e os PSPs participantes não estarão sujeitos a qualquer tipo de penalidade. O objetivo declarado é validar e aprimorar a integração do sistema antes da entrada em produção real. Os demais PSPs, que não fazem parte do grupo inicial, poderão se inscrever a partir de 16 de novembro.

O que o comunicado não estabelece, pelo menos na fonte consultada, é uma data de início de obrigatoriedade definitiva para o processamento real de transações segregadas. Essa data depende de regulamentação adicional que não foi localizada neste levantamento, o que significa que o calendário de testes não deve ser confundido com o calendário de entrada em vigor plena do mecanismo.

Ausência de data não é ausência de urgência.

O período de teste é exatamente a janela em que desenhar e validar a conciliação interna custa menos do que fazer isso sob pressão, depois que o processamento real já tiver começado e a primeira divergência já tiver aparecido no fechamento. Um Manual de Habilitação de Participantes e um Manual de Redes já orientam, segundo cobertura de imprensa técnica especializada sobre a implementação, os procedimentos de entrada e saída dos PSPs na Plataforma e a configuração técnica de rede, o que indica que a estrutura operacional está sendo desenhada em detalhe, mesmo sem data de obrigatoriedade plena ainda definida.

Essa separação entre calendário de teste e calendário de obrigatoriedade costuma gerar um mal-entendido comum: a notícia de que "o split payment começou" circula no mercado como se o mecanismo já estivesse em produção, quando na realidade o que começou foi apenas a validação técnica entre PSPs e plataforma, sem qualquer efeito sobre o fluxo de caixa de quem vende. Tratar essa confusão de forma esclarecida, internamente, evita que a empresa relaxe o planejamento achando que ainda há tempo de sobra, ou se precipite achando que o impacto já está em vigor.

Vale comunicar essa distinção também para fora do time fiscal. Diretoria comercial, tesouraria e atendimento ao cliente costumam ouvir a mesma notícia de mercado e podem reagir de formas diferentes e contraditórias se não houver uma mensagem única, baseada na fonte oficial, sobre o que de fato começou em 15 de outubro e o que ainda depende de regulamentação futura.

O que a lei manda segregar, e quando isso acontece

O artigo 31 da Lei Complementar 214/2025 trata das transações de pagamento relativas a operações com bens ou com serviços, estabelecendo que os prestadores de serviços de pagamento eletrônico e as instituições operadoras de sistemas de pagamentos têm o dever de segregar e recolher ao Comitê Gestor do IBS e à Receita Federal os valores correspondentes a IBS e CBS.

O ponto central desse artigo é o momento da segregação: não é na emissão da nota fiscal, é na liquidação financeira da transação. Isso significa que dois eventos que hoje, para a maioria das empresas, são tratados como praticamente simultâneos (emitir o documento e receber o dinheiro) passam a ser, no mecanismo do split payment, dois momentos distintos, com um terceiro ator no meio: o prestador de serviço de pagamento, que intercepta parte do valor antes de repassar o restante ao fornecedor.

O fornecedor deixa de receber o valor cheio da venda.

Recebe o valor líquido do imposto segregado, e precisa provar, depois, que o valor retido pelo PSP corresponde exatamente ao imposto devido naquela operação específica. Essa prova é o elo que falta na maioria dos desenhos de contas a receber hoje.

O efeito no caixa e no contas a receber

Para operações de venda a consumidor final, caso típico de varejo, o efeito prático é que o valor líquido que chega à conta do fornecedor passa a ser menor que o valor bruto do documento fiscal emitido. Hoje, o contas a receber de muitas empresas espera receber o valor cheio da nota e concilia contra isso. Com a segregação na liquidação, essa expectativa deixa de bater automaticamente, e alguém precisa decidir, caso a caso, se a diferença é imposto segregado corretamente ou divergência real a investigar.

Sem chave de conciliação, a diferença vira saldo pendente.

Um saldo pendente recorrente, mês após mês, tende a ser tratado como provisão genérica ou ajuste manual de fechamento, o que mascara o problema real: a ausência de um vínculo direto, no sistema, entre o documento fiscal específico, a liquidação financeira específica que o pagou, e o valor de IBS e CBS que o PSP reteve naquela liquidação. Sem esse vínculo, nenhuma reconciliação automática é possível, e o time financeiro passa a investigar manualmente cada diferença, operação por operação.

Isso tem efeito direto na previsibilidade de caixa. Uma empresa que projeta entrada de caixa com base no valor bruto das vendas, sem descontar a parcela que o split payment vai reter na liquidação, vai sistematicamente superestimar o caixa disponível, o que é especialmente relevante para quem depende de capital de giro apertado entre a venda e o recebimento.

O efeito tende a ser mais visível em períodos de pico de venda, quando o volume de transações sujeitas à segregação cresce proporcionalmente mais rápido do que a capacidade do time financeiro de investigar cada diferença manualmente. Um processo que funciona de forma apertada em volume normal pode simplesmente não escalar quando o volume dobra ou triplica numa data comercial relevante. Nesses picos, o número absoluto de diferenças a investigar pode crescer mais do que proporcionalmente ao volume de vendas, porque cada canal de pagamento novo adicionado para dar conta da demanda extra traz sua própria combinação de taxas e prazos de liquidação, aumentando a variedade de padrões que a conciliação precisa reconhecer.

Art. 31. Nas transações de pagamento relativas a operações com bens ou com serviços, os prestadores de serviços de pagamento eletrônico e as instituições operadoras de sistemas de pagamentos deverão segregar e recolher ao Comitê Gestor do IBS e à RFB, no momento da liquidação financeira da transação.

Onde o ERP precisa do dado de liquidação, e o que falta hoje

O SAP, na maioria dos ambientes que ainda não se prepararam para o split payment, trata a liquidação financeira como um evento de tesouraria, registrado por extrato bancário ou por integração com o adquirente de cartões, sem nenhum vínculo estruturado com o imposto segregado naquela transação específica. Essa é exatamente a lacuna que o mecanismo novo expõe.

Para que a conciliação funcione, o ERP precisa de uma chave comum entre três registros: o documento fiscal emitido, a liquidação financeira recebida, e o valor de IBS e CBS retido pelo PSP naquela liquidação. Hoje, na maioria dos ambientes, essa chave não existe de forma estruturada, porque o processo de contas a receber e o processo de recebimento de cartão ou meio de pagamento eletrônico correm em trilhas separadas, que só se encontram no extrato bancário consolidado, sem granularidade por documento.

Essa separação de trilhas costuma ter origem histórica: o módulo de contas a receber foi desenhado para reconciliar documento contra recebimento em bloco, não transação a transação, porque antes do split payment não havia motivo para granularidade tão fina. O split payment muda essa necessidade sem que o desenho legado do sistema tenha acompanhado a mudança.

A janela de testes, embora não processe transações definitivas, é o momento certo para desenhar essa chave e simular o fluxo, sem o risco de uma divergência real afetar o caixa. Esperar o processamento real começar para só então desenhar a conciliação é desperdiçar justamente o período criado para evitar esse tipo de improviso.

Vale também mapear, desde já, quantos PSPs ou adquirentes diferentes a empresa utiliza para receber pagamentos de consumidor final, porque cada integração adicional multiplica o número de formatos de retorno que o SAP precisa reconhecer. Uma conciliação desenhada para um único PSP não necessariamente funciona quando a empresa opera com três ou quatro simultaneamente, cada um com seu próprio formato de arquivo de liquidação e sua própria granularidade de informação disponível.

Esse mapeamento inicial custa pouco e revela, antes de qualquer desenvolvimento técnico, se o desafio de conciliação será simples (um ou dois canais, formatos parecidos) ou significativamente mais complexo (múltiplos canais, com retornos heterogêneos que exigem camada de normalização antes mesmo de chegar à lógica de conciliação propriamente dita).

O desenho mínimo de conciliação, e o checklist prático

Um desenho mínimo de conciliação cobre cinco pontos: identificar quais fluxos de venda da empresa passam por PSP sujeito à segregação (tipicamente venda direta ao consumidor final, por cartão ou meio eletrônico); definir a chave comum entre documento fiscal e liquidação (número do documento, referência de transação, ou ambos); parametrizar o SAP para registrar o valor segregado como lançamento identificável, não como diferença genérica de caixa; definir o processo de investigação para quando o valor retido não bater com o esperado; e nomear quem, no time de contas a receber, é responsável por essa conciliação específica.

O quinto ponto costuma ser o mais negligenciado. Conciliação sem responsável nomeado tende a ficar em segundo plano até que o volume de diferenças acumuladas force alguém a tratar o assunto, geralmente várias semanas depois do primeiro sinal de divergência.

Um critério de verificação direto: pergunte ao time de contas a receber como, hoje, uma diferença entre o valor esperado de uma venda e o valor efetivamente recebido na conta é tratada. Se a resposta envolve abrir o extrato bancário e cruzar manualmente com a lista de vendas do dia, o processo não está preparado para o volume de diferenças que o split payment vai gerar quando sair da fase de testes. Um segundo critério: peça para alguém simular, hoje, usando os dados de um dia qualquer, como ficaria a conciliação se um valor qualquer de cada venda ao consumidor final fosse retido na liquidação (a alíquota efetiva de IBS e CBS que será retida não foi conferida em fonte oficial; o exercício serve para testar a mecânica da conciliação, não para prever o valor real retido). Se essa simulação não pode ser feita porque o sistema não separa os dois valores, o desenho ainda não existe.

Onde isso converge para uma decisão concreta

Contas a receber, documentos fiscais e liquidação financeira precisam falar a mesma chave no SAP para que a apuração assistida de IBS e CBS funcione de ponta a ponta. Esse desenho de conciliação, documento contra liquidação, é o trabalho de Apoio à Reforma Tributária: mapear os fluxos de venda que passam por PSP sujeito à segregação, desenhar a chave estrutural no sistema, e provar que o valor retido bate com o imposto devido, operação por operação.

O Diagnóstico Fiscal SAP prioriza, especificamente, os fluxos de venda a não contribuintes, onde a segregação do split payment tende a aparecer primeiro e com maior volume, e verifica se o desenho de conciliação já existe ou ainda depende de reconciliação manual a cada fechamento.