RAD na Reforma Tributária: como funciona o Recolhimento pelo Adquirente no IBS e na CBS

Introdução

A Reforma Tributária do Consumo criou uma mudança importante na relação entre compra, pagamento do tributo e apropriação de créditos.

No novo modelo, o crédito do IBS e da CBS está ligado, como regra geral, à extinção do débito tributário da operação anterior. Isso significa que o documento fiscal continua sendo essencial, mas a existência da NF-e, NFS-e ou de outro documento fiscal eletrônico, isoladamente, não representa em todas as situações o evento definitivo que libera o crédito.

Dentro dessa lógica surge o RAD — Recolhimento pelo Adquirente.

O mecanismo permite que o comprador, quando sujeito ao regime regular e atendidas as condições legais, recolha o IBS e a CBS incidentes sobre uma operação de aquisição. O recolhimento fica vinculado à operação e pode extinguir o débito ainda aberto do fornecedor, permitindo a apropriação do crédito correspondente pelo adquirente conforme as regras de não cumulatividade.

Para sistemas ERP, o RAD cria uma nova conexão entre compras, documentos fiscais, contas a pagar, tesouraria, apuração tributária e integração com a Administração Tributária.

O que é o RAD?

RAD é a sigla utilizada para Recolhimento pelo Adquirente.

A modalidade está prevista no art. 36 da Lei Complementar nº 214/2025 e integra as formas legais de extinção dos débitos de IBS e CBS previstas no art. 27 da mesma lei.

Pelo art. 36, o adquirente de bens ou serviços que seja contribuinte do IBS e da CBS pelo regime regular poderá recolher os tributos incidentes sobre a operação quando o pagamento ao fornecedor ocorrer por instrumento de pagamento que não permita a segregação e o recolhimento por split payment.

Em termos práticos:

o fornecedor possui um débito de IBS/CBS decorrente da venda, mas, nas condições legais do RAD, o adquirente pode recolher o valor vinculado àquela operação.

Esse ponto é essencial: o RAD é um recolhimento vinculado à operação. Ele não funciona como um pagamento genérico que o comprador realiza para quitar qualquer débito tributário do fornecedor.

Onde o RAD aparece entre as formas de extinção do débito?

O art. 27 da LC nº 214/2025 prevê cinco modalidades de extinção dos débitos de IBS e CBS:

1. compensação com créditos apropriados pelo contribuinte;
2. pagamento pelo próprio contribuinte;
3. recolhimento na liquidação financeira da operação — split payment;
4. recolhimento pelo adquirente — RAD;
5. pagamento por responsável tributário.

Existe uma diferença operacional importante.

Na compensação com créditos e no pagamento pelo próprio contribuinte, a extinção é imputada aos débitos não extintos segundo a ordem cronológica prevista na legislação.

No split payment e no RAD, a extinção é vinculada à respectiva operação.

Essa característica é o que permite relacionar o recolhimento diretamente ao documento fiscal que originou o débito.

Para que serve o RAD?

O RAD tem duas funções centrais.

A primeira é permitir a extinção do IBS e da CBS de uma operação quando o instrumento de pagamento utilizado não comportar o split payment.

A segunda é relevante para o adquirente: permitir que a extinção do débito da operação seja identificada e, observadas as demais condições legais, viabilize a apropriação do crédito.

A LC nº 214/2025 determina, no art. 47, que o contribuinte sujeito ao regime regular poderá apropriar créditos quando ocorrer a extinção dos débitos relativos às operações em que seja adquirente.

O documento fiscal eletrônico também continua obrigatório: a apropriação do crédito está condicionada à comprovação da operação por documento fiscal eletrônico idôneo.

Portanto, a lógica geral pode ser representada assim:

Documento fiscal idôneo → débito do fornecedor → extinção do débito → apropriação do crédito pelo adquirente

O RAD atua justamente na etapa de extinção.

Essa sequência representa a regra geral. A própria LC nº 214/2025 contém exceções e regras transitórias, entre elas o art. 48, tratadas adiante.

RAD não é retenção na fonte nem substituição tributária

Um dos principais riscos de interpretação é tratar o RAD como se fosse uma nova retenção.

