Tag: Integração Fiscal

A integração fiscal não termina quando o sistema envia uma requisição. Nas APIs assíncronas da apuração da Contribuição sobre Bens e Serviços (CBS), a abertura de uma consulta inicia um processo que pode ser concluído mais tarde, com um arquivo de retorno obtido em etapa própria. Essa distinção é importante para quem mantém ERPs em Delphi e para profissionais contábeis que dependem da consistência dos dados recebidos pelo sistema.

Em 14 de outubro de 2026, a Receita Federal registrou a versão 1.1 das Regras Comuns de Solicitação e Retorno das APIs assíncronas. A revisão atualizou o conteúdo da notificação enviada ao webhook e o fluxo de obtenção e download do arquivo de retorno por meio de urlAssinada. Não se trata, portanto, de apenas trocar uma URL: a implementação precisa separar claramente a abertura, o acompanhamento, a autorização temporária de download e a leitura do arquivo.

Este artigo percorre o fluxo confirmado na documentação oficial, explica seus efeitos operacionais, delimita o que vale especificamente para débitos e créditos e propõe um roteiro de implementação e testes. Também aponta divergências entre páginas oficiais que merecem tratamento defensivo no código.

Este roteiro complementa o guia de integração da apuração assistida ao ERP. Para contextualizar a evolução dos ambientes, consulte também o anúncio inicial das APIs da CBS; os contratos a implementar são os da documentação oficial atual, não os de versões anteriores.

Uma devolução pode estar corretamente calculada e, ainda assim, carregar uma referência insuficiente para o autorizador. Se o ERP guarda apenas a chave da nota original no cabeçalho, falta uma informação importante para o novo fluxo: qual item daquele documento está sendo devolvido em cada linha da NF-e atual.

A NT 2025.002 reúne adequações da Nota Fiscal Eletrônica para a reforma tributária, incluindo o Imposto sobre Bens e Serviços (IBS) e a Contribuição sobre Bens e Serviços (CBS). Entretanto, implementar sua versão 1.52 não significa refazer indistintamente todas as funcionalidades previstas desde 2025. O histórico dessa revisão destaca a correção da regra VC02-50 e a mudança de prazo da VC02-14, ambas relevantes para devoluções.

O roteiro deste artigo concentra-se nessas alterações e nas regras próximas necessárias para implementá-las. Vamos acompanhar o vínculo entre os itens, a geração do grupo DFeReferenciado, as verificações de emitente e destinatário e os testes que ajudam a diagnosticar rejeições. A conferência documental considera as versões 1.51 e 1.52 e o comunicado posterior de cronograma, consultados em 14 de outubro de 2026.

Imagine que a equipe já tenha revisado os cálculos tributários do sistema de gestão empresarial (ERP). Mesmo assim, ao adaptar o emissor, surgem outras perguntas: onde gravar os novos valores, em que posição gerar cada elemento XML, quando um grupo pode aparecer e qual rejeição deve ser evitada. Essas decisões pertencem ao contrato técnico do documento fiscal.

A NT 2026.008 acrescenta informações de valor líquido e de ICMS previsto no pagamento antecipado à Nota Fiscal Eletrônica (NF-e) e à Nota Fiscal de Consumidor Eletrônica (NFC-e), com diferenças de aplicação entre os modelos. O trabalho envolve persistência, geração do XML, totalização e testes. Atualizar apenas a tela ou o componente de emissão não garante que todas essas partes continuem coerentes.

Este artigo trata dessas adaptações, sem desenvolver fórmulas de formação ou decomposição de preços. A análise foi conferida em 14 de outubro de 2026, usando a versão 1.00 disponível no catálogo consultado. Datas posteriores são previsões documentais; antes de liberar uma atualização do emissor, é necessário reconferir versão, pacote de esquemas e cronograma aplicável.

