O IBS da fibra mora no endereço do terminal, não no CNPJ que paga a fatura

A Reforma Tributária decidiu, para banda larga por fibra e demais serviços de comunicação por cabos, fios e meios similares, que o local da operação não é onde o contrato foi assinado, nem onde a fatura chega. É o local de instalação do terminal. Isso parece um detalhe técnico de regulamento. Na prática, transforma um campo de cadastro que a maioria das operadoras trata como dado operacional comum em um dado que decide, nota a nota, qual ente federativo recebe o IBS.

A regra do local da operação para fibra

O art. 11, inciso IX, da LC 214 é direto: no serviço de telefonia fixa e demais serviços de comunicação prestados por meio de cabos, fios, fibras e meios similares, o local da operação é o local de instalação do terminal. Essa definição importa porque o IBS, como tributo de destino, precisa de uma regra clara sobre onde a operação "acontece" para fins fiscais, especialmente num serviço que não tem um ponto de venda físico único como um estabelecimento comercial.

Para quem presta serviço de conectividade por fibra, essa regra significa que o endereço físico onde o equipamento do cliente foi instalado, não o endereço de cobrança, não o endereço da sede do cliente, é o que determina o município e, por consequência, o ente que tem direito à arrecadação daquela operação específica.

O terminal decide. O CNPJ que assina o contrato só participa da conversa depois.

Essa regra tem uma lógica clara por trás: diferente de um produto físico, que viaja fisicamente até o ponto de entrega, um serviço de conectividade por fibra é consumido continuamente num ponto fixo da rede. O legislador escolheu ancorar o IBS nesse ponto fixo, exatamente porque ele é o único elemento verdadeiramente estável e verificável na relação entre operadora e cliente, mais estável até do que o endereço de cobrança, que pode mudar por decisão puramente administrativa do cliente sem nenhuma alteração no serviço efetivamente prestado.

Vale notar que a mesma lógica de local de instalação já existia, em espírito, na forma como ICMS sobre comunicação costumava tratar a prestação de serviço continuado. A diferença agora é que o IBS exige essa informação explícita e estruturada em campo próprio do documento fiscal, em vez de depender de regras de apuração internas que cada operadora desenvolvia por conta própria para cumprir a legislação estadual anterior.

Pessoa física, pessoa jurídica e compra centralizada

A regra se desdobra de forma diferente conforme o tipo de cliente. Para uma pessoa física, o local de instalação do terminal costuma coincidir naturalmente com o endereço residencial onde o serviço é consumido. A complexidade cresce no segmento corporativo.

A própria LC 214 prevê, no §3º, inciso I, alínea b, que para pessoas jurídicas e entidades sem personalidade jurídica o local da operação é o de cada estabelecimento para o qual o serviço é fornecido. Isso significa que um cliente corporativo com múltiplas filiais atendidas pelo mesmo contrato de conectividade gera, em tese, uma operação distinta por estabelecimento, cada uma com seu próprio local de instalação e, potencialmente, seu próprio município de destino do IBS.

Há uma exceção relevante a essa regra geral, introduzida pela LC 227 de 2026: o §4º do mesmo artigo estabelece que, em caso de compra centralizada, o local da operação passa a ser o domicílio principal do adquirente, não o de cada estabelecimento individualmente atendido. Essa distinção entre compra descentralizada por filial e compra centralizada pela matriz não é um detalhe irrelevante: ela muda completamente qual município recebe o IBS de um contrato corporativo com múltiplas unidades.

Duas rotas legais, duas respostas diferentes. A mesma rede de filiais pode gerar municípios de destino completamente distintos.

Decidir se um contrato é compra centralizada ou não é questão contratual e comercial, não decisão de sistema. O que o sistema precisa fazer é registrar, com rastreabilidade, qual das duas situações se aplica a cada contrato, e aplicar a regra correta de local da operação de forma consistente a cada nota emitida para aquele cliente. Isso exige um campo de classificação explícito no cadastro do contrato, não uma inferência feita na hora da emissão da nota a partir de outros dados que não foram desenhados para essa finalidade.

Na ausência desse campo explícito, o padrão mais comum é o sistema assumir, por omissão, que todo contrato segue a regra padrão de local por estabelecimento, simplesmente porque é o caminho de menor resistência técnica. Isso pode estar certo para a maioria dos contratos e errado justamente para os de maior porte, onde a compra centralizada costuma ser mais frequente e onde o volume de receita envolvido também é maior.

Um ponto adicional que costuma passar despercebido é a renegociação contratual. Um contrato que começou descentralizado, com faturamento e pagamento por filial, pode ser renegociado ao longo do tempo para um modelo de compra centralizada, sem que essa mudança de modelo comercial dispare, automaticamente, a atualização da regra de local da operação usada na emissão fiscal. Se o campo de classificação não for revisado no momento da renegociação, o sistema continua aplicando a regra antiga sobre um contrato que juridicamente já mudou de categoria.

Onde vive o endereço de instalação

Aqui está o ponto cego mais comum. Em operadoras de telecomunicações, o endereço de instalação do terminal costuma viver no BSS, o sistema de suporte ao negócio que gerencia provisionamento, ordens de serviço e dados técnicos da planta instalada, ou no faturador especializado que emite as contas de consumo. Raramente esse dado nasce ou é mantido dentro do SAP.

O SAP, por sua vez, tipicamente guarda o endereço de cobrança e o endereço cadastral do cliente, que servem para emissão de boleto, correspondência e dados fiscais tradicionais. Quando esses dois sistemas não estão rigorosamente sincronizados campo a campo, existe uma divergência estrutural entre o endereço que o SAP conhece e o endereço onde o serviço de fato é consumido.

