Como criar uma política de compras de SaaS na LatAm

A assinatura do SaaS saiu do chat do time e chegou na fatura do financeiro três meses depois. Ninguém mentiu no processo. O que faltava era um regimento: quem aprova, com qual evidência, em qual moeda e com qual nota. Uma política de compras de SaaS fecha esse buraco antes que a renovação automática e o shadow IT façam a conta sozinhas.

O que é uma política de compras de SaaS e por que a empresa LatAm precisa dela?

Uma política de compras de SaaS é o documento interno que define escopo, alçadas, TCO, segurança, risco de fornecedor, moeda, fatura e renovação antes da assinatura. Na América Latina, o custo real do software estrangeiro costuma subir 50% a 70% sobre o preço de lista; sem política, o time compra no catálogo e o financeiro descobre o desembolso no fechamento.

O estudo ABES/IDC Mercado Brasileiro de Software: Panorama e Tendências (edição 2025) descreve um mercado em que a maior parte do software corporativo consumido no Brasil é de origem estrangeira. Esse dado não é curiosidade de mercado. Ele descreve a rotina de quem compra: a proposta chega em dólar, o contrato é de direito estrangeiro, a fatura não serve como nota fiscal doméstica e a renovação roda no cartão de alguém que já saiu da empresa. A política não elimina a fricção. Ela decide, por escrito, quem carrega cada pedaço dela.

Na prática, a política de compras de SaaS responde a cinco perguntas que o chat do time nunca responde com rigor: o que entra no regimento, quem decide, quanto custa de verdade, com qual documentação e o que acontece na renovação ou no desligamento. O resto deste texto monta esse regimento em passos executáveis, na perspectiva da empresa contratante.

Quais pré-requisitos a empresa precisa antes de escrever a política?

Antes do primeiro parágrafo da política, a empresa precisa de quatro peças mínimas: dono nomeado do documento, mapa do gasto de SaaS em uso, definição do regime tributário e acesso aos contratos vigentes. Sem esse pacote, o texto vira manifesto de intenção. Com ele, vira operação que o intake consegue executar no dia a dia.

Reúna o mínimo abaixo antes do Passo 1:

1. Dono nomeado. Um cargo, não um comitê. CFO, head de procurement ou controller com mandato escrito para publicar e revisar a política.
2. Inventário de SaaS em uso. Nome do produto, dono interno, valor anual, moeda, data de renovação, forma de pagamento e se existe nota fiscal doméstica.
3. Regime tributário da empresa. Lucro Real ou Lucro Presumido muda o que a política pode prometer em crédito de PIS/COFINS. Só Lucro Real no regime não cumulativo credita 9,25% sobre a nota fiscal doméstica de entrada. Lucro Presumido não credita NF de entrada; o ganho operacional para esse regime é moeda local, nota em reais, trava cambial e menos fricção no financeiro. Vigente em 2026: o crédito de PIS/COFINS de 9,25% na NF doméstica vale para quem apura no regime não cumulativo (Lucro Real). Sob a LC 214/2025, PIS/COFINS (inclusive Importação) extinguem-se em 2027 com a CBS; o ISS faseia de 2029 a 2032 e extingue-se em 2033, substituídos por IBS/CBS com crédito para o adquirente empresarial. A política deve prever revisão do critério de crédito quando a empresa migrar o regime de consumo.
4. Alçadas financeiras já existentes. A política de compras de SaaS se encaixa na política geral de compras. Não inventa um segundo organograma.
5. Ponto de contato de segurança da informação e de jurídico. Mesmo que o volume seja baixo, segurança e jurídico entram no fluxo com critérios objetivos, não com veto opaco.

Empresas com menos de 15 ferramentas e gasto anual abaixo de um patamar definido internamente ainda precisam de política. O tamanho muda a complexidade das alçadas, não a necessidade do regimento. Shadow IT nasce em time pequeno com cartão corporativo solto com a mesma facilidade com que nasce em multinacional.

Como montar a política de compras de SaaS em oito passos?

O método tem oito passos: delimitar escopo, fixar RACI e alçadas, classificar risco de fornecedor, obrigar TCO antes da aprovação, definir o mínimo de segurança, decidir moeda e fatura, escolher a rota de contratação e fechar renovação e offboarding. Cada passo produz um artefato. No fim, a política é o conjunto desses artefatos assinado pela diretoria.

Passo 1: Delimitar o escopo do que a política governa

O escopo define quais contratações de software como serviço entram no regimento e quais ficam de fora. Sem fronteira clara, o time discute se um plugin de US$ 12 por mês precisa de aprovação e o CFO perde a discussão no detalhe errado.

