Cómo crear una política de compras de SaaS en LatAm

La suscripción de SaaS salió del chat del equipo y llegó a la factura de finanzas tres meses después. Nadie mintió en el proceso. Lo que faltaba era un reglamento: quién aprueba, con qué evidencia, en qué moneda y con qué documento fiscal. Una política de compras de SaaS cierra ese hueco antes de que la renovación automática y el shadow IT hagan la cuenta solas.

¿Qué es una política de compras de SaaS y por qué la empresa LatAm la necesita?

Una política de compras de SaaS es el documento interno que define alcance, niveles de aprobación, TCO, seguridad, riesgo de proveedor, moneda, factura y renovación antes de la firma. En América Latina, el costo real del software extranjero suele subir entre 50% y 70% sobre el precio de lista; sin política, el equipo compra en el catálogo y finanzas descubre el desembolso en el cierre del mes.

El estudio ABES/IDC Mercado Brasileño de Software: Panorama y Tendencias (edición 2025) describe un mercado en el que la mayor parte del software corporativo consumido en Brasil es de origen extranjero. Ese dato no es curiosidad de mercado. Describe la rutina de quien compra: la propuesta llega en dólares, el contrato es de derecho extranjero, la factura no sirve como documento fiscal doméstico y la renovación corre en la tarjeta de alguien que ya salió de la empresa. La política no elimina la fricción. Decide, por escrito, quién carga cada parte de ella.

En la práctica, la política de compras de SaaS responde a cinco preguntas que el chat del equipo nunca responde con rigor: qué entra en el reglamento, quién decide, cuánto cuesta de verdad, con qué documentación y qué ocurre en la renovación o en la baja. El resto de este texto arma ese reglamento en pasos ejecutables, desde la perspectiva de la empresa contratante.

¿Qué prerrequisitos necesita la empresa antes de escribir la política?

Antes del primer párrafo de la política, la empresa necesita cuatro piezas mínimas: dueño nombrado del documento, mapa del gasto de SaaS en uso, definición del régimen tributario y acceso a los contratos vigentes. Sin ese paquete, el texto se vuelve manifiesto de intención. Con él, se vuelve operación que el intake puede ejecutar día a día.

Reúna el mínimo abajo antes del Paso 1:

1. Dueño nombrado. Un cargo, no un comité. CFO, head de procurement o controller con mandato escrito para publicar y revisar la política.
2. Inventario de SaaS en uso. Nombre del producto, dueño interno, valor anual, moneda, fecha de renovación, forma de pago y si existe factura fiscal doméstica.
3. Régimen tributario de la empresa. En Brasil, Lucro Real o Lucro Presumido cambia lo que la política puede prometer en crédito de PIS/COFINS. Solo Lucro Real en el régimen no acumulativo acredita 9,25% sobre la factura fiscal doméstica de entrada. Lucro Presumido no acredita factura de entrada; la ganancia operativa para ese régimen es moneda local, factura en reales, traba cambiaria y menos fricción en finanzas. Vigente en 2026: el crédito de PIS/COFINS de 9,25% en la factura doméstica vale para quien apura en el régimen no acumulativo (Lucro Real). Bajo la LC 214/2025, PIS/COFINS (inclusive Importación) se extinguen en 2027 con la CBS; el ISS se fasea de 2029 a 2032 y se extingue en 2033, sustituidos por IBS/CBS con crédito para el adquirente empresarial. La política debe prever revisión del criterio de crédito cuando la empresa migre el régimen de consumo.
4. Niveles financieros ya existentes. La política de compras de SaaS se encaja en la política general de compras. No inventa un segundo organigrama.
5. Punto de contacto de seguridad de la información y de jurídico. Aunque el volumen sea bajo, seguridad y jurídico entran en el flujo con criterios objetivos, no con veto opaco.

Empresas con menos de 15 herramientas y gasto anual por debajo de un umbral definido internamente aún necesitan política. El tamaño cambia la complejidad de los niveles, no la necesidad del reglamento. El shadow IT nace en un equipo pequeño con tarjeta corporativa suelta con la misma facilidad con que nace en una multinacional.

