A reforma tributária do consumo aproxima o direito ao crédito do efetivo tratamento do débito na operação. Isso muda uma premissa importante para quem desenvolve sistemas empresariais: emitir e escriturar corretamente o documento fiscal continuará sendo essencial, mas nem sempre bastará para concluir o ciclo do crédito. O ERP precisará acompanhar também como o débito de IBS e CBS foi extinto e relacionar esse evento à compra que deu origem ao crédito. É nesse contexto que aparece o recolhimento pelo adquirente, conhecido pela sigla RAD.

O mecanismo ganhou atenção porque permite que o comprador, em uma situação delimitada pela lei, recolha o IBS e a CBS incidentes na própria operação. A ideia parece simples, mas pode gerar interpretações perigosas. O RAD não é uma autorização genérica para pagar o tributo de qualquer fornecedor, não substitui o split payment quando este puder ser utilizado e tampouco deve ser tratado no sistema como uma retenção tradicional. A seguir, vamos examinar o artigo 36 da Lei Complementar nº 214/2025, os efeitos para fornecedor e adquirente e os controles técnicos necessários antes de colocar a funcionalidade em produção.

O que é o recolhimento pelo adquirente

O artigo 36 da Lei Complementar nº 214/2025 permite que o adquirente de bens ou serviços, desde que seja contribuinte de IBS e CBS no regime regular, recolha os tributos relativos à operação. A possibilidade existe quando o pagamento ao fornecedor for realizado por instrumento que não permita a segregação e o recolhimento dos valores na forma dos artigos 32 e 33, que disciplinam o split payment. A opção é exercida pelo próprio recolhimento dos valores correspondentes à operação.

Essa redação contém três filtros que merecem virar regras explícitas no software. Primeiro, o comprador precisa estar no regime regular; não basta existir uma conta a pagar. Segundo, o recolhimento deve se referir ao tributo daquela operação, o que exige vínculo com o documento fiscal e os respectivos débitos. Terceiro, o meio usado no pagamento comercial não pode permitir a segregação prevista para o split payment. Portanto, o RAD é uma alternativa para uma condição operacional específica, e não uma preferência aplicável indistintamente a todas as compras.

A Cartilha Orientativa da Apuração do IBS, volume 2, publicada pelo Comitê Gestor do IBS, inclui o RAD entre as formas de recolhimento que aparecem na apuração. O material mostra tanto o efeito para quem compra quanto a extinção do débito na apuração de quem vende. Essa visão em duas pontas é útil para o desenho do ERP: o mesmo evento precisa ser conciliado de maneiras diferentes conforme a empresa seja adquirente ou fornecedora.

RAD, split payment e retenção não são a mesma coisa

No split payment, a segregação do tributo ocorre vinculada à liquidação financeira: uma parcela segue o tratamento fiscal previsto e o restante compõe o pagamento ao fornecedor. No RAD, a hipótese legal surge justamente quando o instrumento usado para pagar o fornecedor não permite essa segregação. O adquirente então realiza um recolhimento específico da operação. A diferença muda a origem do evento, a forma de conciliação, as evidências necessárias e o tratamento de eventual valor excedente.

Também convém evitar a palavra “retenção” como modelo de dados. Em tributos retidos, obrigação, prazo e declarações decorrem de regras próprias, normalmente associadas à condição de responsável tributário. No RAD, a Lei Complementar nº 214/2025 descreve uma opção exercida pelo recolhimento do IBS e da CBS da operação nas condições do artigo 36. O parágrafo que criaria responsabilidade solidária do adquirente foi vetado; por isso, não é correto concluir apenas pelo RAD que toda a responsabilidade tributária do fornecedor foi transferida ao comprador.

Para o sistema, a consequência prática é manter naturezas de evento distintas. Um campo genérico como tributo_retido ou pagamento_imposto perde informação relevante e favorece lançamentos errados. O domínio deveria distinguir ao menos recolhimento ordinário do contribuinte, split payment, RAD, compensação e outras formas de extinção admitidas. Essa separação ajuda na contabilização e na auditoria e permite adaptar integrações sem reescrever todo o módulo fiscal.

A ligação entre débito extinto e crédito apropriável

A regra geral do novo modelo associa a apropriação do crédito pelo adquirente à extinção do débito correspondente, observadas as exceções e demais condições legais. Isso explica por que o RAD interessa ao comprador: ao recolher corretamente o IBS e a CBS daquela operação, ele produz um evento capaz de extinguir o débito associado e de sustentar a apropriação do crédito, desde que os outros requisitos tenham sido cumpridos. O recolhimento não corrige um documento fiscal inválido, uma classificação errada ou uma operação que não dê direito a crédito.

A cartilha do CGIBS representa créditos ainda não liberados como valores “a apropriar” e, nas simulações, mostra a confirmação do crédito do adquirente após o recolhimento e a extinção do débito do fornecedor. Essa transição recomenda uma máquina de estados, em vez de um indicador verdadeiro ou falso. Um crédito pode estar identificado, aguardando extinção, confirmado, apropriado, ajustado ou cancelado. Cada mudança deve guardar data, origem, valor, identificador do evento e resposta do ambiente oficial.

