Split payment do IBS/CBS: como preparar ERP e pagamentos

Resposta curta

O split payment separa IBS e CBS no momento da liquidação financeira: a parcela tributária segue para Receita Federal e CGIBS, enquanto o valor líquido segue ao fornecedor. Para funcionar sem ruptura, documento fiscal, cobrança e pagamento precisam estar vinculados por identificadores confiáveis.

A empresa deve preparar ERP, checkout, adquirência, contas a receber, tesouraria e conciliação para parcelas, cancelamentos, excessos, reprocessamentos e diferenças. Os manuais oficiais e a OpenAPI já permitem projetar integrações, mas não significam que todo contribuinte deva ativar o mecanismo imediatamente. A implantação será gradual e seguirá os atos aplicáveis.

Split payment não é apenas uma nova baixa bancária. É uma mudança no elo entre venda, documento fiscal, pagamento, débito tributário, crédito do adquirente e caixa do fornecedor.

Por que a preparação ganhou urgência

A Receita Federal e o CGIBS publicaram dois atos técnicos dedicados à Plataforma Pública do Split Payment. O Ato Técnico Conjunto nº 4/2026 aprovou o Manual de Habilitação de Participantes e o Manual de Redes. O Ato Técnico Conjunto nº 5/2026 aprovou versões do Manual de Operações, Manual de Integração, OpenAPI, Manual de Tempos, Manual de Redes e Manual de Segurança.

Na página oficial de documentação do split payment do CGIBS, as versões atuais publicadas em 13 de outubro de 2026 incluem Manual de Integração 1.1.1, Manual de Operações 1.0.1, Manual de Tempos 1.0.1, Manual de Redes 1.0.1, Manual de Segurança 1.0.0, Manual de Habilitação 1.0.0 e OpenAPI 1.1.1.

Esse conjunto muda o estágio do projeto. Já não se trata apenas de interpretar a lei: participantes do ecossistema podem trabalhar sobre contratos técnicos, fluxos, segurança, redes e tempos publicados. Para empresas compradoras e fornecedoras, o sinal é claro: os sistemas internos precisam estar aptos a produzir e conciliar a informação que atravessará esse ecossistema.

O que é o split payment do IBS/CBS

A Lei Complementar nº 214/2025, em texto compilado, estabelece o recolhimento na liquidação financeira como uma das modalidades de extinção dos débitos de IBS e CBS. Nas transações abrangidas, prestadores de serviços de pagamento e instituições operadoras de sistemas de pagamentos segregam e recolhem os valores tributários no fluxo da liquidação.

Na prática, a operação deixa de ser representada apenas por “cliente pagou e fornecedor recebeu”. O sistema precisa provar:

• qual operação de consumo originou a cobrança;
• qual documento fiscal representa essa operação;
• quem é o fornecedor e quem é o adquirente;
• qual transação financeira liquidou o valor;
• quanto de IBS e CBS estava associado ao documento;
• quanto do débito já havia sido extinto por outra modalidade;
• quanto foi segregado, recolhido, transferido ou devolvido por excesso;
• quanto líquido chegou ao fornecedor;
• como o evento repercutiu na apuração e na contabilidade.

O split não substitui o documento fiscal, não corrige uma classificação tributária errada e não elimina eventual saldo a pagar. Ele adiciona um evento financeiro-tributário que deve ser ligado à operação correta.

Procedimento padrão, simplificado e recolhimento pelo adquirente

A legislação distingue mecanismos que não devem ser misturados no ERP.

No procedimento padrão, o originador da transação transmite informações que permitam vincular operação e pagamento e identificar o valor tributário. No simplificado, a segregação usa percentual preestabelecido e segue regras próprias. Ausência de informação não deve ser tratada pelo ERP como licença para criar um percentual local.

O RAD também não é sinônimo de split. A API oficial de recolhimentos da CBS lista ambos na visão do adquirente, mas mantém a natureza de cada evento. Essa distinção precisa sobreviver no razão, na apuração, nos relatórios e na evidência.

A cadeia de dados que precisa fechar