Não é.

No RAD, o adquirente não se torna automaticamente responsável tributário pelo débito do fornecedor. A própria LC nº 214/2025 trata o recolhimento pelo adquirente e o pagamento por responsável tributário como modalidades distintas no art. 27.

Também não se deve concluir que o art. 36, isoladamente, autoriza o comprador a reduzir unilateralmente o valor comercial devido ao fornecedor.

A legislação tributária disciplina quem pode recolher o tributo e como esse recolhimento extingue o débito. A forma de ajustar o fluxo financeiro entre comprador e fornecedor precisa ser compatível com o contrato, a negociação comercial e os procedimentos operacionais adotados pelas partes.

Para o ERP, isso significa que recolher o RAD e liquidar o título do fornecedor são eventos relacionados, mas não devem ser modelados como se fossem necessariamente o mesmo evento.

Quando o RAD pode ser utilizado?

Pela regra geral do art. 36, devem estar presentes pelo menos os seguintes elementos:

• o adquirente deve ser contribuinte do IBS e da CBS sujeito ao regime regular;
• devem existir débitos de IBS e CBS incidentes sobre a operação, conforme o tratamento tributário aplicável;
• o pagamento ao fornecedor deve utilizar instrumento que não permita a segregação e o recolhimento nos termos do split payment;
• o recolhimento deve estar vinculado à operação correspondente.

O RAD, portanto, não é uma escolha indiscriminada para qualquer compra nem um mecanismo criado simplesmente para classificar fornecedores como “seguros” ou “arriscados”.

Sua utilização depende das hipóteses legais e da operacionalização definida pela Administração Tributária.

No âmbito da CBS, o Decreto nº 12.955/2026 acrescenta uma regra operacional importante: quando o pagamento ao fornecedor utilizar mais de um instrumento de pagamento, cada transação deverá ser considerada separadamente para fins do RAD.

Como funciona o RAD na prática?

Considere uma operação simplificada.

Uma empresa Fornecedor A vende mercadorias para a empresa Adquirente B.

O documento fiscal registra:

Suponha que o pagamento seja realizado por instrumento que não permita o split payment e que a operação atenda às condições do RAD.

1. O fornecedor emite o documento fiscal

O documento gera o débito tributário correspondente à operação.

2. O adquirente identifica a operação

O sistema do comprador precisa relacionar, no mínimo:

• documento fiscal;
• fornecedor;
• tributo;
• valor do débito da operação;
• situação da extinção;
• pagamento comercial relacionado.

3. O adquirente realiza o RAD

O recolhimento deve ser identificado com a operação específica.

No exemplo, se os R$ 1.000,00 ainda estiverem integralmente em aberto e forem recolhidos pelo adquirente, o valor será destinado à extinção daquele débito.

4. O débito do fornecedor é extinto

O RAD não é lançado livremente contra outros débitos do fornecedor. Por ser recolhimento vinculado, ele é utilizado na operação à qual se refere.

5. O crédito do adquirente pode ser apropriado

Ocorrida a extinção e atendidas as demais condições do art. 47, o adquirente poderá apropriar crédito limitado ao valor do tributo destacado e efetivamente extinto.

No exemplo simplificado, se os R$ 1.000,00 forem integralmente extintos e não houver impedimento legal ao crédito, o adquirente poderá apropriar o crédito correspondente de CBS.

E se parte do débito já tiver sido extinta?

Esse é um cenário que o ERP precisa prever.

Imagine que o débito original da operação seja R$ 1.000,00, mas R$ 400,00 já tenham sido extintos anteriormente por outra modalidade.

O saldo ainda não extinto é de R$ 600,00.

Se houver recolhimento pelo adquirente acima do valor que ainda poderia ser utilizado naquela operação, a legislação determina que o excedente não seja utilizado para extinguir outro débito qualquer do fornecedor.

O art. 36 prevê a transferência ao fornecedor do valor excedente que não for utilizado na extinção dos débitos daquela operação, em até três dias úteis. No âmbito da CBS, o Decreto nº 12.955/2026 detalha que o prazo é contado da data do pagamento, ressalvada a hipótese de atraso do banco arrecadador no envio da informação à Receita Federal.