¿Cómo armar la política de compras de SaaS en ocho pasos?

El método tiene ocho pasos: delimitar alcance, fijar RACI y niveles, clasificar riesgo de proveedor, exigir TCO antes de la aprobación, definir el mínimo de seguridad, decidir moneda y factura, elegir la ruta de contratación y cerrar renovación y offboarding. Cada paso produce un artefacto. Al final, la política es el conjunto de esos artefactos firmado por la dirección.

Paso 1: Delimitar el alcance de lo que gobierna la política

El alcance define qué contrataciones de software como servicio entran en el reglamento y cuáles quedan fuera. Sin frontera clara, el equipo discute si un plugin de US$ 12 al mes necesita aprobación y el CFO pierde la discusión en el detalle equivocado.

Incluya en el alcance, por defecto, cuatro clases que el intake reconoce sin debate:

• Cualquier suscripción recurrente de software en la nube, pagada con tarjeta, boleto, PIX o remesa.
• Trials que piden tarjeta o que convierten automáticamente en plan pago.
• Add-ons, seats extras y upgrades de plan dentro de un contrato ya existente cuando superan un porcentaje del valor base (por ejemplo, 15%).

Las herramientas gratuitas que procesan datos personales o datos de cliente también entran. No generan factura, pero generan riesgo de privacidad y de salida de dato sin dueño.

Excluya con criterio, no por comodidad: software on-premise con CAPEX propio puede seguir la política de activo; servicios profesionales puntuales sin login continuo pueden seguir la política de servicios. La prueba práctica: si hay renovación automática o seats nominales, entra.

Publique el alcance en una página. Los equipos que no saben si la compra “cuenta” inventan atajos.

Paso 2: Fijar RACI y niveles de aprobación

RACI y niveles transforman “alguien de finance tiene que ver” en nombres, valores y plazos. La política de compras de SaaS muere cuando la aprobación depende de quién está en línea en Slack.

Defina cuatro roles mínimos:

Niveles en franjas, no en excepciones. Un diseño común en mid-market LatAm:

1. Hasta US$ 3.000 al año o equivalente en moneda local: gestor del área + registro en el inventario.
2. De US$ 3.000 a US$ 25.000 al año: procurement o finance + seguridad (checklist corto).
3. Por encima de US$ 25.000 al año o dato sensible (PII, pago, salud, menor): comité lean (finance + seguridad + jurídico) con plazo máximo de cinco días hábiles.

El número exacto es de la empresa. Lo que la política no puede dejar abierto es el techo sin dueño y el plazo sin reloj. Un pedido parado se vuelve compra en tarjeta personal “solo por ahora”.

Paso 3: Clasificar el riesgo de proveedor antes del precio

El riesgo de proveedor viene antes del descuento. Un precio bajo con cláusula de lock-in, sin DPA y con soporte solo en huso estadounidense a las 3 h de la madrugada del equipo local no es ahorro. Es cuenta aplazada.

Monte una grilla simple de riesgo con cuatro ejes y puntuación objetiva:

1. Concentración y continuidad. ¿El proveedor es único en el proceso crítico? ¿Existe plan B documentado?
2. Datos. ¿Qué datos entran en la herramienta? ¿Dónde quedan? ¿Hay subprocesadores?
3. Contrato. Derecho aplicable, foro, SLA, derecho de auditoría, salida de datos en formato legible, aviso de cambio de precio.
4. Salud comercial. Tiempo de mercado, historial de incidentes públicos, dependencia de un único producto.

Los ISVs (Independent Software Vendors, empresas de software que venden su producto a otras empresas) entran en esa grilla del mismo modo que las grandes plataformas. El tamaño del logo no sustituye el DPA. Para compra cross-border, sume un quinto eje: capacidad de emitir documentación fiscal utilizable en el país de la contratante, o de operar vía ruta local que entregue esa documentación.