Inclua no escopo, por padrão, quatro classes que o intake reconhece sem debate:

• Qualquer assinatura recorrente de software acessado pela nuvem, paga em cartão, boleto, PIX ou remessa.
• Trials que pedem cartão ou que convertem automaticamente em plano pago.
• Add-ons, seats extras e upgrades de plano dentro de um contrato já existente quando ultrapassam um percentual do valor base (ex.: 15%).

Ferramentas gratuitas que processam dados pessoais ou dados de cliente também entram. Elas não geram fatura, mas geram risco de privacidade e de saída de dado sem dono.

Exclua com critério, não por comodidade: software on-premise com CAPEX próprio pode seguir a política de ativo; serviços profissionais pontuais sem login contínuo podem seguir a política de serviços. O teste prático: se há renovação automática ou seats nominais, entra.

Publique o escopo em uma página. Times que não sabem se a compra “conta” inventam atalhos.

Passo 2: Fixar RACI e alçadas de aprovação

RACI e alçadas transformam “alguém do finance precisa ver” em nomes, valores e prazos. A política de compras de SaaS morre quando a aprovação depende de quem está online no Slack.

Defina quatro papéis mínimos:

Alçadas em faixas, não em exceções. Um desenho comum em mid-market LatAm:

1. Até US$ 3.000 ao ano ou equivalente em moeda local: gestor da área + registro no inventário.
2. De US$ 3.000 a US$ 25.000 ao ano: procurement ou finance + segurança (checklist curto).
3. Acima de US$ 25.000 ao ano ou dado sensível (PII, pagamento, saúde, menor): comitê lean (finance + segurança + jurídico) com prazo máximo de cinco dias úteis.

O número exato é da empresa. O que a política não pode deixar em aberto é o teto sem dono e o prazo sem relógio. Pedido parado vira compra no cartão pessoal “só por enquanto”.

Passo 3: Classificar risco de fornecedor antes do preço

Risco de fornecedor vem antes do desconto. Um preço baixo com cláusula de lock-in, sem DPA e com suporte só em fuso americano às 3h da manhã do time local não é economia. É conta adiada.

Monte uma grade simples de risco com quatro eixos e pontuação objetiva:

1. Concentração e continuidade. O fornecedor é único no processo crítico? Existe plano B documentado?
2. Dados. Quais dados entram na ferramenta? Onde ficam? Há subprocessadores?
3. Contrato. Direito aplicável, foro, SLA, direito de auditoria, saída de dados em formato legível, aviso de mudança de preço.
4. Saúde comercial. Tempo de mercado, histórico de incidentes públicos, dependência de um único produto.

ISVs (Independent Software Vendors, empresas de software que vendem seu produto para outras empresas) entram nessa grade do mesmo jeito que grandes plataformas. O porte do logo não substitui o DPA. Para compra cross-border, some um quinto eixo: capacidade de emitir documentação fiscal utilizável no país da contratante, ou de operar via rota local que entregue essa documentação.

A política fixa o piso: risco alto exige mitigação escrita (escopo reduzido de dados, SSO obrigatório, cláusula de saída, seguro cibernético do fornecedor quando aplicável) antes da alçada financeira.

Preço não compra exceção de risco.

Passo 4: Tornar o TCO critério de aprovação, não slide opcional

TCO (custo total de propriedade) deixa de ser planilha do finance e vira campo obrigatório do pedido. A política não ensina a calcular cada alíquota linha a linha; ela exige que o número apresentado à alçada seja o desembolso real, não o preço de lista, e que o solicitante saiba qual rota de contratação sustenta esse número.

No pedido, o solicitante ou o finance preenche, no mínimo, o bloco abaixo. Três campos abrem a conversa; o restante fecha o desembolso:

• Preço de lista anual e moeda original.
• Assentos, mínimo contratual e política de overage.
• Estimativa de câmbio e spread quando a cobrança é em moeda estrangeira.

Quando houver remessa ao exterior no Brasil na rota direta do contratante, a conta de TCO deve prever, na classificação padrão de SaaS como serviço técnico, ao menos IRRF, CIDE (10%), PIS/COFINS-Importação (9,25%), ISS municipal e IOF-câmbio (3,5% na remessa de serviços/royalties); o detalhe do cálculo fica no dossiê de TCO e no artigo de custo total, não no corpo da política. A CIDE de 10% incide sobre SaaS e serviços técnicos conforme a leitura da Receita Federal na SC Cosit 191/2017 e na Lei 10.168/2000; a isenção do §1°-A do art. 2º da Lei 10.168/2000 vale só para licença pura de software sem transferência de tecnologia, categoria distinta de SaaS.

