O split payment vai mudar radicalmente a forma como o dinheiro das vendas entra no caixa das empresas. A partir de 2027, quando o pagamento do cliente for processado, o sistema financeiro reterá automaticamente o IBS e a CBS na fonte — antes mesmo de o valor chegar à conta da empresa. Se o seu ERP não estiver preparado para registrar, conciliar e reportar esse fluxo em tempo real, sua operação pode travar. Este checklist técnico foi feito para gestores de PME que precisam saber, agora, se o sistema de gestão atual aguenta a reforma tributária.
O Que é o Split Payment e Por Que Ele Mexe no Coração do ERP
No modelo atual, a empresa recebe o valor bruto da venda e depois recolhe os tributos. Com o split payment previsto na Reforma Tributária, o fluxo se inverte: no momento do pagamento, o PSP (provedor de serviços de pagamento) ou a instituição financeira retém automaticamente o IBS (Imposto sobre Bens e Serviços) e a CBS (Contribuição sobre Bens e Serviços) e os repassa diretamente ao Fisco. A empresa recebe apenas o valor líquido — já descontados os tributos.
Isso significa que o ERP precisa processar, em nível de transação, informações que antes eram consolidadas mensalmente. Cada Documento Fiscal Eletrônico (DF-e) passará a ter IBS e CBS vinculados em valor absoluto, e esses valores precisarão ser reconciliados com o extrato bancário que chegará segregado: de um lado o líquido recebido, de outro o tributo retido. Sistemas construídos para o mundo anterior não conseguem fazer essa amarração sem customizações profundas ou, na prática, sem quebrar.
Os 5 Requisitos Técnicos Que um ERP Precisa Cumprir
Para avaliar se o seu sistema de gestão está pronto para o split payment, verifique se ele atende a cada um dos requisitos abaixo:
1. Captura de IBS e CBS em Valor Absoluto por Transação
O ERP deve ser capaz de calcular e armazenar o IBS e a CBS como campos individuais por linha de item e por documento fiscal — não apenas como alíquotas configuradas, mas como valores absolutos gerados no momento da emissão do DF-e. Esses valores precisam estar disponíveis para integração com os PSPs antes do processamento do pagamento.
2. Vínculo Direto entre DF-e e Meio de Pagamento
Cada Nota Fiscal, NFS-e ou CT-e deve estar formalmente vinculado ao método de pagamento usado na transação (cartão, Pix, boleto). O sistema financeiro do ERP precisa rastrear esse vínculo para saber exatamente qual tributo foi retido em qual liquidação, viabilizando a conciliação posterior sem intervenção manual.
3. Integração Nativa com PSPs e Meios de Pagamento
A comunicação entre o ERP e os provedores de pagamento precisará ser bidirecional e em tempo quase real. O sistema deve enviar ao PSP os dados tributários do DF-e e receber de volta a confirmação de retenção. ERPs que tratam o financeiro e o fiscal como módulos separados — ou que dependem de exportações de planilha para conciliar — não conseguem sustentar essa integração.
4. Conciliação de Extrato Bancário com Partição Líquido/Tributo
Com o split payment, o extrato bancário da empresa virá com lançamentos segregados: valor líquido recebido e valor de tributo retido. O ERP precisa reconhecer e processar esses dois tipos de lançamento automaticamente, classificando-os de forma correta no fluxo de caixa e na apuração fiscal sem exigir reclassificação manual do time financeiro.
5. Reconciliação Tributária Automática
O sistema deve cruzar, automaticamente, os tributos retidos pelo PSP com os valores de IBS e CBS registrados nos DF-es emitidos. Qualquer divergência precisa ser sinalizada em tempo real. Essa reconciliação é o que garante que a empresa não pague tributo em duplicidade nem fique exposta a autuações por inconsistência entre o que foi retido e o que foi declarado.
Sinais de Alerta: Seu ERP Atual Não Está Pronto
Muitos gestores só vão descobrir que o sistema não dá conta quando já for tarde. Estes são os sinais de que o seu ERP não está preparado para o split payment:
- Planilhas no meio do processo fiscal: se o time de fiscal ou financeiro usa Excel para consolidar dados entre emissão de nota e conciliação bancária, esse gap vai explodir com o split payment.
- Módulos fiscal e financeiro desconectados: quando o fiscal emite a NF-e em um sistema e o financeiro lança o recebimento em outro, sem integração automática, a rastreabilidade por transação é impossível.
- Conciliação bancária mensal ou semanal: o split payment exige conciliação diária ou por liquidação. Processos manuais periódicos criam gaps de reconciliação que geram passivo tributário.
- Ausência de campos nativos para IBS e CBS: ERPs que não foram atualizados para a Reforma Tributária ainda trabalham com PIS, COFINS, ISS e ICMS como campos fixos. Adicionar IBS e CBS como campos paralelos sem reestruturar o modelo de dados é um remendo que não sustenta.
- Integração com PSP via exportação de arquivo: se a comunicação com o gateway de pagamento ou banco é feita por upload de CNAB ou arquivo texto, a latência inviabiliza o modelo de retenção em tempo real exigido pelo split payment.
- Nenhuma visibilidade do fluxo de caixa líquido futuro: sem saber com antecedência quanto do recebível será retido como tributo, o gestor perde o controle do capital de giro — um dos maiores impactos práticos do novo modelo.
O Impacto no Capital de Giro das PMEs
Além do desafio técnico, o split payment tem um impacto financeiro direto que os gestores precisam dimensionar. Hoje, muitas PMEs usam o intervalo entre o recebimento bruto e o recolhimento do tributo como capital de giro informal. Com a retenção automática na fonte, esse intervalo deixa de existir.
Isso significa que o ERP precisa oferecer não apenas conciliação retroativa, mas também projeção de fluxo de caixa já considerando o tributo retido. O gestor precisa enxergar, no painel financeiro, qual será o valor líquido a receber de cada lote de vendas — e planejar capital de giro com base nessa realidade, não no valor bruto.
Um ERP preparado para o split payment não é apenas um sistema fiscal atualizado. É uma plataforma financeira que enxerga tributo e caixa como uma coisa só, em tempo real, por transação.
Checklist Rápido: Faça Agora a Avaliação do Seu ERP
Responda sim ou não para cada item. Se houver mais de dois "não", o sistema atual exigirá substituição ou customizações de alto custo antes de 2027:
- O ERP calcula e armazena IBS e CBS em valor absoluto por item de DF-e?
- Existe rastreabilidade automática entre cada DF-e emitido e o pagamento correspondente?
- O sistema se integra via API em tempo real com os PSPs utilizados pela empresa?
- O módulo de conciliação bancária reconhece lançamentos particionados (líquido + tributo retido)?
- Há reconciliação automática entre tributos retidos pelo PSP e tributos registrados nos DF-es?
- O fluxo de caixa projetado já desconta o tributo que será retido na fonte?
- O módulo fiscal e o módulo financeiro compartilham a mesma base de dados, sem exportações intermediárias?
Se a maioria das respostas for "não" ou "não sei", você não está sozinho — a maior parte dos ERPs legados foi construída para um modelo tributário que está sendo aposentado.
Por Que ERPs Legados Têm Dificuldade de se Adaptar
A raiz do problema é arquitetural. ERPs desenvolvidos há mais de dez anos foram projetados com módulos separados para fiscal, financeiro e bancário, conectados por processos batch (em lote) que rodam periodicamente. Esse modelo funciona quando o tributo é apurado mensalmente e recolhido em data futura.
O split payment exige o oposto: processamento por evento, em tempo real, com os três módulos operando como um único fluxo. Adaptar uma arquitetura batch para um modelo orientado a eventos não é uma atualização de software — é uma reescrita. E reescritas em sistemas legados em produção têm custo, prazo e risco elevados, especialmente para PMEs sem equipe de TI dedicada.
ERPs nativos para a Reforma Tributária, construídos ou refatorados com essa arquitetura em mente, partem de uma posição radicalmente diferente: o split payment não é um módulo adicional, é o modelo de operação padrão.
xsoftware: ERP Construído para o Cenário Pós-Reforma
O xsoftware foi desenvolvido com a arquitetura orientada a eventos que o split payment exige. O módulo fiscal e o financeiro compartilham a mesma base transacional — não há exportação de dados entre eles. Cada DF-e emitido gera automaticamente os valores de IBS e CBS vinculados ao documento, disponíveis via API para os PSPs integrados.
A conciliação bancária do xsoftware já reconhece lançamentos particionados, classificando automaticamente o líquido recebido e o tributo retido em campos distintos, sem intervenção manual. A projeção de fluxo de caixa já considera os valores que serão retidos na fonte, dando ao gestor visibilidade real do caixa disponível.
Para PMEs que precisam estar prontas antes de 2027 sem passar por uma migração traumática de último minuto, o xsoftware oferece o caminho mais direto: uma plataforma que já opera no modelo que a Reforma Tributária vai impor.
Conclusão: 2027 Chega Mais Rápido do Que Parece
A implementação do split payment está prevista para 2027, mas o processo de avaliação, decisão e migração de ERP para uma PME leva, em média, de 6 a 18 meses. Quem começar a avaliação em 2026 estará correndo contra o tempo. Quem começar agora tem margem para fazer a transição com segurança, treinar o time e ajustar processos sem pressão de prazo regulatório.
O checklist acima é o primeiro passo. O segundo é fazer um diagnóstico real do seu sistema atual com quem entende de ERP e split payment.
Faça agora o diagnóstico gratuito do seu ERP e descubra se ele está pronto para o split payment — ou o que será necessário para chegar lá. Conheça o xsoftware e veja como PMEs estão se preparando para a Reforma Tributária com um sistema construído para esse novo cenário.
