No fechamento da Contribuição sobre Bens e Serviços (CBS), uma empresa pode ter diante de si duas versões do mesmo registro. De um lado, o documento e seus reflexos tributários no sistema de gestão empresarial. Do outro, os débitos, créditos e, nas etapas correspondentes, os pagamentos apresentados pelos serviços da Receita Federal.
Na primeira consulta, as informações podem coincidir. Depois, uma nova consulta pode devolver uma atualização de um crédito já conhecido. Se o sistema procurar apenas registros que nunca apareceram antes, essa mudança não chegará à equipe fiscal. O dado estará na consulta da Receita, mas o fechamento interno continuará baseado na versão anterior.
Por isso, no fechamento da CBS, não basta o sistema de gestão empresarial — o ERP — importar uma vez os dados da Receita e, nas rodadas seguintes, procurar somente registros novos. Neste artigo, apuração assistida é o fluxo em que fiscal, contabilidade e financeiro comparam documentos, débitos, créditos e pagamentos internos com os registros apresentados pelos serviços da Receita. Como as novas interfaces de programação de aplicações, as APIs, foram anunciadas com consultas incrementais, o ERP também precisa reconhecer alterações em registros já consultados e encaminhá-las para nova conciliação. O cronograma de outubro e novembro de 2026 trata da disponibilização gradual em Produção Restrita, usada no Piloto da CBS, e Produção Beta — não de uma implantação universal, de produção plena ou do Imposto sobre Bens e Serviços (IBS).
O que é apuração assistida neste fluxo da CBS?
A Receita disponibiliza serviços para consulta dos dados relacionados à apuração da CBS. A API funciona como a ligação pela qual o sistema da empresa se comunica com esses serviços. O ERP recebe os retornos e os organiza para que as áreas responsáveis possam compará-los com os documentos e controles internos.
Essa sequência tem quatro participantes com papéis diferentes:
a Receita Federal apresenta os dados por meio dos serviços de consulta;
a API permite a comunicação entre esses serviços e o sistema da empresa;
o ERP recebe, identifica e organiza os registros;
fiscal, contabilidade e financeiro verificam se o conteúdo recebido corresponde às operações, aos controles tributários e às liquidações registradas pela empresa.
Essa é uma definição operacional de apuração assistida para o recorte deste artigo. A consulta fornece informações para a conferência, mas não significa que toda correspondência esteja automaticamente confirmada ou que um ajuste produza, por si só, determinado efeito jurídico.
O ponto decisivo é outro: o saldo só pode ser considerado seguro internamente depois que as diferenças relevantes forem compreendidas. Se o ERP mostra determinado crédito e a consulta posterior da Receita apresenta outra versão do mesmo registro, a simples existência da divergência não prova quem está certo. Ela mostra que ainda não há base para validar o fechamento sem investigar o que mudou.
Esse mecanismo afeta diretamente empresas e escritórios contábeis que integram dados tributários e precisam coordenar tecnologia, fiscal, contabilidade, financeiro e fornecedores de ERP. Quem não opera uma integração também precisa compreender a lógica da conferência, mas o foco aqui é a preparação das equipes responsáveis por receber e tratar os retornos das APIs.
A consequência prática orienta todo o trabalho: se uma alteração devolvida pela Receita não entrar no controle interno, a consulta oficial e o ERP passam a exibir versões diferentes do mesmo fechamento. A divergência pode ter explicações distintas, mas não deve desaparecer sem tratamento.
A consulta incremental não traz somente documentos inéditos
A mudança central anunciada pela Receita está no modo de consulta. Segundo a notícia oficial publicada em 14 de setembro de 2026, cada requisição incremental retorna as alterações ocorridas desde a última consulta realizada pelo usuário.
Isso significa que o sistema não precisa receber novamente toda a carga a cada chamada. Ele recebe o que mudou no intervalo entre uma consulta e outra.
É útil visualizar a consulta incremental como um histórico de revisões, e não como uma pasta que recebe apenas arquivos inéditos. Uma revisão pode acrescentar algo que não existia, mas também pode apresentar uma nova versão de algo que já havia sido visto. A comparação ajuda a compreender a relação entre as consultas; ela não descreve a estrutura técnica das respostas, dos campos ou dos dados transmitidos pela Receita.
A distinção que importa para a conciliação é esta:
Um retorno incremental pode trazer tanto um registro incluído quanto uma atualização de um registro consultado anteriormente.
O índice oficial da documentação da apuração da CBS torna essa diferença concreta ao descrever a consulta de créditos em operações de consumo como um serviço que retorna créditos incluídos ou atualizados entre as consultas.
“ incluído” e “atualizado” não são duas formas de dizer a mesma coisa. Um registro incluído aparece pela primeira vez. Um registro atualizado já era conhecido, mas voltou porque alguma informação mudou.
Considere um exemplo hipotético. Um documento já está registrado no ERP e, na primeira consulta, determinado crédito é associado a ele. Em uma consulta posterior, a Receita devolve uma atualização desse mesmo registro, sem que o exemplo presuma a causa da mudança.
Se a integração filtrar apenas identificadores nunca vistos, entenderá que não há nada novo a processar. O fiscal continuará trabalhando com o conteúdo da primeira consulta. Se o ERP reconhecer que um registro conhecido foi atualizado, poderá reabrir o item e encaminhá-lo novamente à conciliação.
O exemplo mostra por que novidade e alteração exigem tratamentos diferentes. A primeira cria um item no fluxo; a segunda devolve ao fluxo um item que poderia estar aparentemente encerrado.
Para que isso funcione, os testes do ERP precisam verificar três capacidades operacionais:
Reconhecer inclusões e atualizações: o sistema deve perceber tanto o surgimento de um registro quanto a mudança de um registro conhecido.
Preservar o histórico necessário: a equipe precisa conseguir identificar que houve alteração depois da consulta anterior.
Reabrir a conferência: o registro alterado deve voltar à fila de conciliação, em vez de ficar apenas guardado em um log técnico.
Esses são requisitos operacionais recomendados, não especificações técnicas oficiais. Autenticação, campos, endpoints, conteúdo das respostas e demais detalhes de integração devem seguir os guias específicos de cada serviço.
Na conversa com o fornecedor do ERP, quatro perguntas ajudam a transformar a ideia em critérios de aceitação:
O sistema distingue um registro novo de um registro atualizado?
Uma atualização reabre automaticamente a conciliação?
A equipe consegue identificar o que mudou depois da consulta anterior?
A divergência permanece visível até ser analisada e encerrada?
Se a resposta for “não” para qualquer uma delas, a integração pode até estar recebendo dados, mas ainda não sustenta uma conferência segura.
O cronograma de outubro e novembro não é um calendário de produção plena
Depois de definir o que o ERP deve reconhecer, é preciso separar quando testar de onde testar.
A atualização da Receita publicada em 14 de setembro de 2026 anunciou a disponibilização gradual das APIs nos ambientes de Produção Restrita, usado no Piloto da CBS, e Produção Beta. O cronograma separa os serviços em três momentos.
A tabela abaixo permite distinguir o serviço anunciado, o período previsto, o ambiente indicado e o teste que a empresa pode preparar.
Serviço anunciado | Momento previsto | Ambiente informado pela Receita | Preparação correspondente |
|---|---|---|---|
Consultas de débitos e créditos | Início de outubro de 2026 | Produção Restrita/Piloto da CBS e Produção Beta, conforme a disponibilidade confirmada para o serviço | Testar a associação com documentos e o tratamento de inclusões e atualizações |
Consultas de pagamentos e de recolhimentos realizados pelo adquirente | Início de novembro de 2026 | Mesmos ambientes anunciados, mediante confirmação da disponibilidade | Preparar a conciliação financeira dos pagamentos e recolhimentos |
Emissão de Documento de Arrecadação de Receitas Federais (DARF) para Recolhimento pelo Adquirente (RAD) e para Pagamento do Contribuinte (PCONT) | Final de novembro de 2026 | Mesmos ambientes anunciados, mediante confirmação da disponibilidade | Testar a relação entre apuração, pagamento e documento de arrecadação |
Em 1º de outubro de 2026, o marco anunciado como “início de outubro” está começando. Isso não transforma a previsão em confirmação automática de que todos os serviços estejam ativos, nos dois ambientes, para todos os participantes. Antes de executar um teste, a equipe deve verificar na documentação oficial qual consulta está disponível e em qual ambiente.
A diferença parece apenas terminológica, mas muda a conclusão. Um cronograma anunciado informa o que a Receita planejou disponibilizar. A confirmação no ambiente mostra o que pode efetivamente ser testado naquele momento. Nenhum dos dois, isoladamente, autoriza tratar o serviço como produção plena.
Também é preciso conservar três limites:
O cronograma citado trata das APIs da CBS, não do IBS;
Produção Restrita e Produção Beta não significam implantação universal;
As datas não antecipam obrigação, efeito jurídico ou comportamento que a documentação específica não tenha descrito.
O calendário, portanto, deve orientar a preparação dos testes — não servir como atalho para conclusões sobre a aplicação definitiva do novo modelo.
O teste precisa seguir o documento até o pagamento
Saber que um serviço está disponível não basta para testar um fechamento. A conferência precisa acompanhar o mesmo fato ao longo do caminho: documento, débito, crédito e, quando os serviços correspondentes estiverem disponíveis, pagamento, recolhimento e DARF.
Um roteiro operacional pode seguir esta sequência:
Localizar o documento nos registros internos.
A equipe identifica no ERP qual operação está sendo confrontada e quais informações internas sustentam a conferência.
Verificar o débito relacionado consultado na Receita.
O objetivo é conferir se o registro consultado pode ser associado ao documento analisado e se há diferença de valor, situação ou vínculo que precise ser investigada.
Verificar se o crédito correspondente foi incluído ou atualizado.
A equipe não procura apenas a existência do crédito. Também verifica se aquele registro já havia aparecido e retornou com alguma alteração.
Conciliar pagamento ou recolhimento realizado pelo adquirente.
Esta etapa entra no teste quando os respectivos serviços estiverem disponíveis. O financeiro compara o retorno consultado com a liquidação registrada internamente.
Relacionar o DARF aplicável ao fluxo.
Na etapa prevista para os serviços de emissão, a empresa verifica a ligação entre a apuração, o pagamento e o documento de arrecadação pertinente.
Esse checklist é uma recomendação de controle, não o leiaute oficial de uma API. Sua utilidade não está em marcar que cada registro existe, mas em descobrir em qual ligação a informação deixou de coincidir.
Um documento pode estar corretamente registrado no ERP enquanto o crédito relacionado ainda exige análise. Da mesma forma, um pagamento pode constar no financeiro sem estar relacionado ao registro tributário que a equipe está conferindo. Ver os dois registros separadamente não demonstra que a conciliação foi concluída.
Quando valor, situação ou vínculo não coincidir, a diferença deve permanecer identificada. Isso evita três conclusões prematuras: presumir que houve erro da Receita, presumir que houve erro da empresa ou considerar automaticamente que determinado crédito é devido. A primeira tarefa é descobrir a origem da diferença e registrar o tratamento dado a ela.
Voltemos à empresa hipotética. Uma consulta posterior atualiza o crédito já conhecido. O ERP reabre o item. O fiscal compara o novo retorno com o documento; a contabilidade verifica o reflexo no controle da apuração; se a mudança alcançar a liquidação, o financeiro confere o pagamento ou recolhimento relacionado.
A atualização, portanto, não deve terminar no histórico da integração. Ela precisa percorrer novamente as áreas afetadas. Um log prova que o sistema recebeu alguma coisa; a conciliação mostra que a empresa entendeu o efeito da mudança sobre seu fechamento.
Quando o crédito estiver relacionado ao estoque, a qualidade do dado de origem também entra na conferência; o guia sobre crédito de CBS sobre estoques e a preparação do inventário de 2026 aprofunda esse caso específico sem substituir a conciliação das consultas.
A conciliação de pagamentos é uma etapa do fechamento; o acompanhamento da certidão negativa federal e da regularidade fiscal é um controle mais amplo e não deve ser confundido com a validação isolada de um registro devolvido pela API.
Quem cuida de cada parte da conciliação?
A API não é um assunto exclusivo da tecnologia. Ao mesmo tempo, as áreas tributárias não devem receber a responsabilidade de resolver sozinhas questões técnicas da integração.
Uma matriz operacional ajuda a delimitar quem identifica, quem analisa e quem decide o encaminhamento de cada diferença:
Área | Responsabilidade recomendada | Evidência que deve produzir ou preservar |
|---|---|---|
Tecnologia ou fornecedor do ERP | Manter a integração, reconhecer inclusões e atualizações e preservar o histórico das consultas | Registro de recebimento, identificação da mudança e reabertura da conciliação |
Fiscal | Relacionar documentos, débitos e créditos e analisar as diferenças tributárias | Resultado da conferência e justificativa do tratamento |
Contabilidade | Avaliar o reflexo da diferença nos controles da apuração | Registro do efeito considerado no fechamento |
Financeiro | Conciliar pagamentos e recolhimentos quando esses serviços estiverem disponíveis | Correspondência ou divergência entre o retorno consultado e a liquidação interna |
Gestão | Definir responsáveis, escalonamento e condições internas para encerrar divergências | Responsável final, decisão registrada e pendências ainda abertas |
Essa divisão existe porque cada área enxerga uma parte diferente do problema. A tecnologia consegue identificar que um registro mudou, mas não deve presumir sozinha o significado tributário da alteração. Fiscal e contabilidade analisam o conteúdo e o reflexo na apuração. O financeiro verifica se a liquidação interna corresponde ao pagamento ou recolhimento consultado.
A gestão fecha a lacuna entre essas funções. Sem um responsável definido, a divergência pode circular entre áreas: a TI diz que a integração funcionou, o fiscal aguarda uma explicação contábil, a contabilidade pede a confirmação financeira e ninguém registra por que o item foi encerrado.
No exemplo que acompanhamos, a tecnologia registra que o crédito foi atualizado. O fiscal verifica a relação com o documento. A contabilidade analisa o reflexo no controle tributário. O financeiro participa se houver impacto na conciliação da liquidação. A gestão define quem documentará a conclusão e em que condição o item poderá deixar a lista de pendências.
Para escritórios contábeis, a mesma lógica precisa ser adaptada à carteira. Convém identificar quem acompanha cada cliente, quem mantém contato com o fornecedor do ERP e onde ficam registradas as divergências abertas. Não se trata de uma obrigação oficial, mas de uma forma de impedir que uma atualização técnica fique sem análise tributária.
Encerrar a análise não significa afirmar que consultar, confirmar ou ajustar um registro produziu automaticamente determinado efeito jurídico. A conclusão operacional é mais precisa: a empresa deve documentar o que recebeu, como comparou a informação e por que considerou a divergência resolvida.
A validação segura depende de levar cada mudança à conciliação
A preparação pode ser avaliada por quatro perguntas:
O serviço e o ambiente foram confirmados na documentação oficial?
O ERP reconheceu tanto a inclusão quanto a atualização de registros?
A mudança percorreu todas as etapas e áreas afetadas?
As divergências continuam identificadas até que sua origem e seu tratamento sejam documentados?
Se alguma resposta for negativa, ainda existe uma lacuna. O sistema pode estar conectado, mas a empresa não concluiu a preparação necessária para confiar no fluxo de conferência.
Não basta trazer o que entrou: o fechamento também precisa conferir tudo o que mudou. O ganho não está em acumular retornos da API, e sim em impedir que uma atualização fique fora da apuração interna.
Os testes devem acompanhar a disponibilização gradual dos serviços. Produção Restrita, Piloto da CBS e Produção Beta permitem preparar processos e identificar falhas, mas não autorizam conclusões sobre obrigação universal, produção plena ou IBS.
Se a empresa precisa transformar essa conferência em requisitos para fiscal, contabilidade, financeiro e tecnologia, a Scott pode apoiar o diagnóstico e a preparação para a Reforma Tributária, acompanhando a implementação com a equipe interna ou o fornecedor do ERP.
Fontes consultadas
Como apuramos este conteúdo
Pergunta de partida. Apuração assistida: como preparar fiscal e ERP para as APIs da CBS
Critério das fontes. Partimos de normas, decisões e publicações oficiais lidas na íntegra. Cada afirmação sustentada por fonte traz o endereço consultado; interpretações nossas aparecem identificadas como análise, não como texto de lei.
Fontes oficiais consultadas.
Órgão público federal: Receita Federal publica nova documentação técnica das APIs de apuração da CBS — Receita Federal
Órgão público federal: Documentação da apuração CBS
Referências complementares.
scottgroup.com.br: Apuração Assistida na Reforma Tributária: o que muda para empresas
scottgroup.com.br: Reforma Tributária — Scott
Autoria e revisão. Redação e responsabilidade técnica: Leonardo Douradinho Tonchis — OAB/SP 491.827 · Advogado tributarista e especialista em direito fiscal · Revisão técnica: Bernardo Platner Sandri — Especialista técnico · Última revisão do conteúdo: 01/10/2026.
Limite deste conteúdo. É material informativo e não substitui a análise do seu caso concreto, que depende de documentos, prazos e do histórico fiscal específico.