Some ainda o custo interno de implementação, treinamento e integração, e o custo de saída (exportação de dados, overlap de ferramentas no período de transição).

O detalhe do cálculo e as simulações por rota estão em como calcular o custo total de SaaS estrangeiro. Aqui a regra de política é outra: sem TCO preenchido, não há aprovação. Quem apresenta só o preço de catálogo devolve o pedido.

Para empresas em Lucro Real, a política pode exigir que o TCO mostre se existe caminho com nota fiscal doméstica que sustente crédito de PIS/COFINS de 9,25%. O crédito se ancora na NF doméstica do caminho local, não no discurso genérico de “importação com crédito”. Para Lucro Presumido, a política não promete crédito; promete previsibilidade de caixa e documentação em reais. Em ambos os regimes, o critério de crédito da política deve carregar data de revisão alinhada à transição da LC 214/2025 (PIS/COFINS e PIS/COFINS-Importação extinguem-se em 2027 com a CBS; ISS faseia de 2029 a 2032).

Passo 5: Fixar o mínimo de segurança e privacidade

Segurança na política de compras de SaaS é checklist binário na porta, não workshop depois do go-live. O avaliador técnico marca sim ou não. Cinza vira exceção documentada com prazo de remediação.

Checklist mínimo recomendado para qualquer ferramenta que toque dado de cliente ou dado interno não público. Os três primeiros itens barram a maior parte do risco operacional:

• SSO corporativo (SAML ou OIDC) disponível no plano cotado, não só no enterprise inalcançável.
• Provisionamento e desprovisionamento de usuários (SCIM ou processo equivalente com dono).
• DPA assinado, com subprocessadores listados e localização de dados declarada.

Os demais fecham o dossiê de auditoria: criptografia em trânsito e em repouso; logs de acesso exportáveis ou retenção compatível com o prazo interno de auditoria; processo de notificação de incidente com prazo explícito.

Ferramentas de baixo risco (sem PII, uso individual, dado não sensível) podem rodar um checklist reduzido. A política nomeia quem classifica o risco de dados: segurança da informação, não o solicitante animado com o trial.

Passo 6: Decidir moeda, fatura e documentação fiscal no pedido

Moeda e fatura definem se o financeiro consegue fechar o mês sem caça ao PDF do cartão. A política trata documentação como critério de compra, não como detalhe pós-assinatura, porque é no pedido que a rota ainda pode mudar sem custo de saída.

Três regras práticas para a empresa contratante na LatAm, com profundidade normativa no Brasil e fricção operacional no restante da região:

1. Preferência por cobrança em moeda local e documento fiscal local sempre que o valor e o risco justificarem a rota. No Brasil, nota fiscal doméstica em reais muda conciliação, auditoria e, no Lucro Real, a conversa de crédito de PIS/COFINS na NF de entrada, com o horizonte de revisão já previsto na LC 214/2025.
2. Proibição de cartão pessoal para SaaS corporativo, com exceção temporária máxima de 30 dias e reembolso condicionado ao registro no inventário.
3. Remessa ao exterior só com classificação fiscal prévia quando a rota direta for a escolhida. No Brasil, quem paga a remessa sem dono da classificação descobre no fechamento IRRF, CIDE, PIS/COFINS-Importação, ISS e IOF, conforme a qualificação da operação (SaaS/serviço técnico na leitura padrão da RFB). Fora do Brasil, a política exige que o time local declare impostos digitais e retenções aplicáveis com suporte de assessoria do país; análise regulatória detalhada fora do corpus brasileiro fica marcada como preliminar até validação local.

A política não precisa ser um manual tributário. Precisa impedir a frase “a gente vê a nota depois”.

Passo 7: Escolher a rota de contratação com critérios, não por hábito

A rota (importação direta, intermediário local, canal regional) é decisão de política com trade-offs explícitos. O hábito de “sempre comprar no site do fornecedor” não é critério.

Compare rotas na mesa de aprovação com as mesmas colunas:

O comparativo completo de canais está em compra direta ou marketplace de software. Na política, o ponto é o gatilho: acima de um teto de TCO, ou quando houver necessidade de NF doméstica, a rota local vira padrão e a rota direta vira exceção justificada.

