Receita Federal publica documentação de novas APIs de apuração da CBS

TL;DR

A Receita Federal publicou, em 14 de setembro de 2026, nova documentação técnica para as APIs de apuração da Contribuição sobre Bens e Serviços (CBS).

As novas APIs contemplam consultas de débitos, créditos, pagamentos e recolhimentos realizados pelo adquirente, além de serviços previstos para emissão de DARF de Recolhimento pelo Adquirente (RAD) e Pagamento do Contribuinte (PCONT).

As consultas de débitos e créditos funcionam de forma incremental e assíncrona. A documentação estabelece uma janela máxima de retorno de 8 dias. Na primeira consulta, quando ainda não existe registro de consulta anterior, são retornadas as inclusões e atualizações ocorridas desde o primeiro dia do mês corrente.

O cronograma oficial prevê disponibilização gradual nos ambientes de Produção Restrita (Piloto da CBS) e Produção Beta: débitos e créditos no início de outubro de 2026; pagamentos e recolhimentos pelo adquirente no início de novembro; e emissão de DARF para RAD e PCONT no fim de novembro.

Para fornecedores de ERP e empresas que utilizam integração sistêmica, o ponto de atenção não é apenas consumir novos endpoints. Será necessário implementar corretamente o fluxo assíncrono, o webhook HTTPS, o controle local dos dados recebidos e os cuidados de segurança definidos pela Receita.

O que aconteceu

A Receita Federal anunciou uma nova documentação técnica para integração com os serviços de apuração da CBS.

Segundo o comunicado oficial, os novos serviços gratuitos contemplarão consultas de:

• débitos;
• créditos;
• pagamentos;
• recolhimentos realizados pelo adquirente.

Também estão previstos serviços para:

• emissão de DARF para Recolhimento pelo Adquirente (RAD);
• emissão de DARF para Pagamento do Contribuinte (PCONT).

A disponibilização ocorrerá gradualmente a partir de outubro de 2026.

A Receita também destacou uma mudança importante em relação à versão anterior: as novas APIs passam a trabalhar com consultas incrementais, reduzindo o volume de dados retornados em cada consulta.

Como funcionam as consultas incrementais

Nos serviços de consulta de débitos e créditos já documentados, o retorno considera registros incluídos ou atualizados entre a consulta atual e a consulta anterior.

A Receita definiu duas regras importantes:

• a janela máxima de retorno das informações é de 8 dias;
• na primeira consulta, quando não há registro de consulta anterior, são retornadas inclusões e atualizações ocorridas a partir do primeiro dia do mês corrente.

Isso significa que a integração não deve partir da premissa de que uma consulta feita após um intervalo indefinido recuperará todo o histórico desde a última execução.

A periodicidade de consumo precisa respeitar a janela documentada pela Receita para os endpoints de débitos e créditos.

O ERP informa data ou cursor da consulta?

Nos endpoints publicados de débitos e créditos, a documentação não apresenta um parâmetro de período, data inicial ou cursor a ser definido pelo consumidor.

Os campos de entrada documentados concentram-se no CNPJ base, autenticação e urlRetorno do webhook.

Portanto, o controle incremental da consulta é determinado pelo funcionamento do serviço da Receita, enquanto o ERP deve manter seus próprios controles locais para saber quais arquivos, registros e eventos já foram recebidos e processados.

Esse controle local é uma recomendação de arquitetura do Tribium e não deve ser confundido com um cursor enviado à API.

As APIs funcionam de forma assíncrona

Outro ponto central para fornecedores de ERP é o processamento assíncrono.

A chamada inicial não retorna imediatamente o arquivo final com os dados.

O fluxo documentado pela Receita ocorre, em linhas gerais, da seguinte forma:

1. o sistema cliente obtém o token de autenticação;
2. envia a solicitação para a API específica, informando uma urlRetorno HTTPS;
3. a Receita valida a disponibilidade do webhook;
4. quando a solicitação é aceita, retorna um tiqueteSolicitacao;
5. o processamento ocorre de forma assíncrona;
6. ao concluir, a Receita envia uma notificação para o webhook;
7. em caso de sucesso, a notificação contém o tiqueteSolicitacao, a urlAssinada e a data de expiração da URL;
8. o sistema cliente utiliza a URL assinada para baixar o arquivo de retorno.