Esse comportamento reforça a necessidade de o ERP controlar:

débito original → valor já extinto → saldo em aberto → RAD realizado → RAD utilizado → eventual excedente

RAD e apropriação de créditos

O vínculo entre RAD e crédito está nos arts. 47 e 48 da LC nº 214/2025.

Regra geral

O art. 47 condiciona a apropriação dos créditos à extinção dos débitos relativos às operações de aquisição, além da existência de documento fiscal eletrônico idôneo e das demais condições legais.

O crédito apropriado corresponde, em regra, ao valor do IBS ou da CBS destacado no documento fiscal e efetivamente extinto.

Isso significa que uma extinção parcial pode produzir apropriação proporcional do crédito.

Regra transitória do art. 48

A própria LC nº 214/2025 prevê uma exceção importante.

Enquanto nenhuma das seguintes modalidades tiver sido implementada:

• split payment; ou
• recolhimento pelo adquirente,

fica dispensado o requisito de extinção do débito para apropriação do crédito, desde que os valores corretos de IBS e CBS estejam destacados no documento fiscal eletrônico.

Esse dispositivo evita que a não cumulatividade fique bloqueada antes da implantação dos mecanismos operacionais de extinção vinculada.

Um cuidado importante: a existência de ambiente piloto, Produção Restrita, Produção Beta ou documentação de API não deve ser tratada automaticamente como o marco jurídico de “implementação” previsto no art. 48. Para definir quando a dispensa transitória deixa de valer, devem ser observados os atos oficiais que efetivamente colocarem as modalidades em operação para os contribuintes alcançados.

Por isso, é incorreto afirmar simplesmente que “a partir da Reforma, só existe crédito depois de o fornecedor pagar o imposto” sem observar a regra transitória do art. 48 e as demais exceções da legislação.

RAD, split payment e PCONT: qual a diferença?

Os três conceitos não devem ser misturados.

O RAD e o split payment são particularmente importantes porque, pelo art. 27, a extinção realizada por essas modalidades fica vinculada à operação.

Como a Apuração Assistida entra nessa história?

A Apuração Assistida passa a reunir informações sobre:

• débitos gerados pelas operações;
• créditos;
• pagamentos pelo próprio contribuinte;
• recolhimentos efetuados por adquirentes;
• split payment;
• saldos da apuração.

Nos materiais oficiais do Piloto da CBS, a Receita Federal já demonstrou o RAD como evento de extinção vinculado à operação.

Em um exemplo oficial, apenas parte de determinado RAD foi utilizada porque o débito remanescente daquela operação era inferior ao valor recolhido. O saldo do RAD não foi deslocado para outro débito justamente porque o recolhimento pelo adquirente é vinculado à operação específica.

Essa lógica muda a forma de conciliar compras e tributos.

O ERP deixa de controlar apenas:

documento → escrituração → crédito

e passa a precisar acompanhar:

documento → débito da operação → eventos de extinção → crédito potencial → crédito apropriado

APIs da Receita Federal: o que já foi publicado?

Em setembro de 2026, a Receita Federal publicou documentação técnica das APIs da Apuração da CBS.

Entre os serviços estão:

• consulta de débitos;
• consulta de créditos;
• consulta de pagamentos de CBS;
• consulta de recolhimentos de CBS realizados na condição de adquirente, incluindo RAD e split payment;
• emissão de DARF para RAD;
• emissão de DARF para PCONT.

A documentação da API de consulta de recolhimentos prevê dados como:

• período de apuração;
• número do DARF;
• fornecedor;
• chave do DF-e;
• valor principal;
• multa;
• juros;
• valor total.

A Receita Federal informou o seguinte cronograma para os novos serviços nos ambientes de Produção Restrita e Produção Beta:

Esse cronograma é especialmente relevante para software houses porque permite iniciar a arquitetura de integração antes da operação definitiva da CBS.

Situação em 06/10/2026: o cronograma divulgado pela Receita Federal refere-se à disponibilização gradual dos serviços nos ambientes de Produção Restrita e Produção Beta. Portanto, ele deve ser tratado como cronograma técnico de integração e testes, e não como prova isolada de que o RAD já esteja operacional, em caráter definitivo, para todos os contribuintes.