Esse cuidado se conecta à apuração assistida e às APIs fiscais. A documentação de recolhimentos da CBS descreve uma consulta assíncrona dos recolhimentos registrados para o contribuinte como adquirente, incluindo RAD e split payment. Em vez de presumir que a emissão de uma guia ou ordem bancária concluiu o processo, o ERP deve consultar o resultado oficial, importar os eventos e conciliá-los com sua escrituração.

O que acontece quando o valor recolhido é maior

O artigo 36 determina que o valor recolhido pelo adquirente seja usado exclusivamente para extinguir débitos de IBS e CBS relativos às respectivas operações. Se houver excedente, ele deve ser transferido ao fornecedor em até três dias úteis. Esse detalhe afasta a ideia de que a diferença possa ser reaproveitada livremente pelo comprador ou compensada de modo informal em outra aquisição. O vínculo com a operação precisa sobreviver a todo o processamento.

Para atender à regra, o ERP deve registrar separadamente valor calculado, solicitado, efetivamente reconhecido, utilizado na extinção e eventual excedente. A diferença não deveria desaparecer em uma conta genérica: ela exige acompanhamento até a transferência ao fornecedor. A cartilha do CGIBS identifica esse movimento como valor transferido por excesso, o que reforça a necessidade de evento próprio na apuração e na conciliação bancária.

A lei ainda prevê que o CGIBS e a Receita Federal estabeleçam mecanismo para o fornecedor acompanhar o recolhimento feito pelo adquirente. Isso exige visões complementares. Quando a empresa compra, acompanha confirmação e crédito. Quando vende, reconhece que um terceiro recolheu valor associado ao seu débito, confere a extinção e trata eventual excesso. Grupos empresariais com compras e vendas sentirão as duas necessidades no mesmo ecossistema.

Um fluxo seguro para o ERP

Imagine uma compra cujo documento fiscal contenha IBS e CBS corretamente calculados. A tesouraria informa que o pagamento comercial será feito por instrumento que, naquela operação, não admite a segregação do split payment. Antes de oferecer o RAD, o sistema verifica o regime do adquirente, a elegibilidade da operação, a identidade do fornecedor, as chaves dos documentos e os valores individualizados de cada tributo. O exemplo é conceitual: alíquotas, leiautes e procedimentos devem vir da documentação vigente, nunca de números fixados no código.

Depois da aprovação fiscal, o ERP cria uma intenção de RAD idempotente, com identificador que impeça duplicação caso haja repetição de mensagem ou falha de comunicação. A ordem de recolhimento não deve liberar imediatamente o crédito. O sistema aguarda o processamento, consulta a situação oficial, confere os valores reconhecidos e só então movimenta o crédito do estado “a apropriar” para o estado admitido pela apuração. Se ocorrer rejeição, divergência ou processamento parcial, a operação permanece pendente para análise.

Uma implementação consistente pode organizar o processo nestas etapas:

1. validar o regime regular do adquirente e os requisitos do artigo 36;
2. registrar por que o instrumento de pagamento não permitiu o split payment;
3. relacionar estabelecimento, fornecedor, documento, débitos de IBS e CBS e vencimentos;
4. obter aprovação fiscal e impedir recolhimentos duplicados;
5. transmitir ou registrar o recolhimento sem expor credenciais em logs;
6. consultar o processamento e conciliar valor solicitado, reconhecido, utilizado e excedente;
7. liberar o crédito apenas quando a extinção estiver confirmada e os demais requisitos forem satisfeitos;
8. conservar trilha de auditoria, histórico de estados e mecanismo autorizado de ajuste.

Esse desenho combina bem com arquitetura orientada a eventos. O contas a pagar comunica o meio de pagamento; o fiscal avalia a elegibilidade; a integração registra e consulta o recolhimento; a apuração reage à confirmação; e a contabilidade recebe os lançamentos. Cada componente continua responsável por seu domínio, mas todos compartilham identificadores estáveis. A mesma rastreabilidade aparece na adaptação de devoluções ao IBS, à CBS e ao split payment, pois um cancelamento posterior também precisa alcançar eventos financeiros e fiscais relacionados.

APIs ajudam, mas não substituem a regra de negócio

Em setembro de 2026, a Receita Federal publicou nova documentação técnica das APIs de apuração da CBS. O cronograma divulgado prevê, em produção restrita, consulta de pagamentos e recolhimentos no início de novembro e emissão de documento de arrecadação para RAD e recolhimento pelo contribuinte no fim daquele mês. Como é uma evolução em ambiente beta, contratos, datas e comportamentos precisam ser confirmados antes de cada implantação.