Essa divergência é especialmente provável em dois cenários: contratos B2B, onde o endereço de cobrança da matriz frequentemente difere do endereço de instalação em cada filial atendida, e produtos de serviço de valor agregado vendidos em conjunto com a conectividade, onde o cadastro comercial pode ter sido criado sob uma lógica de produto, não sob uma lógica de local de consumo.

Dois sistemas, duas verdades de endereço. A nota fiscal só pode carregar uma.

O risco não é apenas de classificação incorreta de ente federativo. A própria LC 214 prevê, no art. 11, §6º, a possibilidade de diferença exigível do adquirente quando o endereço informado resulta em pagamento a menor do imposto devido. Isso muda a natureza da conversa em contratos corporativos: um endereço de instalação mal registrado não é só um problema de rastreabilidade fiscal interna, é um ponto que pode gerar cobrança complementar ao cliente depois que a nota já foi emitida e o serviço já foi prestado.

Há ainda um cenário intermediário que raramente aparece nas discussões sobre o tema: a mudança de endereço de instalação depois que o contrato já está ativo. Quando um cliente corporativo muda uma filial de endereço, ou quando um cliente residencial muda de residência levando o mesmo contrato de conectividade, o BSS precisa atualizar o ponto de instalação, e essa atualização precisa necessariamente chegar ao SAP antes da próxima nota ser emitida. Se o fluxo de atualização entre os dois sistemas tiver qualquer atraso ou falha, a nota seguinte sai com o local da operação antigo, mesmo que o serviço já esteja sendo consumido em outro município.

O que a Nota Técnica 2026.004 exige do documento

A Nota Técnica 2026.004 da NFCom, aprovada em 29 de setembro de 2026, estabelece as regras da Reforma Tributária aplicadas especificamente a esse documento fiscal: alterações no schema XML, novas tags e regras de validação, e um grupo de totalização próprio para IBS e CBS, reunindo base de cálculo, devoluções, diferimentos e alíquotas efetivas. Isso significa que o documento fiscal da fibra agora carrega, estruturalmente, a granularidade necessária para refletir o local da operação determinado pela lei.

O documento está pronto para carregar o dado correto. A pergunta que fica em aberto é se o cadastro de origem, no BSS ou no faturador, está entregando esse dado correto ao SAP, ou se a integração entre os dois sistemas ainda assume que endereço de cobrança e local de instalação são a mesma coisa.

Granularidade por cliente, linha, serviço e município não é luxo técnico: é o que o novo modelo de documento exige. Sem isso, o layout está certo e o conteúdo, errado.

Um schema XML corretamente atualizado não valida, por si só, se o valor preenchido em cada tag de município é o correto. A validação de formato garante que a nota será aceita pelo ambiente nacional. Ela não garante que o ente federativo nela indicado é, de fato, o titular daquela arrecadação segundo a regra de local da operação. Essas são duas camadas de conformidade diferentes, e tratar a primeira como se resolvesse a segunda é um engano comum na corrida para adequar sistemas ao novo leiaute.

Vale lembrar que o grupo de totalização de IBS e CBS da NT 2026.004 soma valores por tributo e por alíquota efetiva, mas essa soma é calculada em cima do município que o sistema já determinou como local da operação. Se o município de origem estiver errado, o grupo de totalização simplesmente consolida o erro com precisão técnica impecável. O schema não tem como, sozinho, detectar que o dado de entrada estava equivocado.

Teste de qualidade do cadastro por amostra

Antes de assumir que a integração entre BSS, faturador e SAP já reflete corretamente a regra do local de instalação, vale rodar um teste simples: selecionar uma amostra de contratos corporativos com múltiplas filiais atendidas e comparar, campo a campo, o endereço de instalação registrado no sistema de provisionamento contra o endereço usado para determinar o local da operação na nota fiscal emitida. Se os dois coincidirem em todos os casos da amostra, é sinal de que a integração está íntegra. Se divergirem em qualquer proporção relevante, a extensão real do problema só aparece quando a amostra é expandida para a base completa de contratos ativos.

Esse teste deve separar, desde o início, os contratos marcados como compra centralizada dos demais, porque a regra correta de local muda entre os dois grupos. Testar os dois grupos com o mesmo critério de validação produz falso positivo num lado e falso negativo no outro.

Vale também incluir na amostra os contratos que sofreram mudança de endereço de instalação nos últimos meses, porque é justamente nesse subconjunto que o atraso de sincronização entre BSS e SAP tende a se manifestar primeiro. Um contrato estável, sem mudança recente, tem menos chance de expor o problema mesmo quando a integração entre sistemas tem falhas estruturais, simplesmente porque o dado nunca precisou ser atualizado desde a configuração inicial.

A amostra também deve capturar contratos recém-renegociados de descentralizado para centralizado, ou o inverso, exatamente pelo motivo descrito antes: é nesse ponto de transição contratual que o campo de classificação tem mais chance de ficar desatualizado em relação à realidade jurídica do contrato vigente.

A pergunta que decide se essa amostra deve virar auditoria completa é simples de formular: quando o endereço do contrato, o de cobrança e o do terminal divergem numa mesma conta corporativa, qual deles está, hoje, sustentando o campo de local da operação na NFCom, e onde, no ambiente de sistemas, essa decisão foi tomada? Enquanto essa pergunta não tiver resposta documentada, o risco de local da operação errado permanece invisível até o primeiro cruzamento externo de dados expor o padrão.