La política fija el piso: riesgo alto exige mitigación escrita (alcance reducido de datos, SSO obligatorio, cláusula de salida, seguro cibernético del proveedor cuando aplique) antes del nivel financiero.

El precio no compra excepción de riesgo.

Paso 4: Convertir el TCO en criterio de aprobación, no en slide opcional

El TCO (costo total de propiedad) deja de ser planilla de finance y se vuelve campo obligatorio del pedido. La política no enseña a calcular cada alícuota línea a línea; exige que el número presentado al nivel sea el desembolso real, no el precio de lista, y que el solicitante sepa qué ruta de contratación sostiene ese número.

En el pedido, el solicitante o finance completa, como mínimo, el bloque abajo. Tres campos abren la conversación; el resto cierra el desembolso:

• Precio de lista anual y moneda original.
• Asientos, mínimo contractual y política de overage.
• Estimación de tipo de cambio y spread cuando el cobro es en moneda extranjera.

Cuando haya remesa al exterior en Brasil en la ruta directa del contratante, la cuenta de TCO debe prever, en la clasificación estándar de SaaS como servicio técnico, al menos IRRF, CIDE (10%), PIS/COFINS-Importación (9,25%), ISS municipal e IOF-cambio (3,5% en la remesa de servicios/royalties); el detalle del cálculo queda en el dossier de TCO y en el artículo de costo total, no en el cuerpo de la política. La CIDE de 10% incide sobre SaaS y servicios técnicos conforme a la lectura de la Receita Federal en la SC Cosit 191/2017 y en la Ley 10.168/2000; la exención del §1°-A del art. 2º de la Ley 10.168/2000 vale solo para licencia pura de software sin transferencia de tecnología, categoría distinta de SaaS.

Sume además el costo interno de implementación, capacitación e integración, y el costo de salida (exportación de datos, overlap de herramientas en el período de transición).

El detalle del cálculo y las simulaciones por ruta están en cómo calcular el costo total de un SaaS extranjero. Aquí la regla de política es otra: sin TCO completado, no hay aprobación. Quien presenta solo el precio de catálogo devuelve el pedido.

Para empresas en Lucro Real, la política puede exigir que el TCO muestre si existe camino con factura fiscal doméstica que sustente crédito de PIS/COFINS de 9,25%. El crédito se ancla en la factura doméstica del camino local, no en el discurso genérico de “importación con crédito”. Para Lucro Presumido, la política no promete crédito; promete previsibilidad de caja y documentación en reales. En ambos regímenes, el criterio de crédito de la política debe llevar fecha de revisión alineada a la transición de la LC 214/2025 (PIS/COFINS y PIS/COFINS-Importación se extinguen en 2027 con la CBS; el ISS se fasea de 2029 a 2032).

Paso 5: Fijar el mínimo de seguridad y privacidad

La seguridad en la política de compras de SaaS es checklist binario en la puerta, no workshop después del go-live. El evaluador técnico marca sí o no. El gris se vuelve excepción documentada con plazo de remediación.

Checklist mínimo recomendado para cualquier herramienta que toque dato de cliente o dato interno no público. Los tres primeros ítems barran la mayor parte del riesgo operativo:

• SSO corporativo (SAML u OIDC) disponible en el plan cotizado, no solo en el enterprise inalcanzable.
• Provisionamiento y desprovisionamiento de usuarios (SCIM o proceso equivalente con dueño).
• DPA firmado, con subprocesadores listados y localización de datos declarada.

Los demás cierran el dossier de auditoría: cifrado en tránsito y en reposo; logs de acceso exportables o retención compatible con el plazo interno de auditoría; proceso de notificación de incidente con plazo explícito.

Herramientas de bajo riesgo (sin PII, uso individual, dato no sensible) pueden correr un checklist reducido. La política nombra quién clasifica el riesgo de datos: seguridad de la información, no el solicitante entusiasmado con el trial.

Paso 6: Decidir moneda, factura y documentación fiscal en el pedido