A API resolve transporte e consulta, mas não decide se a operação é elegível, não substitui a validação contábil e não garante sozinha que o crédito possa ser apropriado. O ERP continua responsável por selecionar documentos, manter consistência de valores, controlar concorrência e interpretar respostas. Também deve tratar indisponibilidade sem multiplicar recolhimentos: idempotência, fila de retentativas, reconciliação posterior e alertas são requisitos financeiros, não refinamentos opcionais.

É recomendável manter o conector oficial isolado do núcleo de apuração por uma camada de adaptação. Assim, alteração de endpoint, autenticação, esquema ou ambiente não contamina as regras centrais. Os contratos recebidos devem ser versionados, e respostas desconhecidas precisam seguir para análise, em vez de serem silenciosamente aceitas. Para equipes Delphi, isso significa separar clientes HTTP e DTOs das entidades que representam operação, débito, recolhimento e crédito.

Decisões que ainda exigem acompanhamento

A base legal permite compreender os limites do RAD, mas a operação concreta depende de regulamentação e infraestrutura em evolução. O Portal Contábeis chamou atenção para operações com maior risco fiscal do fornecedor. Essa pode ser uma dimensão da análise empresarial, porém o perfil de risco não substitui as condições do artigo 36. Um fornecedor considerado arriscado não torna o RAD automaticamente aplicável se o pagamento admitir split payment ou se o adquirente não estiver no regime regular.

Também é prematuro codificar uma política universal. Volume, custo operacional, prazo de confirmação, tratamento de exceções e conciliação de excedentes podem tornar o RAD apropriado em um processo e inadequado em outro. A decisão deve ser parametrizada por estabelecimento e cenário, aprovada pela área fiscal e revisada quando a regulamentação mudar. Regras críticas precisam registrar versão e vigência para que uma auditoria reconstrua por que o sistema tomou determinada decisão.

Ambientes de teste e produção devem ser claramente separados. Dados de homologação não podem liberar créditos reais, e resultados simulados precisam ser identificados. Antes de ativar o recurso, vale testar documento cancelado, pagamento duplicado, recolhimento parcial, valor excedente, indisponibilidade da API, resposta fora de ordem e alteração do regime. O caminho feliz demonstra a integração; as exceções demonstram se o controle fiscal está pronto.

Conclusão

O adquirente pode recolher IBS e CBS pelo RAD quando estiver no regime regular e o pagamento ao fornecedor usar instrumento que não permita segregação e recolhimento pelo split payment, sempre com vínculo aos tributos da operação. O mecanismo pode extinguir o débito e sustentar o crédito correspondente, mas não dispensa os demais requisitos legais, não equivale a retenção genérica e não autoriza escolher livremente entre RAD e split payment.

Para quem desenvolve ERP, o ponto decisivo é tratar o RAD como processo fiscal rastreável, não como botão de pagamento. Documento, débito, meio de pagamento, recolhimento, confirmação, crédito e eventual excedente precisam formar uma cadeia auditável, com estados claros e integrações idempotentes. A legislação fornece o contorno; a documentação oficial fornecerá detalhes crescentes. Separar regra de negócio, integração e conciliação permitirá acompanhar essa evolução sem comprometer a apuração nem o direito ao crédito.

Referências

BRASIL. Lei Complementar nº 214, de 16 de janeiro de 2025. Institui o IBS, a CBS e o Imposto Seletivo. Brasília, DF: Presidência da República, 2025. Disponível em: https://legis.senado.leg.br/norma/40180341/publicacao/40181429. Acesso em: 17 set. 2026.

COMITÊ GESTOR DO IMPOSTO SOBRE BENS E SERVIÇOS. Cartilha orientativa da apuração do IBS: volume 2. Versão 1.00. Brasília, DF: CGIBS, 2026. Disponível em: https://www.cgibs.gov.br/upload/arquivos/202601/26155056-cartilha-apurac-a-o-do-ibs-vol-2-v1-00-20260105-docx.pdf. Acesso em: 17 set. 2026.

MACARIO, Lívia. Recolhimento pelo adquirente: entenda as regras do RAD para IBS e CBS. Portal Contábeis, 12 set. 2026. Disponível em: https://www.contabeis.com.br/noticias/79326/rad-entenda-quando-o-adquirente-podera-recolher-ibs-e-cbs/. Acesso em: 17 set. 2026.

RECEITA FEDERAL DO BRASIL. Receita Federal publica nova documentação técnica das APIs de apuração da CBS. Brasília, DF, set. 2026. Disponível em: https://www.gov.br/receitafederal/pt-br/assuntos/noticias/2026/setembro/receita-federal-publica-nova-documentacao-tecnica-das-apis-de-apuracao-de-cbs. Acesso em: 17 set. 2026.

RECEITA FEDERAL DO BRASIL. Recolhimentos CBS. Documentação dos Serviços da Receita Federal, 2026. Disponível em: https://docs.receitafederal.gov.br/apuracao-cbs/recolhimentos.html. Acesso em: 17 set. 2026.