Atenção: a documentação de APIs descrita acima, publicada pela Receita Federal, é específica para a CBS. No âmbito do IBS, o CGIBS já publicou regulamentação e material orientativo do seu Sistema de Apuração Assistida, inclusive com simulação de RAD no ambiente piloto. Esses materiais são referência importante para arquitetura e testes, mas o ambiente piloto também não deve ser confundido com implantação definitiva para todos os contribuintes.

Impactos para ERP

O RAD não deveria ser tratado apenas como uma nova opção de emissão de DARF.

Ele cria um fluxo transversal dentro do ERP.

Compras e recepção fiscal

O sistema precisa registrar a operação de aquisição e identificar o valor potencialmente creditável de IBS e CBS.

Devem estar relacionados:

• chave do DF-e;
• fornecedor;
• data da operação;
• período de apuração;
• IBS e CBS destacados;
• elegibilidade do crédito;
• situação de extinção dos débitos.

Contas a pagar

O financeiro precisa conhecer a existência de um RAD relacionado à operação.

Isso não significa simplesmente reduzir o título do fornecedor automaticamente.

O ERP deve permitir controlar separadamente:

• valor comercial devido ao fornecedor;
• valores tributários da operação;
• RAD previsto;
• RAD efetivamente recolhido;
• eventual ajuste financeiro acordado entre as partes.

Fiscal e apuração

O módulo fiscal deverá acompanhar diferentes estados da mesma aquisição.

Como modelo de arquitetura de ERP — e não como estrutura obrigatória de banco de dados criada pela legislação, um desenho possível é:

1. Crédito potencial — valor que a operação poderá gerar, sujeito às condições legais;
2. Débito extinto — parcela do tributo do fornecedor já extinta;
3. Valor a apropriar — parcela que já reúne condições para apropriação, mas ainda não foi processada internamente;
4. Valor apropriado — crédito efetivamente reconhecido na apuração do adquirente.

A lógica é coerente com a separação operacional já apresentada em materiais oficiais de Apuração Assistida. No Piloto do IBS, por exemplo, o CGIBS utiliza classificações como “A apropriar”, “Utilizados”, “Não utilizados” e “Transferidos por excesso”.

Esses estados não devem ser tratados como sinônimos, e o ERP não precisa reproduzir literalmente a nomenclatura das telas oficiais para manter a rastreabilidade necessária.

Tesouraria

O RAD cria uma nova saída financeira que não é simplesmente o pagamento de uma obrigação própria do comprador.

A tesouraria precisa identificar:

• operação que originou o recolhimento;
• documento de arrecadação;
• tributo;
• fornecedor;
• valor recolhido;
• situação do pagamento;
• retorno da Administração Tributária.

Integração com a Apuração Assistida

Para ERPs com integração automática, será necessário armazenar identificadores que permitam conciliar o retorno da Receita Federal com a operação original.

A documentação atual da CBS já utiliza campos como:

• CNPJ do fornecedor;
• chave do DF-e;
• período de apuração;
• número do DARF;
• valores de principal, multa, juros e total.

Existem duas perspectivas diferentes nas APIs publicadas:

• recolhimentos: permite ao adquirente consultar recolhimentos de CBS realizados nessa condição, incluindo RAD e split payment;
• pagamentos: permite ao contribuinte fornecedor consultar pagamentos que extinguem seus débitos, incluindo recolhimentos efetuados por adquirentes e split payment.

Essa diferença é importante porque o ERP precisa conciliar o mesmo fato sob duas óticas: quem recolheu e qual débito do fornecedor foi extinto.

Uma integração robusta deve ser idempotente: o mesmo evento recebido mais de uma vez não pode duplicar extinção ou crédito.

Impacto também para o ERP do fornecedor

O RAD não afeta apenas quem compra.

O fornecedor também precisa acompanhar:

• quais operações tiveram débito extinto por RAD;
• quem realizou o recolhimento;
• qual valor foi efetivamente utilizado;
• se ainda existe saldo tributário não extinto na operação;
• eventual valor excedente transferido;
• reflexo do evento na sua apuração.