Moneda y factura definen si finanzas puede cerrar el mes sin cazar el PDF de la tarjeta. La política trata la documentación como criterio de compra, no como detalle postfirma, porque es en el pedido donde la ruta aún puede cambiar sin costo de salida.

Tres reglas prácticas para la empresa contratante en LatAm, con profundidad normativa en Brasil y fricción operativa en el resto de la región:

1. Preferencia por cobro en moneda local y documento fiscal local siempre que el valor y el riesgo justifiquen la ruta. En Brasil, la factura fiscal doméstica en reales cambia conciliación, auditoría y, en Lucro Real, la conversación de crédito de PIS/COFINS en la factura de entrada, con el horizonte de revisión ya previsto en la LC 214/2025.
2. Prohibición de tarjeta personal para SaaS corporativo, con excepción temporal máxima de 30 días y reembolso condicionado al registro en el inventario.
3. Remesa al exterior solo con clasificación fiscal previa cuando la ruta directa sea la elegida. En Brasil, quien paga la remesa sin dueño de la clasificación descubre en el cierre IRRF, CIDE, PIS/COFINS-Importación, ISS e IOF, según la calificación de la operación (SaaS/servicio técnico en la lectura estándar de la RFB). Fuera de Brasil, la política exige que el equipo local declare impuestos digitales y retenciones aplicables con soporte de asesoría del país; el análisis regulatorio detallado fuera del corpus brasileño queda marcado como preliminar hasta validación local.

La política no necesita ser un manual tributario. Necesita impedir la frase “la nota la vemos después”.

Paso 7: Elegir la ruta de contratación con criterios, no por hábito

La ruta (importación directa, intermediario local, canal regional) es decisión de política con trade-offs explícitos. El hábito de “siempre comprar en el sitio del proveedor” no es criterio.

Compare rutas en la mesa de aprobación con las mismas columnas:

El comparativo completo de canales está en compra directa o marketplace de software. En la política, el punto es el gatillo: por encima de un techo de TCO, o cuando haya necesidad de factura doméstica, la ruta local se vuelve estándar y la ruta directa se vuelve excepción justificada.

Cuando la política prioriza contratación local previsible, el Nexforce Marketplace entra como camino del comprador: software e IA internacionales con precio en moneda local, factura fiscal, gestión centralizada, traba cambiaria y medios regionales (PIX, boleto, parcelamento). El caso público de ConectCar, empresa del grupo Itaú, registra una reducción de cerca del 10% en los costos de software internacional en esa ruta (caso ConectCar). La política cita el camino por los atributos (factura, moneda, centralización), nunca por el margen de quien intermedia.

Paso 8: Cerrar renovación, expansión y offboarding

La renovación es donde la política de compras de SaaS prueba si es documento vivo o PDF de onboarding. El offboarding es donde el shadow IT reaparece con el login de un excolaborador.

Incluya en el reglamento:

1. Calendario de renovación con alerta a 90, 60 y 30 días para contratos por encima del nivel B.
2. Revisión de uso real (seats activos vs contratados, features activadas vs pagadas) antes de cualquier auto-renew.
3. Regla de expansión: seats y add-ons por encima de X% del contrato base reabren el flujo de nivel, incluso dentro de la vigencia.
4. Offboarding en dos puntas: RR. HH. o el gestor elimina el acceso en el IdP; procurement confirma cancelación o transferencia de ownership en el vendor y archiva evidencia.
5. Prohibición de renovación en tarjeta de persona física sin excepción.

Las empresas que solo controlan la compra inicial e ignoran la renovación pagan el precio lleno en el año dos con menos escrutinio que en el año uno. La política invierte eso: la renovación tiene el mismo rigor de la primera compra, con menos tiempo de ciclo porque el dossier ya existe.

¿Cómo verificar si la política de compras de SaaS está funcionando?