O maior risco não está no cálculo isolado. Está na perda do vínculo entre sistemas. Um pedido pode gerar mais de um documento, uma cobrança pode reunir vários documentos, o cliente pode pagar parcialmente, uma parcela pode ser antecipada e uma devolução pode ocorrer depois da liquidação.

Uma cadeia confiável usa identificadores que não mudam durante o ciclo:

1. operação comercial: pedido, contrato, assinatura ou carrinho;
2. fornecimento: entrega, competência ou evento que caracteriza a operação;
3. documento fiscal: chave, número, série, modelo, item e eventos;
4. instrução de cobrança: título, parcela, fatura, QR Code ou transação iniciada;
5. transação de pagamento: identificador do arranjo e dos participantes;
6. liquidação: data, valor bruto, taxas, split e líquido;
7. apuração: débito, créditos utilizados, extinção, excesso e saldo;
8. contabilidade: contas de tributo, cliente, recebível, caixa e diferenças;
9. evidência: payload, versão, protocolo, retorno e aprovações.

Quando um sistema não aceita o identificador de origem, crie uma tabela de correlação imutável. Não tente reconciliar por valor e data como regra principal: duas vendas iguais no mesmo dia produzem colisões e falsos acertos.

Arquitetura segura para ERP e pagamentos

Uma boa arquitetura isola a regra tributária das particularidades de cada adquirente, banco ou provedor. Isso permite trocar um participante sem reescrever o núcleo fiscal.

1. Catálogo fiscal versionado: mantém CST, classificação, base, alíquota, redução, vigência e fonte.
2. Registro da operação: cria o identificador canônico que une venda, documento, cobrança e pagamento.
3. Adaptador de documentos: lê e publica chaves, itens, totais e eventos dos DF-e aplicáveis.
4. Orquestrador de cobrança: forma parcelas e preserva a composição fiscal de cada uma.
5. Adaptador do PSP: traduz mensagens do provedor para um modelo interno estável.
6. Razão de liquidações: registra bruto, tributos, taxas, líquido, excesso, devolução e status.
7. Conector de apuração: consulta pagamentos e recolhimentos e liga o retorno à operação.
8. Motor de conciliação: compara expectativa, liquidação, apuração, banco e contabilidade.
9. Fila de exceções: bloqueia ou encaminha casos sem vínculo, duplicados ou divergentes.
10. Cofre de evidências: preserva payloads, hashes, versões, protocolos e decisões sem expor segredos.

Fluxo operacional em doze etapas

1. Classificar a operação

O motor fiscal determina o tratamento com base em fornecedor, adquirente, bem ou serviço, local, data e regime. O resultado precisa ser explicável e versionado antes de chegar à cobrança.

2. Emitir ou receber o documento fiscal

Guarde o arquivo autorizado, protocolo e eventos. A chave do documento e os valores de IBS/CBS devem ficar disponíveis ao módulo financeiro sem redigitação.

3. Criar a cobrança vinculada

A cobrança referencia uma ou mais operações por uma composição explícita. Se houver parcelamento, cada parcela conhece sua fração e os documentos relacionados.

4. Enviar a instrução ao provedor

O adaptador monta a mensagem conforme a versão técnica vigente. Antes do envio, valida identificadores, valor bruto, composição fiscal, idempotência e ambiente.

5. Receber aceite ou rejeição

O retorno técnico não encerra a operação. Registre código, horário, versão e identificador externo. Rejeições entram em fila com causa e ação permitida.

6. Acompanhar a autorização do pagamento

Autorização, captura e liquidação são estados diferentes. O ERP não deve contabilizar o líquido definitivo usando apenas o primeiro evento aprovado.

7. Processar a liquidação financeira

Na liquidação, o sistema recebe bruto, tributos segregados, taxas, líquido, participantes e referências. Aplique deduplicação antes de gravar efeitos financeiros.

8. Reconhecer o valor líquido

Contas a receber baixa o cliente pelo valor total pago, enquanto tesouraria e contabilidade representam separadamente tributo segregado, taxas e líquido recebido. Baixar apenas pelo depósito bancário cria diferença artificial no cliente.

9. Consultar apuração