Quando a política prioriza contratação local previsível, o Nexforce Marketplace entra como caminho do comprador: software e IA internacionais com preço em moeda local, nota fiscal, gestão centralizada, trava cambial e meios regionais (PIX, boleto, parcelamento). O caso público da ConectCar, empresa do grupo Itaú, registra redução de cerca de 10% nos custos de software internacional nessa rota (case ConectCar). A política cita o caminho pelos atributos (NF, moeda, centralização), nunca pela margem de quem intermedia.

Passo 8: Fechar renovação, expansão e offboarding

Renovação é onde a política de compras de SaaS prova se é documento vivo ou PDF de onboarding. Offboarding é onde o shadow IT reaparece com login de ex-colaborador.

Inclua no regimento:

1. Calendário de renovação com alerta em 90, 60 e 30 dias para contratos acima da alçada B.
2. Revisão de uso real (seats ativos vs contratados, features ligadas vs pagas) antes de qualquer auto-renew.
3. Regra de expansão: seats e add-ons acima de X% do contrato base reabrem o fluxo de alçada, mesmo dentro da vigência.
4. Offboarding em duas pontas: RH ou gestor remove acesso no IdP; procurement confirma cancelamento ou transferência de ownership no vendor e arquiva evidência.
5. Proibição de renovação em cartão de pessoa física sem exceção.

Empresas que só controlam a compra inicial e ignoram a renovação pagam o preço cheio no ano dois com menos escrutínio do que no ano um. A política inverte isso: renovação tem o mesmo rigor da primeira compra, com menos tempo de ciclo porque o dossiê já existe.

Como verificar se a política de compras de SaaS está funcionando?

A verificação usa quatro evidências operacionais que o controller consegue ler sem interpretação criativa: inventário completo, taxa de pedidos fora do fluxo, tempo médio de aprovação por faixa de alçada e percentual de renovações com TCO revisado. Se o documento existe e o cartão pessoal ainda paga ferramenta crítica, a política não operou.

Números, não narrativa.

Rode o checklist abaixo 60 dias após a publicação e a cada trimestre:

1. Cobertura do inventário. Meta: 100% das ferramentas com login corporativo listadas com dono, valor e data de renovação.
2. Pedidos fora do fluxo. Meta declinante. Cada exceção vira registro com motivo e plano de correção, não silêncio.
3. SLA de alçada. Percentual de pedidos decididos dentro do prazo da faixa. Alçada lenta empurra shadow IT.
4. Renovação com dossiê. Contratos acima da alçada B renovados com TCO atualizado e checklist de segurança revalidado.
5. Offboarding amostral. Sorteio mensal de desligamentos: acesso SaaS removido em até 24 horas no IdP e no vendor.

O resultado esperado é chato e saudável: menos surpresa no fechamento, menos ferramenta duplicada, menos renovação automática de produto que ninguém abre há quatro meses. Quando a governança já existe e o próximo corte de custo vem da rota de contratação e do portfólio consolidado, e não de mais uma rodada de bronca no shadow IT, o caminho natural é reduzir custos de software internacional.

Quais erros comuns destroem uma política de compras de SaaS?

Os erros que mais destroem a política de compras de SaaS reabrem, um a um, o buraco que o documento prometeu fechar: escopo vago, alçada sem prazo, TCO opcional na mesa de aprovação, segurança depois do go-live, cartão pessoal tolerado e renovação no piloto automático. Cada um basta para devolver a compra ao chat do time.

1. Política de 40 páginas que ninguém lê. Prefira dez páginas operáveis e anexos de checklist. O regimento que não cabe no fluxo do ticket não existe.
2. Aprovação por consenso difuso. Sem RACI, todo mundo comenta e ninguém decide.

O solicitante interpreta silêncio como sim. Esse é o caminho mais curto entre um comentário no ticket e uma assinatura sem TCO.

1. Exceção permanente para “ferramenta do fundador”. Exceção sem prazo e sem dono vira segundo regime. A política ou vale para o C-level ou vira teatro.
2. TCO só no slide da diretoria. Se a alçada B aprova no preço de lista, a diretoria herda a conta cheia.
3. Segurança como opinião. Checklist binário vence “acho que está ok”. Opinião não audita.
4. Ignorar moeda e nota. Time feliz com o trial; financeiro infeliz com a reconciliação e com a falta de documento fiscal.
5. Shadow IT tratado só com bronca. Bronca sem caminho fácil de regularização empurra a ferramenta para o e-mail pessoal. Ofereça fast-track de regularização com anistia limitada no primeiro ciclo.

Tabela de estágio, evidência e aprovador

A tabela abaixo é o coração operacional da política de compras de SaaS: cada estágio do pedido exige uma evidência mínima e um aprovador nomeado, para que o formulário de intake e o wiki interno falem a mesma língua. Cole os dois no mesmo lugar e treine o time uma vez.