O § 4º do art. 36 da LC nº 214/2025 determina que o CGIBS e a Receita Federal estabeleçam mecanismo para acompanhamento, pelo fornecedor, do recolhimento realizado pelo adquirente.

No desenho do ERP, isso significa que um RAD recebido não deve ser confundido com um pagamento comercial do cliente. Ele é um evento de extinção tributária da operação que precisa ser conciliado com a venda e com a apuração do fornecedor.

Relatórios e conciliação

Relatórios tradicionais de “créditos por documento” tendem a ser insuficientes.

Será necessário responder perguntas como:

• qual crédito ainda é apenas potencial?
• qual débito do fornecedor já foi extinto?
• qual modalidade extinguiu o débito?
• quanto foi recolhido por RAD?
• houve recolhimento excedente?
• o crédito correspondente já foi apropriado?
• existe divergência entre o ERP e a Apuração Assistida?

Modelo de dados recomendado para o ERP

Uma arquitetura segura deve evitar gravar toda a história do RAD em um único campo de status.

O ideal é separar entidades ou eventos.

Operação fiscal

Registra:

• DF-e;
• fornecedor;
• adquirente;
• base;
• IBS;
• CBS;
• período de apuração.

Extinção tributária

Registra cada evento de extinção:

• modalidade;
• tributo;
• valor;
• data;
• origem;
• vínculo com o DF-e;
• identificador externo;
• situação.

Crédito

Registra:

• crédito potencial;
• valor liberado para apropriação;
• valor apropriado;
• eventuais estornos;
• motivo do bloqueio.

Arrecadação

Registra:

• documento de arrecadação;
• pagamento;
• RAD ou PCONT;
• valor principal;
• multa;
• juros;
• retorno da Receita Federal.

Essa separação facilita auditoria, conciliação e futuras mudanças de regra.

Boas práticas

• não confundir RAD com retenção tributária;
• não permitir RAD sem vínculo com a operação;
• não gerar crédito automaticamente apenas pela existência do documento fiscal;
• controlar extinções parciais;
• separar crédito potencial de crédito apropriado;
• não utilizar eventual excedente do RAD para outro documento por decisão interna do ERP;
• manter histórico dos eventos recebidos da Administração Tributária;
• conciliar diariamente os dados internos com as APIs oficiais quando o serviço estiver disponível;
• versionar regras de integração e manter rastreabilidade do estado anterior;
• separar a implementação atualmente documentada para CBS da futura integração equivalente do IBS.

Erros comuns

Perguntas frequentes

O RAD é obrigatório?

A regra geral do art. 36 utiliza a expressão “poderá pagar”. Trata-se de uma modalidade facultada ao adquirente quando presentes as condições legais.

Isso não elimina outras regras de extinção nem autoriza o uso indiscriminado do mecanismo.

Qualquer comprador pode fazer RAD?

Não.

A regra geral do art. 36 é destinada ao adquirente que seja contribuinte do IBS e da CBS pelo regime regular e esteja na situação prevista pelo dispositivo.

O RAD pode quitar qualquer dívida do fornecedor?

Não.

O recolhimento pelo adquirente é vinculado à respectiva operação.

O RAD garante automaticamente o crédito?

O RAD extingue o débito da operação na extensão em que for efetivamente utilizado. A apropriação do crédito também depende das demais condições legais, inclusive documento fiscal eletrônico idôneo e inexistência de vedação específica.

Se o fornecedor já tiver extinguido parte do débito, o que acontece?

O RAD somente pode ser utilizado para os débitos ainda não extintos daquela operação. Eventual excedente segue a regra de transferência prevista na legislação.

O comprador pode simplesmente descontar IBS e CBS do pagamento ao fornecedor?

A norma tributária permite o recolhimento pelo adquirente nas hipóteses legais, mas não deve ser interpretada isoladamente como autorização para alteração unilateral da obrigação comercial.

O fluxo financeiro entre as partes precisa ser compatibilizado com os contratos e procedimentos adotados.