As APIs publicadas para a CBS permitem consultar pagamentos que extinguem débitos do fornecedor e recolhimentos feitos na condição de adquirente. O conector deve trabalhar de modo assíncrono, com controle de tíquete, webhook e recuperação por status.

10. Conciliar por operação

Compare documento, cobrança, transação, liquidação, apuração e banco. O total do dia é uma segunda linha de defesa, não substitui a conciliação unitária.

11. Tratar excessos e devoluções

Valores transferidos por excesso, estornos, cancelamentos e devoluções precisam de evento próprio. Nunca altere retroativamente a liquidação original para “fazer fechar”.

12. Encerrar com evidência

Uma operação só fecha quando todos os eventos obrigatórios têm origem, versão, horário, resultado e destino contábil. Casos pendentes continuam visíveis até resolução ou decisão formal.

Parcelas, antecipação e liquidação parcial

A LC 214 determina que, em pagamento parcelado pelo fornecedor, a segregação e o recolhimento ocorram proporcionalmente na liquidação financeira de cada parcela. Também estabelece que a antecipação de recebíveis não altera a obrigação de split conforme a liquidação das parcelas.

O ERP precisa separar três cronologias:

• fiscal: fato gerador, emissão e eventos do documento;
• comercial: vencimentos, descontos, juros e renegociação;
• financeira: autorização, liquidação, antecipação e repasse.

Se uma parcela de R$ 2.000 é liquidada hoje e outra amanhã, não grave um único evento de R$ 4.000 com data média. Se uma adquirente antecipa o recebível ao fornecedor, preserve a diferença entre adiantamento financeiro e liquidação da compra pelo cliente. Misturar essas linhas do tempo distorce caixa, tributo e conciliação.

Cancelamentos, devoluções e estornos

O ciclo não termina no recebimento. A venda pode ser cancelada, o pagamento estornado ou a mercadoria devolvida. Documento fiscal e transação financeira podem mudar em ordens diferentes.

Modele cada alteração como evento ligado à origem:

A LC 214 compilada prevê tratamento específico para devoluções e cancelamentos de operações cujo débito foi extinto por split, inclusive possibilidade de transferência ao fornecedor conforme regulamentação. O sistema deve consumir o evento oficial aplicável, não produzir uma devolução local com base apenas no extrato bancário.

Crédito do adquirente e extinção do débito

No novo modelo, o direito a crédito está conectado às condições legais e à extinção do débito correspondente nas hipóteses aplicáveis. Isso torna a visibilidade do pagamento mais relevante para compras, fiscal e tesouraria.

O adquirente precisa acompanhar, sem presumir direito automático:

• documento fiscal e classificação corretos;
• IBS e CBS destacados ou tratados conforme a regra;
• vínculo entre operação e pagamento;
• modalidade de extinção do débito do fornecedor;
• parcela efetivamente extinta;
• cancelamentos, devoluções e ajustes posteriores;
• crédito apropriado, pendente, utilizado ou estornado.

Um painel chamado “crédito disponível” não deve somar todo tributo informado nas entradas. Deve explicar a condição de cada parcela e apontar a evidência oficial. O time fiscal define a interpretação; a automação aplica e demonstra a regra aprovada.

Integração com as APIs de apuração da CBS

A documentação oficial da apuração da CBS publica consultas de débitos, créditos, pagamentos, recolhimentos e situação de solicitações. A API de pagamentos retorna atualizações que extinguem débitos do contribuinte, incluindo pagamento próprio, recolhimento do adquirente e split. A API de recolhimentos mostra eventos na condição de adquirente, incluindo RAD e split.

Essas consultas são assíncronas. De acordo com o guia oficial de APIs assíncronas, a aplicação envia um POST com webhook HTTPS, recebe um tíquete, aguarda processamento e obtém uma URL assinada para download. O guia informa OAuth 2.0 no fluxo Client Credentials, disponibilidade temporária do arquivo e limite publicado para a abertura das consultas.

O desenho interno deve contemplar:

• credenciais separadas por ambiente e rotação controlada;
• segredo fora de código, planilha e log;
• webhook dedicado, autenticado na aplicação e protegido contra repetição;
• validação do certificado TLS e do estado da solicitação;
• armazenamento do tíquete, não da URL assinada em logs;
• download dentro da validade e descarte seguro da URL;
• consulta de status como recuperação quando o webhook falhar;
• reprocessamento idempotente do arquivo recebido;
• mascaramento de CNPJ, tokens e dados pessoais na observabilidade.

Não copie exemplos de token da documentação para testes de produção. Use dados sintéticos e credenciais próprias do ambiente autorizado.

Exemplo concreto: venda parcelada com valores fictícios

Considere uma venda B2B de R$ 12.000 em três parcelas iguais. Para testar a integração, a empresa usa em homologação IBS/CBS fictícios de R$ 1.800 no total, ou R$ 600 por parcela. Os números não representam alíquota oficial nem recomendação tributária.

Na primeira parcela, o cliente paga R$ 4.000. A liquidação informa R$ 600 segregados e R$ 3.400 destinados ao fornecedor, antes de eventuais taxas contratuais. O ERP baixa R$ 4.000 do contas a receber, reconhece o evento tributário de R$ 600, registra o líquido e preserva a relação com o documento.

Na segunda parcela, o identificador fiscal não é enviado por falha do checkout. O provedor retorna um evento que não pode ser conciliado ao documento esperado. O sistema não tenta “achar” a venda pelo valor: coloca a transação em exceção, bloqueia o fechamento automático e aciona o responsável.

Na terceira parcela, o pagamento é estornado antes da liquidação. Não há baixa definitiva nem repetição do split. Depois, o cliente paga por outra transação corretamente vinculada. O motor reconhece a nova idempotência, processa a liquidação válida e mantém o estorno anterior na trilha.

O teste só passa se documentos, parcelas, transações, líquido, apuração, banco e contabilidade fecharem individualmente.

Como proteger o fluxo contra duplicidade

Pagamentos e webhooks podem ser reenviados. Timeout não prova falha; resposta 500 não prova que nada foi gravado. Sem idempotência, uma tentativa de recuperação pode criar duas baixas ou dois lançamentos.

Use uma chave idempotente formada por identificador do participante, ambiente, tipo de evento e identificador externo. Grave o payload recebido e seu hash antes de aplicar efeitos. O processador precisa responder de forma consistente a uma repetição legítima e rejeitar colisões com conteúdo diferente.

Estados devem avançar por transições válidas. Por exemplo, iniciado → aceito → liquidado → conciliado. Um evento “liquidado” repetido não cria outra liquidação. Um estorno anterior à autorização deve ir para investigação, não forçar a sequência.

Conciliação contábil e fluxo de caixa

O depósito líquido será menor que o valor pago pelo cliente, mas a diferença não é necessariamente despesa financeira. O plano de contas e o razão auxiliar precisam separar:

• valor bruto da venda;
• IBS e CBS da operação;
• tributo segregado e recolhido;
• taxa do meio de pagamento;
• desconto comercial;
• antecipação e custo financeiro;
• valor líquido repassado;
• excesso devolvido ou transferência posterior;
• estorno, chargeback e devolução;
• diferença ainda sem causa.

Tesouraria deve projetar caixa com base em cenários. A parcela tributária pode deixar de transitar pela conta operacional no fluxo abrangido, e valores por excesso podem retornar em momento posterior. Contratos de recebíveis, covenants e modelos de capital de giro precisam ser revisados com jurídico, fiscal e financeiro.

O cliente pode estar integralmente quitado mesmo quando o extrato mostra apenas o líquido. Baixar a venda pelo depósito bancário reduz artificialmente a receita e deixa o contas a receber aberto.

Painel operacional que realmente ajuda

O painel deve permitir abrir cada operação. Totais agregados são úteis para tendência, mas não explicam por que uma liquidação divergiu.

Defina limites por materialidade e por tempo. Uma divergência pequena repetida milhares de vezes pode ser mais relevante que um evento isolado de valor alto.

Onde a IA ajuda — e onde não deve decidir

IA pode acelerar a investigação ao:

• resumir mudanças entre versões dos manuais e da OpenAPI;
• agrupar exceções por padrão de payload, canal ou provedor;
• sugerir a causa provável citando documento, evento e regra;
• correlacionar chamados, deploys e aumento de divergências;
• gerar casos de teste a partir do contrato técnico;
• explicar a trilha de uma operação em linguagem de negócio;
• identificar dados sensíveis antes que cheguem aos logs;
• priorizar filas por valor, recorrência, idade e risco.

Ela não deve escolher alíquota, criar vínculo sem evidência, promover regra para produção, decidir direito a crédito ou executar estorno financeiro sem autorização. Regras determinísticas e responsáveis nomeados continuam no comando.

Riscos que merecem teste específico

Vínculo incorreto

Uma transação ligada ao documento errado pode extinguir débito indevido, distorcer crédito e produzir reconciliação enganosa. Teste colisões de valor, cliente e data.

Informação tributária desatualizada

O checkout pode usar uma versão diferente do motor fiscal. Exija versão e hash da composição fiscal em cada instrução.

Reenvio e ordem de eventos

Webhooks podem chegar duplicados ou fora de ordem. Teste repetição, atraso, interrupção e recuperação.

Pagamento de vários documentos

Uma cobrança consolidada precisa informar a composição. Sem ela, o valor total não revela qual débito foi afetado.

Parcelamento e renegociação

Alterar vencimento ou quantidade de parcelas não pode perder a proporção fiscal nem apagar eventos anteriores.

Cancelamento parcial

O estorno financeiro e o documento de devolução podem cobrir escopos diferentes. Faça conciliação por item e valor.

Indisponibilidade de participante

Defina fila, repetição com idempotência, fallback autorizado e reconciliação posterior. Nunca “assuma sucesso” para liberar fechamento.

Vazamento de segredo

Tokens, URLs assinadas e dados fiscais não pertencem a logs abertos. Teste mascaramento e acesso mínimo.

Plano de preparação em quatro ondas

Onda 1 — inventário e contrato de dados

Liste documentos, meios de pagamento, PSPs, bancos, ERPs, checkouts, filiais e modelos de cobrança. Desenhe o identificador canônico e a composição entre documento e pagamento.

Onda 2 — razão e conciliação

Antes de integrar produção, construa o razão de liquidações com dados atuais. Prove que bruto, taxas, líquido, estornos e recebíveis fecham sem o novo evento.

Onda 3 — simulador de split

Use massas fictícias para procedimento padrão, simplificado quando aplicável, RAD, parcelas, excessos, devoluções e falhas. Compare resultado esperado e eventos gerados.

Onda 4 — homologação e ativação controlada

Conecte ambientes autorizados, execute regressão, obtenha aprovação fiscal, financeira, contábil, jurídica e técnica. Ative por canal ou estabelecimento com observabilidade e rollback operacional.

Não programe uma virada global baseada apenas na existência dos manuais. A LC 214 prevê implementação gradual definida em ato conjunto e admite hipóteses específicas. O calendário interno deve apontar a fonte oficial de cada marco.

Como a Laf Digital estrutura o projeto

A Laf Digital organiza a adequação como um sistema de controle, não como um campo adicional no ERP.

1. Mapa de operação e pagamento

Identificamos onde nasce o fornecimento, quem emite o documento, quem cria a cobrança, quais participantes liquidam e como o dinheiro chega ao caixa.

2. Modelo canônico e integrações

Criamos um contrato interno para documento, cobrança, transação, split, líquido, apuração e eventos. Adaptadores isolam particularidades de ERP, PSP, banco e plataforma.

3. Razão de liquidações e conciliação

Cada evento recebe identidade, estado, valor, origem e efeito contábil. Diferenças entram em fila com evidência e responsável.

4. Segurança e governança

Configuramos credenciais, segregação de ambientes, idempotência, observabilidade sem segredos, aprovações e trilha de auditoria.

5. Homologação por cenários

Testamos parcelas, múltiplos documentos, cancelamentos, estornos, excesso, indisponibilidade e versões. A ativação ocorre somente com critérios objetivos de saída.

Checklist executivo