A situação da solicitação também pode ser consultada por endpoint específico utilizando o tíquete.

A documentação informa tempo limite de processamento de até 240 minutos (4 horas).

URL assinada e prazo para download

Quando o processamento é concluído com sucesso, a Receita disponibiliza uma URL assinada para download do arquivo.

Essa URL:

• é temporária;
• deve ser tratada como informação sensível;
• permanece disponível por 48 horas;
• pode ser utilizada para download dentro desse período;
• deixa de funcionar após a expiração.

A Receita orienta expressamente que a URL assinada não seja registrada em logs, mensagens de erro, métricas, histórico do navegador ou ferramentas de rastreamento.

Limite de chamadas

As regras comuns das APIs assíncronas informam limite de quatro chamadas por dia para o endpoint de abertura da solicitação.

A documentação consultada não detalha, nessa regra, se a contabilização do limite ocorre por CNPJ, credencial, API ou outro critério. Por isso, esse ponto não deve ser transformado em premissa específica de capacidade sem confirmação adicional da Receita Federal.

O limite deve ser considerado no desenho da rotina de integração, em conjunto com a janela máxima de 8 dias estabelecida para as consultas de débitos e créditos.

Quem é impactado

A publicação interessa principalmente a:

• fornecedores de sistemas ERP;
• empresas de software fiscal e tributário;
• desenvolvedores responsáveis por integrações fiscais;
• empresas que utilizarão integração sistêmica com a apuração da CBS;
• equipes fiscais e tributárias;
• equipes de TI, arquitetura e segurança;
• empresas com elevado volume de transações;
• áreas financeiras relacionadas ao pagamento e recolhimento de tributos.

A própria Receita Federal recomenda que empresas desenvolvedoras de software e contribuintes que utilizam integração sistêmica consultem a documentação e iniciem o planejamento das adequações necessárias.

Impactos práticos

Consulta de débitos e créditos

Os sistemas poderão consumir informações de débitos e créditos incluídos ou atualizados na apuração da CBS.

O modelo permite que as empresas incorporem esses dados aos seus processos internos de acompanhamento e conciliação.

Porém, a janela máxima de 8 dias exige disciplina operacional: uma integração que deixe de consultar o serviço por período superior ao limite documentado não deve presumir que receberá automaticamente todo o histórico ausente.

Consulta de pagamentos

O cronograma oficial prevê para o início de novembro a consulta de pagamentos.

Esse serviço poderá apoiar a conciliação entre os débitos existentes e os pagamentos que produzem sua extinção, conforme a estrutura disponibilizada pela Receita.

Recolhimentos realizados pelo adquirente

Também está prevista consulta de recolhimentos realizados pelo adquirente.

A documentação da apuração relaciona esse grupo ao Recolhimento pelo Adquirente (RAD) e ao split payment.

Emissão de DARF

Para o fim de novembro de 2026, a Receita prevê serviços para emissão de DARF relacionados a:

• RAD — Recolhimento pelo Adquirente;
• PCONT — Pagamento do Contribuinte.

A integração, portanto, passa a alcançar não apenas consultas da apuração, mas também serviços relacionados ao recolhimento.

Impacto para ERP

O impacto técnico mais concreto está no desenho da integração assíncrona.

Autenticação

As regras comuns documentam uso de TLS e OAuth 2.0 no fluxo Client Credentials.

A aplicação utiliza credenciais válidas para obtenção do token e envia o access_token no cabeçalho Authorization das chamadas.

Tokens e credenciais não devem ser expostos em logs.

Webhook HTTPS

O ERP ou componente de integração precisa disponibilizar uma urlRetorno HTTPS válida.

A Receita realiza uma chamada HEAD para verificar a disponibilidade do endereço antes de aceitar a solicitação.

Segundo a documentação oficial, o endpoint deve:

• utilizar HTTPS;
• manter validação adequada do certificado TLS;
• permanecer disponível durante o processamento;
• utilizar rota dedicada ao recebimento das notificações;
• responder adequadamente às notificações;
• prever mecanismos contra repetição e abuso.