Cole no wiki. Use no intake.

Sem evidência no estágio, o pedido não sobe de alçada. Essa regra única evita a maior parte das exceções improvisadas que a diretoria descobre só no fechamento trimestral, quando o gasto de SaaS já está contratado e o offboarding do fornecedor antigo ainda não começou.

FAQ

Antes de fechar o regimento, procurement e financeiro repetem as mesmas dúvidas: dono do documento, trials, crédito de PIS/COFINS, CIDE na rota direta, cadência de revisão e SaaS já comprado fora do fluxo. As respostas abaixo entram no FAQ interno da política de compras de SaaS e evitam reabrir o debate a cada pedido.

Quem deve ser o dono da política de compras de SaaS?

O dono é um cargo com mandato escrito de publicação e revisão: CFO, head de procurement ou controller. Comitês revisam. Não publicam.

Sem dono nominal, a política envelhece em silêncio e o shadow IT volta pelo cartão corporativo de quem tem pressa e não quer esperar a alçada B.

A política precisa cobrir trials e ferramentas gratuitas?

Sim, quando há cartão, conversão automática, dado pessoal ou dado de cliente. Cobrança vira compra. Trial sem cartão e sem dado sensível pode ter registro simplificado no inventário, desde que o dono do time declare o prazo de fim e o que acontece se ninguém cancelar antes da conversão automática. A fronteira fica escrita no escopo.

Lucro Presumido se beneficia de crédito de PIS/COFINS na compra de SaaS?

Não. Lucro Presumido não credita PIS/COFINS de NF de entrada. O benefício operacional da rota com nota doméstica para esse regime é moeda local, documentação em reais, trava cambial e menos fricção de conciliação. Crédito de 9,25% é conversa de Lucro Real no regime não cumulativo, ancorada na NF doméstica do caminho local. Vigente em 2026 esse recorte; sob a LC 214/2025, PIS/COFINS (inclusive Importação) extinguem-se em 2027 com a CBS, e a política deve prever revisão do critério de crédito na migração do regime de consumo.

A CIDE incide na compra de SaaS do exterior?

No Brasil, a CIDE de 10% incide sobre SaaS e serviços técnicos na leitura da Receita Federal (SC Cosit 191/2017 e Lei 10.168/2000). A isenção do §1°-A do art. 2º da Lei 10.168/2000 aplica-se exclusivamente a licenças puras de software sem transferência de tecnologia, categoria distinta de SaaS. A política de compras trata essa linha no TCO da rota direta; não assume isenção por default.

Com que frequência a política deve ser revisada?

Revisão formal ao menos uma vez por ano e sempre que mudar regime tributário, organograma de alçadas ou o teto de gasto anual de software. Revisões pontuais cabem quando um incidente de segurança ou uma multa expõe um buraco no fluxo, e também quando o calendário da LC 214/2025 alterar o critério de crédito que a política promete no TCO.

O que fazer com o SaaS já contratado fora da política?

Anistia limitada no primeiro ciclo: 60 a 90 dias para registrar no inventário, completar checklist e encaixar na alçada de renovação. Depois da janela, ferramenta fora do regimento perde reembolso e acesso via IdP corporativo. Sem consequência, não há regularização.

Referências e Leitura Complementar

• ABES/IDC, Mercado Brasileiro de Software: Panorama e Tendências
• Lei 10.168/2000 (CIDE), Planalto
• Lei Complementar 214/2025 (reforma tributária do consumo), Planalto
• Como calcular o custo total de SaaS estrangeiro
• Compra direta ou marketplace de software
• Reduzir custos de software internacional
• Case ConectCar: redução de custos de software internacional
• Nexforce Marketplace

Qual o próximo passo depois de publicar a política?

O próximo passo é operar o primeiro ciclo completo: publicar o regimento, migrar o inventário em 30 dias, rodar o formulário de intake em todos os pedidos novos e medir as quatro evidências de verificação no dia 60. Sem o ciclo medido, a política de compras de SaaS continua sendo texto de boas intenções.

Empresas que já sentem a fatura em dólar dobrar no caminho até o financeiro ganham velocidade quando a rota padrão privilegia moeda local e nota fiscal doméstica. O Nexforce Marketplace existe para esse comprador: centraliza software e IA internacionais com cobrança em reais, NF, trava cambial e meios locais, enquanto a política interna define quem pede, quem aprova e o que acontece na renovação. A governança é da empresa. A rota previsível é escolha de critério, não de improviso no cartão.