La verificación usa cuatro evidencias operativas que el controller puede leer sin interpretación creativa: inventario completo, tasa de pedidos fuera del flujo, tiempo medio de aprobación por franja de nivel y porcentaje de renovaciones con TCO revisado. Si el documento existe y la tarjeta personal aún paga una herramienta crítica, la política no operó.

Números, no narrativa.

Corra el checklist abajo 60 días después de la publicación y cada trimestre:

1. Cobertura del inventario. Meta: 100% de las herramientas con login corporativo listadas con dueño, valor y fecha de renovación.
2. Pedidos fuera del flujo. Meta declinante. Cada excepción se vuelve registro con motivo y plan de corrección, no silencio.
3. SLA de nivel. Porcentaje de pedidos decididos dentro del plazo de la franja. Un nivel lento empuja shadow IT.
4. Renovación con dossier. Contratos por encima del nivel B renovados con TCO actualizado y checklist de seguridad revalidado.
5. Offboarding muestral. Sorteo mensual de desvinculaciones: acceso SaaS eliminado en hasta 24 horas en el IdP y en el vendor.

El resultado esperado es aburrido y saludable: menos sorpresa en el cierre, menos herramienta duplicada, menos renovación automática de un producto que nadie abre hace cuatro meses. Cuando la gobernanza ya existe y el próximo corte de costo viene de la ruta de contratación y del portafolio consolidado, y no de otra ronda de regaño al shadow IT, el camino natural es reducir costos de software internacional.

¿Qué errores comunes destruyen una política de compras de SaaS?

Los errores que más destruyen la política de compras de SaaS reabren, uno a uno, el hueco que el documento prometió cerrar: alcance vago, nivel sin plazo, TCO opcional en la mesa de aprobación, seguridad después del go-live, tarjeta personal tolerada y renovación en piloto automático. Cada uno basta para devolver la compra al chat del equipo.

1. Política de 40 páginas que nadie lee. Prefiera diez páginas operables y anexos de checklist. El reglamento que no cabe en el flujo del ticket no existe.
2. Aprobación por consenso difuso. Sin RACI, todo el mundo comenta y nadie decide.

El solicitante interpreta el silencio como sí. Ese es el camino más corto entre un comentario en el ticket y una firma sin TCO.

1. Excepción permanente para la “herramienta del fundador”. Excepción sin plazo y sin dueño se vuelve segundo régimen. La política vale para el C-level o se vuelve teatro.
2. TCO solo en el slide de la dirección. Si el nivel B aprueba en el precio de lista, la dirección hereda la cuenta llena.
3. Seguridad como opinión. El checklist binario gana a “creo que está bien”. La opinión no audita.
4. Ignorar moneda y factura. Equipo feliz con el trial; finanzas infeliz con la conciliación y con la falta de documento fiscal.
5. Shadow IT tratado solo con regaño. El regaño sin camino fácil de regularización empuja la herramienta al correo personal. Ofrezca fast-track de regularización con amnistía limitada en el primer ciclo.

Tabla de etapa, evidencia y aprobador

La tabla abajo es el corazón operativo de la política de compras de SaaS: cada etapa del pedido exige una evidencia mínima y un aprobador nombrado, para que el formulario de intake y el wiki interno hablen el mismo idioma. Pegue ambos en el mismo lugar y capacite al equipo una vez.

Pegue en el wiki. Use en el intake.

Sin evidencia en la etapa, el pedido no sube de nivel. Esa regla única evita la mayor parte de las excepciones improvisadas que la dirección descubre solo en el cierre trimestral, cuando el gasto de SaaS ya está contratado y el offboarding del proveedor anterior aún no empezó.

FAQ

Antes de cerrar el reglamento, procurement y finanzas repiten las mismas dudas: dueño del documento, trials, crédito de PIS/COFINS, CIDE en la ruta directa, cadencia de revisión y SaaS ya comprado fuera del flujo. Las respuestas abajo entran en el FAQ interno de la política de compras de SaaS y evitan reabrir el debate en cada pedido.

¿Quién debe ser el dueño de la política de compras de SaaS?