RAD e split payment são a mesma coisa?

Não.

No split payment, a segregação e o recolhimento ocorrem no fluxo da liquidação financeira por meio dos prestadores ou operadores do sistema de pagamento.

No RAD, quem realiza o recolhimento é o adquirente, nas condições do art. 36.

As APIs publicadas pela Receita Federal em 2026 já cobrem IBS e CBS?

Não.

A documentação de APIs atualmente disponibilizada pela Receita Federal para a Apuração Assistida é da CBS.

No IBS, o CGIBS possui regulamentação própria e material do Piloto da Apuração Assistida, inclusive com simulação de recolhimento pelo adquirente. Isso não significa que as APIs da CBS possam ser reutilizadas automaticamente para o IBS: os dois ambientes e respectivos atos técnicos precisam ser acompanhados separadamente.

O cronograma de APIs de novembro de 2026 significa que o RAD já será obrigatório?

Não necessariamente.

O cronograma divulgado em setembro de 2026 trata da disponibilização de serviços nos ambientes de Produção Restrita e Produção Beta. Ele orienta desenvolvimento e testes, mas não deve ser confundido com o marco jurídico de obrigatoriedade ou de implementação definitiva do RAD para todos os contribuintes.

Base legal

• Emenda Constitucional nº 132/2023, especialmente a autorização constitucional para vincular a apropriação do crédito ao recolhimento, desde que o adquirente possa efetuar o recolhimento ou ele ocorra na liquidação financeira;
• Lei Complementar nº 214/2025, com redação atualizada pela Lei Complementar nº 227/2026:
  • art. 27 — modalidades de extinção dos débitos;
  • art. 36 — recolhimento pelo adquirente;
  • arts. 45 e 46 — apuração e apuração assistida;
  • arts. 47 e 48 — apropriação de créditos e regra transitória;
• Decreto nº 12.955/2026 — regulamentação da CBS, inclusive recolhimento pelo adquirente;
• Resolução CGIBS nº 6, de 30 de abril de 2026 — regulamentação do IBS, inclusive modalidades de extinção e recolhimento pelo adquirente;
• documentação oficial da Receita Federal para a Apuração Assistida da CBS e respectivas APIs;
• materiais oficiais do CGIBS para a Apuração Assistida do IBS, inclusive o fluxo de simulação de RAD no Piloto.

Fontes oficiais

• Lei Complementar nº 214/2025 — texto atualizado — Câmara dos Deputados
• Lei Complementar nº 214/2025 — texto compilado — Planalto
• Decreto nº 12.955/2026 — Planalto
• Receita Federal — Documentação da Apuração da CBS
• Receita Federal — API de consulta de recolhimentos CBS
• Receita Federal — API de consulta de pagamentos CBS
• Receita Federal — novas APIs da Apuração da CBS e cronograma
• Receita Federal — materiais da Reforma Tributária do Consumo
• CGIBS — Resolução nº 6, de 30 de abril de 2026
• CGIBS — Apuração do IBS, Cartilha Orientativa, Volume 2

Conteúdos relacionados

• Split Payment no IBS e na CBS
• Apuração Assistida da CBS
• Extinção do débito e apropriação de créditos no IBS e na CBS
• Créditos de IBS e CBS na Reforma Tributária

Conclusão

O RAD é uma das peças centrais da nova lógica de não cumulatividade do IBS e da CBS.

Seu impacto vai além da arrecadação. Ele conecta o pagamento de uma aquisição à extinção do débito do fornecedor e, consequentemente, ao processo de apropriação do crédito pelo adquirente.

Para as empresas, isso cria a necessidade de conciliar fiscal e financeiro com muito mais precisão.

Para fornecedores de ERP, a principal mudança é conceitual: não basta saber que existe um documento fiscal e um valor de crédito. O sistema precisará acompanhar qual débito foi extinto, por qual modalidade, em qual valor, em qual momento e qual parcela do crédito já pode ser efetivamente apropriada.

O caminho mais seguro é tratar o RAD como um evento tributário próprio, vinculado à operação e integrado à Apuração Assistida — e não como uma simples retenção ou mais um campo dentro do contas a pagar.