A validação HEAD confirma a disponibilidade do endereço, mas não substitui controles de autenticação e validação do conteúdo recebido.

Tíquete e processamento assíncrono

Quando uma solicitação é aceita, a API retorna um tiqueteSolicitacao.

Esse identificador deve fazer parte do controle técnico da integração, pois permite correlacionar a solicitação com o retorno e consultar seu status quando necessário.

Download e armazenamento

Após a conclusão do processamento, o webhook recebe a URL assinada para download.

O ERP ou middleware deve baixar o arquivo dentro do prazo de 48 horas e tratar a URL como segredo temporário.

Controle local de sincronização

A Receita mantém o comportamento incremental do serviço.

Separadamente, o ERP precisa de controles internos para evitar problemas no seu próprio processamento.

Como recomendação de arquitetura do Tribium, é importante registrar de forma segura:

• tiqueteSolicitacao;
• horário da solicitação;
• resultado do processamento;
• identificador interno de correlação;
• status de importação do arquivo;
• identificadores dos registros já processados, quando necessários ao desenho do sistema.

Esse controle local serve para idempotência, rastreabilidade e recuperação da aplicação.

Ele não significa que o ERP possa definir ou retroceder livremente o período da consulta na API.

Reprocessamento: atenção ao conceito

A documentação consultada não demonstra que os endpoints incrementais de débitos e créditos permitam solicitar livremente um período histórico já consultado.

Por isso, o ERP não deve depender de uma suposta função de “voltar o cursor” da Receita.

Quando houver necessidade de recuperação, o sistema pode reprocessar localmente os arquivos e dados que já tenham sido obtidos e armazenados de forma válida.

Qualquer possibilidade de reconsulta histórica pela API deve ser tratada somente quando houver mecanismo oficial documentado para isso.

Integração fiscal e financeira

Os futuros serviços de DARF para RAD e PCONT também aproximam os processos fiscais e financeiros.

Dependendo da arquitetura do ERP, podem estar envolvidos:

• módulo fiscal;
• contas a pagar;
• tesouraria;
• gestão tributária;
• serviços de integração;
• conciliação;
• controles de arrecadação.

A definição exata desses fluxos depende da arquitetura de cada produto.

Segurança de logs e auditoria

A Receita estabelece cuidados específicos para o registro de informações.

A documentação recomenda manter auditoria sem dados sensíveis, registrando no mínimo elementos como:

• tiqueteSolicitacao;
• horário;
• resultado do processamento;
• identificador de correlação.

Ao mesmo tempo, devem ser mascarados ou excluídos dos logs:

• tokens;
• credenciais;
• URLs pré-assinadas;
• dados pessoais, quando aplicável.

A urlAssinada não deve ser gravada em logs, mensagens de erro, métricas, histórico de navegador ou ferramentas de rastreamento.

O que fazer agora

1. Consultar a documentação técnica oficial da apuração da CBS.
2. Mapear quais serviços serão consumidos pelo ERP ou solução fiscal.
3. Preparar autenticação OAuth 2.0 conforme o padrão documentado.
4. Disponibilizar e proteger o webhook HTTPS exigido pelo fluxo assíncrono.
5. Planejar a rotina de consultas respeitando a janela máxima de 8 dias para débitos e créditos.
6. Implementar controle local de tíquetes, arquivos recebidos e processamento idempotente.
7. Definir processo seguro para download e descarte das URLs assinadas.
8. Revisar políticas de logs para impedir armazenamento de tokens, credenciais e URLs pré-assinadas.
9. Considerar o limite de quatro chamadas diárias do endpoint de abertura no desenho da integração.
10. Preparar testes nos ambientes disponibilizados pela Receita conforme o cronograma.
11. Avaliar os impactos dos futuros serviços RAD e PCONT nos módulos fiscal e financeiro.
12. Monitorar atualizações da documentação durante a evolução dos serviços.

Linha do tempo

Os serviços serão disponibilizados gradualmente nos ambientes de Produção Restrita (Piloto da CBS) e Produção Beta.

O comunicado não estabelece uma data única de obrigatoriedade de uso dessas APIs pelos contribuintes.

Base legal e contexto

A CBS foi instituída pela Lei Complementar nº 214, de 16 de janeiro de 2025, no contexto da Reforma Tributária do Consumo.