• [ ] inventariar todos os meios de pagamento e participantes;
• [ ] relacionar documentos fiscais, cobranças e transações;
• [ ] definir identificador canônico e tabela de correlação;
• [ ] versionar regra fiscal e composição enviada ao pagamento;
• [ ] separar procedimento padrão, simplificado, RAD e pagamento próprio;
• [ ] modelar parcela, pagamento parcial e renegociação;
• [ ] diferenciar antecipação de recebível e liquidação do cliente;
• [ ] criar razão com bruto, tributos, taxas, líquido e excessos;
• [ ] implementar idempotência em comandos e webhooks;
• [ ] tratar eventos fora de ordem e recuperação de timeout;
• [ ] proteger credenciais, tokens e URLs assinadas;
• [ ] conciliar documento, PSP, apuração, banco e contabilidade;
• [ ] testar cancelamento, devolução, estorno e chargeback;
• [ ] medir exceções por idade, valor, canal e causa;
• [ ] registrar fonte oficial e vigência de cada marco;
• [ ] aprovar ativação com fiscal, financeiro, contábil, jurídico e tecnologia.

Referências consultadas

• Receita Federal — Atos Técnicos Conjuntos da Reforma Tributária do Consumo
• Receita Federal e CGIBS — Ato Técnico Conjunto nº 4/2026
• Receita Federal e CGIBS — Ato Técnico Conjunto nº 5/2026
• CGIBS — documentação da Plataforma Pública do Split Payment
• Planalto — Lei Complementar nº 214/2025, texto compilado
• Planalto — Lei Complementar nº 227/2026
• Planalto — Decreto nº 12.955/2026, Regulamento da CBS
• CGIBS — Resolução CGIBS nº 6/2026, Regulamento do IBS
• Receita Federal — documentação das APIs de apuração da CBS
• Receita Federal — consultar pagamentos de CBS
• Receita Federal — consultar recolhimentos de CBS como adquirente
• Receita Federal — regras comuns das APIs assíncronas da apuração

Perguntas frequentes

O que é split payment do IBS e da CBS?

É o recolhimento dos tributos na liquidação financeira da operação. O fluxo segrega a parcela tributária e destina o valor líquido ao fornecedor conforme as regras aplicáveis.

O split payment já é obrigatório para todas as empresas?

Não se deve concluir isso apenas porque os manuais foram publicados. A legislação prevê implementação gradual por ato conjunto e pode estabelecer hipóteses e cronogramas específicos.

Publicação da OpenAPI significa que a plataforma está liberada em produção?

Não. A OpenAPI permite preparar contratos e testes. Produção depende de habilitação, ambientes, versões e atos aplicáveis ao participante e ao meio de pagamento.

Toda empresa vai integrar diretamente com a Plataforma Pública?

Não necessariamente. PSPs e instituições operadoras cumprem papéis próprios. Fornecedores e adquirentes podem integrar seus sistemas aos participantes e às consultas oficiais conforme seu papel.

Qual é a diferença entre split padrão e simplificado?

O padrão usa informações que vinculam operação e pagamento e identificam os valores tributários. O simplificado usa percentual preestabelecido conforme norma e possui efeitos próprios.

O percentual simplificado é a alíquota da operação?

Não. A LC 214 afirma que ele não guarda relação necessária com o valor dos débitos efetivamente incidentes na operação. O ERP deve manter os conceitos separados.

O que é recolhimento pelo adquirente?

É a modalidade em que adquirente do regime regular recolhe IBS e CBS da operação nas condições legais, inclusive quando usa instrumento que não permite o split aplicável.

RAD e split payment são a mesma coisa?

Não. Ambos podem aparecer nas consultas de recolhimentos, mas são modalidades distintas e precisam de identificação, contabilização e evidência próprias.

O documento fiscal continua necessário?

Sim. O split depende da operação e de suas informações. O pagamento não substitui classificação, cálculo, emissão, evento ou escrituração do documento fiscal.

O que acontece em vendas parceladas?

A segregação e o recolhimento devem acompanhar proporcionalmente a liquidação de cada parcela, conforme a lei. O sistema precisa preservar a composição de cada pagamento.