A chegada de IBS e CBS à rotina das empresas do Simples Nacional cria uma decisão operacional que não deve ser confundida com a própria permanência no regime: a escolha de apurar esses dois tributos pelo regime regular. Para o primeiro semestre de 2027, a opção tem prazo até 30 de outubro de 2026 e, quando realizada, produz efeitos a partir de 1º de janeiro de 2027, conforme orientação oficial da Receita Federal.

Para profissionais de contabilidade, o tema exige organização de informações, comunicação clara com o cliente e uma decisão documentada. Para desenvolvedores Delphi e equipes responsáveis por sistemas fiscais, ele pede atenção à separação de fluxos: a empresa pode continuar no Simples Nacional, mas passar a tratar IBS e CBS fora do Documento de Arrecadação do Simples Nacional (DAS). Isso afeta cadastros, regras de cálculo, telas de parametrização, relatórios, integrações e rotinas de conferência.

Este artigo percorre a base da opção, diferencia os dois procedimentos que frequentemente se confundem, apresenta o calendário confirmado, delimita o que se sabe sobre cancelamento e propõe uma preparação prática. O objetivo não é indicar qual modelo é economicamente melhor para cada empresa: essa conclusão depende de simulação e de elementos específicos da operação que as fontes disponíveis não permitem generalizar.

Uma integração pode transmitir uma mensagem sem conseguir registrar o evento fiscal pretendido. Também pode montar um XML aparentemente coerente com uma tabela e descobrir, na validação, que o esquema publicado exige outro nome de campo. Na manifestação do adquirente da NFS-e Via, esses dois problemas merecem atenção antes de escrever a rotina de envio.

A NT SE/CGNFS-e nº 010, versão 1.00, acrescenta a modalidade de pagamento sem cobrança e os eventos de aceite e rejeição pelo adquirente. Este artigo se concentra na implementação desses eventos: contrato XML, identificação, validação, assinatura, comunicação e acompanhamento. O objetivo é transformar a documentação em um plano técnico verificável, sem repetir a análise normativa e o calendário geral do Ato nº 7.

A conferência considera os arquivos disponíveis em 14 de outubro de 2026, incluindo o pacote de esquemas versão 1.01 atualizado. Foram executados ensaios locais de estrutura e tipos, descritos adiante. Não houve assinatura com certificado real, transmissão à API nem homologação de um XML completo.

A atualização da Nota Fiscal de Serviço eletrônica (NFS-e) para contemplar IBS e CBS não é apenas uma mudança de nomenclatura tributária. Ela alcança o contrato técnico entre emissor e ambiente nacional: tipos de dados, grupos de informação, regras de negócio, cenários de ajuste e validações. Para quem mantém um ERP em Delphi, isso significa revisar componentes de geração de XML, modelos de domínio, persistência e rotinas de integração. Para a contabilidade, significa acompanhar se o dado transmitido expressa corretamente a operação que está sendo documentada.

O marco analisado aqui é o Ato Técnico Conjunto RFB/SUFIS/CGIBS/Diretoria-Executiva nº 7, de 28 de setembro de 2026, disponibilizado pelo CGIBS em 1º de outubro de 2026. Ele aprova documentos técnicos para a NFS-e e a NFS-e Via aplicáveis à CBS e ao IBS. Este artigo percorre o que foi formalmente aprovado, as alterações técnicas confirmadas, o cronograma divulgado, a divergência documental identificada e uma forma prática de conduzir a adequação sem confundir leiaute com obrigação tributária material.

Receber uma apuração calculada pela administração tributária não elimina a necessidade de conferência. Se uma operação foi registrada incorretamente, um pagamento não foi relacionado ou um crédito não atende às condições legais, o problema pode aparecer no resultado mesmo quando o sistema apresenta um saldo pronto.

A apuração assistida da Contribuição sobre Bens e Serviços, a CBS, utiliza informações para organizar o cálculo do período. O papel do contador e da empresa muda de foco: além de produzir registros, é necessário reconciliar o que foi informado, o que chegou ao ambiente oficial e o que compõe o fechamento.

