A Receita Federal publicou no dia 14 de setembro a documentação técnica das novas APIs de apuração da CBS, a Contribuição sobre Bens e Serviços. São interfaces gratuitas para consultar débitos, créditos, pagamentos e recolhimentos, além de dois serviços para emissão de DARF.
Quem acompanha o assunto desde dezembro do ano passado já conhece a primeira versão dessa API, liberada em produção restrita para as empresas do piloto da CBS.
Nessa nova documentação, a Receita reescreveu a lógica da consulta e ampliou bastante o escopo de serviços. O ponto que mais interessa para quem escreve código é este: as consultas passam a ser incrementais.
Vou explicar o que isso significa na prática, quais serviços entram no ar em cada mês e o que muda para quem tem sistema com módulo fiscal rodando.
O que são as novas APIs de apuração da CBS?
As APIs de apuração da CBS são interfaces gratuitas da Receita Federal que entregam, em formato legível por máquina, os valores de débito, crédito, pagamento e recolhimento de CBS apurados pelo próprio fisco para um contribuinte.
Elas fazem parte da apuração assistida, o modelo em que a Receita calcula o tributo a partir dos documentos fiscais emitidos e devolve a conta pronta para conferência.
A ideia por trás disso é reduzir o trabalho de fechamento mensal. Em vez de a empresa calcular tudo por conta própria e torcer para bater com o que o fisco entende, ela puxa os números apurados pela Receita e compara com a base interna antes do vencimento.
Segundo a Receita, a nova documentação atende a sugestões da classe contábil, de empresas de software e de contribuintes com alto volume de transações.
Faz sentido, porque os três grupos convivem com o mesmo gargalo: arquivo grande, processamento lento e nenhuma forma fácil de saber o que mudou desde ontem.
A mudança central: consulta incremental
Na versão anterior, cada consulta devolvia o conjunto de dados do período. Se a sua aplicação consultava todo dia, todo dia ela baixava a mesma massa de informação de novo, gastando tempo de processamento para descobrir sozinha quais registros eram inéditos.
Agora as requisições receberam uma nova inteligência, e retornam apenas o que foi incluído ou atualizado entre a consulta atual e a anterior. A cada chamada, a API informa as novas transações e as atualizações de transações passadas.
Para uma empresa com algumas dezenas de notas por mês, isso pode parecer irrelevante. Mas para um marketplace, um SaaS com milhares de assinaturas ativas ou um e-commerce que emite em volume, a diferença aparece na primeira semana de uso.
O arquivo encolhe, a automação termina mais rápido e a reconciliação vira um diff de verdade em vez de uma varredura completa.
Vale registrar uma consequência prática desse desenho: a sua aplicação passa a ser responsável por manter o estado. Se uma consulta falhar e ninguém tratar o erro, o delta daquele intervalo não volta sozinho na chamada seguinte com a mesma clareza.
Com isso, controle de log e reprocessamento passam a ser obrigatórios.
Os seis serviços e o cronograma até novembro
A documentação já está publicada em no portal da receita federal, e a liberação acontece em três ondas, nos ambientes de produção restrita (o piloto da CBS) e produção beta.
Início de outubro de 2026
Consultar débitos e consultar créditos de CBS. São os dois lados da apuração, e o de créditos conversa direto com a lógica de crédito de IBS e CBS na não cumulatividade plena.
Início de novembro de 2026
Consultar pagamentos e consultar recolhimentos como adquirente. O serviço de pagamentos cobre três origens: o pagamento feito pelo próprio contribuinte, o recolhimento feito pelos seus adquirentes e o valor retido via split payment.
Final de novembro de 2026
Emitir DARF para recolhimento como adquirente (RAD) e emitir DARF para pagamento do contribuinte (PCONT). Aqui a API deixa de ser só leitura e passa a gerar documento de arrecadação.
Existe ainda um serviço de apoio, o de consulta da situação da solicitação, que permite acompanhar o processamento de cada chamada.
Fluxo assíncrono com webhook
Este é o detalhe que muda a arquitetura de quem for integrar. A documentação traz uma página inteira de regras comuns para as APIs assíncronas, cobrindo fluxo, webhook, segurança e restrições.
Assíncrono quer dizer que a sua aplicação não recebe os dados na resposta da requisição. Ela abre uma solicitação, recebe um identificador e depois consulta a situação daquele processamento ou espera a Receita avisar via webhook que o resultado ficou pronto.
Quem já integrou com a SEFAZ conhece bem esse padrão, a emissão NF-e no geral é assim. Para quem está chegando agora, vindo de APIs REST síncronas de gateway de pagamento, vai precisar prever fila, retry e endpoint público para receber a notificação. Não dá para tratar como um simples GET dentro do controller.
A parte de pagamentos, aliás, é onde essa estrutura fica mais interessante. Como o split payment retém o tributo no momento da liquidação financeira, o valor chega à Receita por um caminho que não passa pelo seu backend. A API de pagamentos é justamente o que permite enxergar esse dinheiro de volta e fechar a conta.
O que isso significa para quem mantém software fiscal?
Se você desenvolve um ERP, um SaaS com módulo fiscal ou uma ferramenta de conciliação, essa documentação é um mapa do que vai ser cobrado de você em 2027.
Três movimentos me parecem razoáveis agora:
- Ler a especificação antes de outubro. Os endpoints de débito e crédito são os primeiros, e é neles que a modelagem de dados se define.
- Desenhar o armazenamento pensando em delta. Guardar o timestamp da última consulta bem-sucedida por contribuinte deixa de ser detalhe e vira chave da integração.
- Separar leitura de arrecadação. A emissão de DARF que chega no fim de novembro tem implicação financeira, e misturar isso com rotina de consulta costuma dar dor de cabeça em auditoria.
Muito cuidado com uma coisa: apuração assistida não transfere a responsabilidade do cálculo para a Receita. O número que a API devolve é o que o fisco entendeu a partir dos documentos que você emitiu. Se a nota saiu com classificação errada, a apuração vem errada e a divergência continua sendo sua.
O que ainda não está claro
Preciso ser honesto sobre os limites do que dá para afirmar hoje.
A notícia e a documentação tratam da disponibilização em produção restrita e produção beta. Não encontrei uma definição pública de quando esses serviços chegam para o contribuinte fora do piloto, nem os limites de requisição por CNPJ.
Também não dá para dizer com segurança se o processo de geração de credencial continua igual ao da versão de dezembro, que era feito no Portal do Piloto RTC-CBS pelo serviço “Gerar Credencial para API”. Se você for integrar, confirme isso direto na documentação da Receita antes.
Como esse cronograma envolve três datas em dois meses, é o tipo de coisa que pode mudar. Vale acompanhar as publicações oficiais.
Automatizar a emissão de NF-e é 90% do caminho
Consultar o resultado da apuração assistida é só uma ponta do problema. O principal é garantir que as notas fiscais que alimentam essa apuração sejam emitidas corretamente, no volume e na velocidade que a operação dos seus clientes exigem, sem que o seu time precise manter e atualizar a integração com SEFAZ e prefeitura.
A Spedy API conecta seu ERP, SaaS ou plataforma à emissão fiscal automatizada com o melhor custo-benefício do mercado. Sem taxa de setup, preço fixo conforme seu volume, suporte à NF-e, NFS-e e NFC-e sem dor de cabeça.
Perguntas frequentes
As APIs de apuração da CBS são pagas?
Não. A Receita Federal informa que o acesso é gratuito, assim como era na versão anterior liberada em dezembro de 2025.
Preciso usar essas APIs para apurar a CBS?
Não há indicação de obrigatoriedade. Elas são um canal de consulta e conferência. A obrigação segue sendo emitir os documentos fiscais corretamente e recolher o tributo devido.
Qual a diferença entre RAD e PCONT?
RAD é o DARF para recolhimento na condição de adquirente, quando quem compra é responsável por recolher. PCONT é o DARF para pagamento do próprio contribuinte sobre seus débitos.
Quando os serviços entram no ar?
Débitos e créditos no início de outubro de 2026, pagamentos e recolhimentos no início de novembro, e a emissão dos dois DARFs no final de novembro.