Antecipar recebíveis antecipa o split?

A antecipação do recebível não altera, por si, a obrigação de segregação conforme as liquidações das parcelas. Registre o adiantamento financeiro separado do pagamento do cliente.

Como baixar o contas a receber?

Baixe pelo valor total pago pelo cliente e represente separadamente tributo segregado, taxas e líquido recebido. Usar apenas o depósito líquido deixa saldo artificial.

O split elimina eventual saldo devedor?

Não. A lei preserva a responsabilidade do sujeito passivo por eventual saldo a recolher. A conciliação deve mostrar parcela extinta e parcela ainda aberta.

Como tratar um pagamento que reúne várias notas?

Guarde a composição explícita por documento e valor. Não rateie depois apenas por proximidade de data ou valor total.

Como tratar uma nota paga por várias transações?

Modele relação muitos-para-muitos. Cada transação informa a parcela que extingue e o razão consolida o saldo da operação sem apagar os eventos.

O que fazer quando falta o vínculo do documento?

Envie a transação para exceção, preserve o payload e siga o procedimento de correção aplicável. Não invente o vínculo por semelhança.

Como evitar dupla baixa por reenvio de webhook?

Use chave idempotente, hash do payload e máquina de estados. O mesmo evento repetido deve retornar o mesmo resultado sem criar novo efeito.

O ERP deve consultar a apuração por total mensal?

Totais ajudam no fechamento, mas o controle principal deve chegar à operação, documento, modalidade e valor. Compensações entre erros podem esconder divergências.

As APIs de apuração respondem imediatamente?

As consultas publicadas operam de forma assíncrona: retornam tíquete, processam a solicitação e notificam um webhook com link temporário para o arquivo.

A URL assinada pode ser registrada no log?

Não é recomendado. O guia oficial manda tratá-la como segredo temporário. Registre tíquete, horário e resultado; proteja a URL e descarte-a após o uso.

Como tratar cancelamento depois da liquidação?

Relacione evento fiscal e financeiro ao original, acompanhe o efeito oficial na apuração e contabilize transferência, estorno ou ajuste sem reescrever a liquidação histórica.

Transferência por excesso é nova receita?

Não deve ser classificada automaticamente assim. É preciso identificar a origem e o motivo do retorno, conciliando-o à operação e ao débito já tratado.

Split payment muda o fluxo de caixa?

Pode mudar, porque a parcela tributária segregada não compõe o líquido operacional recebido no fluxo abrangido. Simule capital de giro, taxas, prazos e excessos.

Como lidar com chargeback?

Separe contestação, provisão, decisão, estorno financeiro e efeito fiscal. Chargeback não deve disparar ajuste tributário sem a evidência e o evento aplicáveis.

Quais áreas precisam participar?

Fiscal, financeiro, tesouraria, contabilidade, jurídico, vendas, tecnologia, segurança e operações de pagamento. O erro costuma atravessar várias dessas fronteiras.

Onde a IA pode reduzir trabalho?

Na comparação de versões, agrupamento de exceções, explicação de trilhas e geração de testes. Decisão tributária, ativação e movimento financeiro continuam sob controle humano.

Qual é o primeiro teste que a empresa deve fazer?

Escolha uma venda simples, uma parcelada e uma com cancelamento. Prove o vínculo entre documento, cobrança, transação, liquidação, banco, apuração e contabilidade.

Quando procurar uma automação sob medida?

Quando ERP, emissor, checkout, PSP, banco e apuração não compartilham identificadores ou quando a conciliação manual já não fecha no prazo com evidência suficiente.

Próximo passo

Selecione os três meios de pagamento de maior volume e desenhe uma linha completa para cada um: operação, documento fiscal, cobrança, transação, liquidação, tributos, taxas, valor líquido, apuração e lançamento contábil. Marque onde o identificador muda, onde existe redigitação e onde um evento pode ser repetido.

Se sua empresa precisa preparar ERP, checkout, PSPs, tesouraria e apuração para o split payment, a Laf Digital pode construir o modelo canônico, os adaptadores e a conciliação por operação, com homologação controlada e trilha de auditoria.