Este artigo propõe uma rotina de conferência para o regime regular, com base nas fontes consultadas em 5 de outubro de 2026. Não é um tutorial de acesso a uma conta real nem demonstra homologação de integração. O guia de 2027 apresenta a transição; aqui, o foco é como avaliar o saldo antes da confirmação.

A NFS-e Via criou um padrão nacional específico para o registro de prestações de serviços de exploração de via. Para quem desenvolve sistemas em Delphi, integra ERPs ou conduz a escrituração e a conferência fiscal de concessionárias, a novidade não se resume a mais um arquivo XML: ela conecta cadastros operacionais, identificação de passagens, valores cobrados, tributação e eventos documentais em um mesmo fluxo.

A base técnica inicial desse modelo está na Nota Técnica SE/CGNFS-e nº 006, versão 1.00, de 22 de janeiro de 2026. Ela apresenta o primeiro leiaute da NFS-e Via, disciplinando emissão em XML, transmissão ao Ambiente Nacional e validação síncrona. Mas há um ponto essencial para qualquer projeto: essa nota não deve ser lida isoladamente como fotografia definitiva do leiaute atual. A documentação oficial posterior registra ajustes pela NT 010 e lista uma versão mais recente do anexo de leiautes.

Este artigo percorre o contexto normativo, a estrutura funcional do documento, os reflexos técnicos e contábeis, as atualizações confirmadas e um roteiro concreto de adequação. A proposta é distinguir o que os documentos efetivamente estabelecem daquilo que é uma decisão de implementação ou uma inferência operacional prudente.

A atualização de um esquema XML pode parecer um ajuste pequeno quando vista apenas como uma mudança de atributo. Em uma integração fiscal, porém, um limite de cardinalidade define até onde um arquivo pode crescer sem falhar na validação estrutural. Por isso, a ampliação do maxOccurs do grupo {infoConta} em dois eventos da Declaração de Regimes Específicos (DeRE) exige atenção tanto de quem desenvolve emissores em Delphi quanto de quem responde pela consistência contábil das informações.

Em comunicado publicado em 21 de setembro de 2026, a Receita Federal do Brasil (RFB) e o Comitê Gestor do IBS (CGIBS) informaram a atualização do pacote técnico de XSD destinado à Produção Restrita — Empresas Piloto. A mudança elevou os limites do evento D-1011, Plano Geral de Contas Comentado, e do D-1101, Balancete Mensal. Os servidores desse ambiente foram atualizados na noite de 21 de setembro, e a recepção oficial de XML com os novos limites começou em 22 de setembro de 2026, conforme o comunicado da RFB no SPED.

Este artigo explica o que efetivamente mudou, separa o fato confirmado das implicações técnicas razoáveis e propõe um percurso de adequação. O ponto central é simples: o XML pode passar a comportar mais ocorrências de {infoConta} nos dois eventos indicados, mas a atualização não altera, segundo a comunicação oficial, regras de negócio, tipos de dados nem os demais campos dos leiautes.

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.

A Receita Federal publicou, em setembro de 2026, uma nova documentação técnica para as interfaces de programação de aplicações, as APIs, ligadas à apuração da Contribuição sobre Bens e Serviços (CBS). A notícia chama atenção pelos serviços de consulta a débitos, créditos, pagamentos e recolhimentos, mas a mudança mais importante para quem desenvolve ERP está na forma de integração: os dados serão entregues de maneira assíncrona e incremental, em arquivos gerados após a solicitação, e não como uma resposta completa e imediata a cada chamada.

Essa diferença parece pequena até imaginarmos a rotina de uma empresa com milhares de documentos fiscais. O ERP precisa solicitar o processamento, guardar um tíquete, receber ou recuperar o resultado, baixar um arquivo temporário, importar apenas as alterações e preservar evidências para conciliação. Neste artigo, vou explicar o que a Receita disponibilizou, como o fluxo técnico funciona e quais decisões de arquitetura evitam perda de dados, duplicidade e exposição de credenciais. O objetivo não é fornecer um conector pronto, porque credenciais e ambientes dependem do enquadramento de cada contribuinte, mas transformar a documentação oficial em um plano de implementação verificável.