El dueño es un cargo con mandato escrito de publicación y revisión: CFO, head de procurement o controller. Los comités revisan. No publican.

Sin dueño nominal, la política envejece en silencio y el shadow IT vuelve por la tarjeta corporativa de quien tiene prisa y no quiere esperar el nivel B.

¿La política necesita cubrir trials y herramientas gratuitas?

Sí, cuando hay tarjeta, conversión automática, dato personal o dato de cliente. El cobro se vuelve compra. Un trial sin tarjeta y sin dato sensible puede tener registro simplificado en el inventario, siempre que el dueño del equipo declare el plazo de fin y qué ocurre si nadie cancela antes de la conversión automática. La frontera queda escrita en el alcance.

¿Lucro Presumido se beneficia de crédito de PIS/COFINS en la compra de SaaS?

No. Lucro Presumido no acredita PIS/COFINS de factura de entrada. El beneficio operativo de la ruta con factura doméstica para ese régimen es moneda local, documentación en reales, traba cambiaria y menos fricción de conciliación. El crédito de 9,25% es conversación de Lucro Real en el régimen no acumulativo, anclada en la factura doméstica del camino local. Vigente en 2026 ese recorte; bajo la LC 214/2025, PIS/COFINS (inclusive Importación) se extinguen en 2027 con la CBS, y la política debe prever revisión del criterio de crédito en la migración del régimen de consumo.

¿La CIDE incide en la compra de SaaS del exterior?

En Brasil, la CIDE de 10% incide sobre SaaS y servicios técnicos en la lectura de la Receita Federal (SC Cosit 191/2017 y Ley 10.168/2000). La exención del §1°-A del art. 2º de la Ley 10.168/2000 se aplica exclusivamente a licencias puras de software sin transferencia de tecnología, categoría distinta de SaaS. La política de compras trata esa línea en el TCO de la ruta directa; no asume exención por default.

¿Con qué frecuencia debe revisarse la política?

Revisión formal al menos una vez al año y siempre que cambie el régimen tributario, el organigrama de niveles o el techo de gasto anual de software. Las revisiones puntuales caben cuando un incidente de seguridad o una multa expone un hueco en el flujo, y también cuando el calendario de la LC 214/2025 altere el criterio de crédito que la política promete en el TCO.

¿Qué hacer con el SaaS ya contratado fuera de la política?

Amnistía limitada en el primer ciclo: 60 a 90 días para registrar en el inventario, completar checklist y encajar en el nivel de renovación. Después de la ventana, la herramienta fuera del reglamento pierde reembolso y acceso vía IdP corporativo. Sin consecuencia, no hay regularización.

Referencias y lectura complementaria

• ABES/IDC, Mercado Brasileño de Software: Panorama y Tendencias
• Ley 10.168/2000 (CIDE), Planalto
• Ley Complementaria 214/2025 (reforma tributaria del consumo), Planalto
• Cómo calcular el costo total de un SaaS extranjero
• Compra directa o marketplace de software
• Reducir costos de software internacional
• Caso ConectCar: reducción de costos de software internacional
• Nexforce Marketplace

¿Cuál es el próximo paso después de publicar la política?

El próximo paso es operar el primer ciclo completo: publicar el reglamento, migrar el inventario en 30 días, correr el formulario de intake en todos los pedidos nuevos y medir las cuatro evidencias de verificación el día 60. Sin el ciclo medido, la política de compras de SaaS sigue siendo texto de buenas intenciones.

Las empresas que ya sienten la factura en dólares duplicarse en el camino hasta finanzas ganan velocidad cuando la ruta estándar privilegia moneda local y factura fiscal doméstica. El Nexforce Marketplace existe para ese comprador: centraliza software e IA internacionales con cobro en reales, factura fiscal, traba cambiaria y medios locales, mientras la política interna define quién pide, quién aprueba y qué ocurre en la renovación. La gobernanza es de la empresa. La ruta previsible es elección de criterio, no de improvisación en la tarjeta.