O art. 36 da LC nº 214/2025, em sua redação vigente, disciplina o recolhimento do IBS e da CBS pelo adquirente nas condições previstas na própria lei.

A publicação da Receita Federal de 14 de setembro de 2026 tem caráter técnico e operacional: apresenta novos serviços de integração e seu cronograma de disponibilização.

Ela não cria, por si só, nova hipótese de incidência ou nova obrigação tributária.

Fontes oficiais

• Receita Federal — Nova documentação técnica das APIs de apuração da CBS: https://www.gov.br/receitafederal/pt-br/assuntos/noticias/2026/setembro/receita-federal-publica-nova-documentacao-tecnica-das-apis-de-apuracao-de-cbs
• Receita Federal — Documentação da apuração da CBS: https://docs.receitafederal.gov.br/apuracao-cbs/
• Receita Federal — Regras comuns das APIs assíncronas: https://docs.receitafederal.gov.br/apuracao-cbs/guiaapiassincrona.html
• Receita Federal — Consulta de débitos da CBS: https://docs.receitafederal.gov.br/apuracao-cbs/debito.html
• Receita Federal — Consulta de créditos da CBS: https://docs.receitafederal.gov.br/apuracao-cbs/credito.html
• Presidência da República — Lei Complementar nº 214/2025, texto compilado: https://www.planalto.gov.br/ccivil_03/leis/lcp/lcp214compilado.htm

Análise Tribium

A publicação é mais relevante para os fornecedores de ERP do que uma simples ampliação do catálogo de APIs.

O modelo combina três características que precisam ser consideradas em conjunto: consulta incremental, processamento assíncrono e janela máxima de retorno.

A consulta incremental reduz a repetição de dados, mas a janela máxima de 8 dias torna a regularidade da integração um requisito operacional importante.

Ao mesmo tempo, como o processamento é assíncrono, não basta criar uma rotina que execute uma requisição HTTP e aguarde os dados na própria resposta.

A integração precisa trabalhar com:

• autenticação;
• solicitação;
• tíquete;
• webhook;
• acompanhamento de status;
• URL assinada;
• download do arquivo;
• processamento local;
• auditoria segura.

Há também uma separação importante entre o que a Receita controla e o que cabe ao ERP.

A Receita controla o comportamento incremental da API. Já o ERP precisa controlar sua própria execução: quais solicitações realizou, quais arquivos recebeu, quais dados processou e quais operações precisam ser retomadas internamente em caso de falha.

Isso é diferente de presumir que o ERP controla um cursor remoto ou consegue solicitar arbitrariamente qualquer intervalo histórico.

Para fornecedores de software, os testes devem abranger cenários como:

• webhook temporariamente indisponível;
• processamento ainda pendente;
• consulta de status após ausência de notificação;
• URL assinada próxima da expiração;
• download repetido dentro das 48 horas;
• falha após o download e antes da importação;
• reprocessamento local do mesmo arquivo;
• prevenção de duplicidade;
• mascaramento de informações sensíveis;
• retomada segura da integração.

Esses cenários são mais importantes do que apenas validar se o endpoint responde com HTTP 201.

Conclusão

A nova documentação das APIs de apuração da CBS representa mais uma etapa da infraestrutura tecnológica da Reforma Tributária do Consumo.

A partir de outubro de 2026, a Receita Federal prevê iniciar a disponibilização das consultas de débitos e créditos. Em novembro, o escopo será ampliado para pagamentos, recolhimentos realizados pelo adquirente e emissão de DARF para RAD e PCONT.

Para os ERPs, os pontos técnicos mais relevantes são a janela máxima de 8 dias, o processamento assíncrono, o uso de webhook HTTPS, o controle por tíquete, o download por URL assinada válida por 48 horas, o limite de quatro chamadas diárias no endpoint de abertura e os cuidados de segurança com logs e credenciais.

Além dos requisitos oficiais, cada fornecedor deverá implementar controles locais de idempotência, rastreabilidade e recuperação compatíveis com sua própria arquitetura.

O período de Produção Restrita e Produção Beta deve ser utilizado para validar não apenas conectividade, mas o ciclo completo da integração e seus cenários de falha.