Respuesta ejecutiva
Una clave de reparto distribuye costos comunes entre receptores cuando no existe trazabilidad directa suficiente. Debe aproximar de manera razonable el beneficio esperado por cada entidad, utilizar datos controlados y permitir que otra persona reproduzca el cálculo. No es defendible por ser común, sencilla o histórica; ingresos, headcount y activos son posibles indicadores, no respuestas universales.
La selección ocurre después de definir el servicio, probar beneficio y depurar la base. Una clave perfecta aplicada a costos de accionista, servicios no prestados o duplicidades sólo distribuye con precisión un cargo improcedente. Asimismo, el porcentaje asignado no determina el precio completo: deben analizarse base, costos pass-through, margen, moneda, ajustes y condiciones.
El proceso recomendable tiene seis pasos: segmentar servicios, identificar el impulsor de beneficio, evaluar una medida directa, seleccionar una aproximación, probar datos y resultados, y documentar gobierno. Cuando los servicios tienen impulsores distintos, deben separarse o usar claves múltiples claramente conciliadas.
Principio de correspondencia
La pregunta central es: ¿qué variable cambia aproximadamente en la misma dirección que el beneficio o consumo del servicio? Para nómina puede ser empleados procesados; para soporte tecnológico, usuarios, dispositivos o tickets; para cuentas por pagar, facturas o transacciones; para compras, gasto gestionado; para tesorería, saldos, deuda o transacciones; para espacio, metros cuadrados.
El indicador no necesita medir valor económico con precisión científica. Sí debe tener una relación explicable y estable. Use información disponible cuando sea confiable, pero no sacrifique correspondencia únicamente por comodidad. Si una medida ideal no existe, explique por qué el proxy elegido es mejor que alternativas razonables.
La clave debe definirse ex ante, antes de conocer qué entidad recibe el mayor cargo. Elegir retrospectivamente la variable que minimiza la asignación mexicana genera sesgo. Mantenga una política de selección, criterios de cambio y aprobaciones.
Selector estático de claves
| Familia | Impulsor esperado | Clave primaria posible | Alternativa | Riesgo de mala aplicación |
|---|---|---|---|---|
| Recursos humanos | población atendida | empleados/FTE | movimientos de nómina | incluir personal no cubierto |
| Nómina | procesamiento | recibos o empleados procesados | horas | ignorar complejidad por país |
| TI de usuario | acceso/soporte | usuarios o dispositivos | tickets ponderados | contar licencias inactivas |
| Infraestructura TI | capacidad | consumo, almacenamiento, CPU | usuarios | capacidad reservada no medida |
| Cuentas por pagar | volumen | facturas procesadas | proveedores | mezclar facturas complejas y simples |
| Compras | gasto gestionado | órdenes o spend | ahorros | atribuir gasto no gestionado |
| Tesorería | fondos/riesgo | saldos, deuda, transacciones | activos | no separar cash pool y préstamos |
| Legal | asunto/tiempo | horas o expedientes | ingresos | cargar litigios de una entidad a todas |
| Cumplimiento | obligación/riesgo | horas o entidades cubiertas | ingresos | confundir gobierno accionista |
| Mercadotecnia | mercado/campaña | gasto, usuarios o ventas vinculadas | ingresos | asumir beneficio uniforme |
| Instalaciones | ocupación | metros cuadrados | headcount | omitir áreas exclusivas |
| Dirección general | beneficio mixto | clave compuesta justificada | ingresos | usar ingresos por defecto |
La tabla es un punto de partida. La conducta y el alcance contractual deciden. Por ejemplo, usuarios puede ser mejor para una aplicación, pero capacidad consumida para nube. “TI” no debe ser una sola bolsa si reúne ambos modelos.
Trazabilidad directa antes del reparto
Los costos atribuibles a un receptor deben asignarse directamente cuando los sistemas lo permiten. Un proyecto exclusivo de México no debe distribuirse globalmente y regresar sólo en proporción a ingresos. La trazabilidad directa reduce subsidios cruzados y mejora evidencia.
Defina campos obligatorios: proyecto, cliente interno, centro de costo, orden, ticket o código. Capacite al prestador para registrarlos al incurrir el costo, no meses después. Revise muestras y tasas de “sin asignar”. Un sistema sofisticado pierde valor si el equipo usa categorías genéricas.
El resto forma el pool común. Explique la frontera entre directo e indirecto. Un empleado puede registrar horas directas y dejar supervisión general en común. Evite doble conteo: un costo asignado directamente no debe permanecer en el pool.
Construir y depurar la base
Empiece con una población conciliada a la balanza del prestador. Identifique cuentas, centros, entidades, moneda y periodo. Excluya accionista, duplicados, costos sin servicio y partidas fuera de alcance. Separe pass-through y costos sobre los que procede margen conforme al análisis funcional.
Los costos negativos, recuperaciones y provisiones requieren reglas. Determine si reducen la base, pertenecen a otro periodo o representan ajustes. Documente capitalizaciones, depreciación, bonos, viajes e impuestos. La consistencia interanual importa, pero una política histórica incorrecta debe corregirse con explicación.
Si varias entidades participan en la prestación, mapee capas. Un centro regional puede recibir un cargo global y añadir costos propios. Conserve el rastro desde la cuenta original hasta el receptor final y evite aplicar márgenes sucesivos sin analizar valor añadido.
Calidad de datos
Una clave defendible necesita fuente autorizada, definición, propietario, fecha de extracción, periodo, moneda si aplica, controles y evidencia de integridad. “Headcount enviado por RH” no basta si no se sabe si representa promedio, cierre, FTE, contratistas o todos los empleados.
Use denominadores comparables. Si México reporta promedio anual y otras entidades cierre, el porcentaje se distorsiona. Documente entidades sin datos, nuevas, vendidas o inactivas. No asigne automáticamente cero: un receptor nuevo puede consumir muchos servicios aunque tenga pocos ingresos.
Concilie el total con reportes operativos o financieros. Controle duplicados, valores nulos y cambios bruscos. Un dashboard puede alertar desviaciones, pero el archivo fuente y transformación deben conservarse. Versione fórmulas y bloquee celdas críticas.
Claves simples, múltiples y compuestas
Una clave simple funciona cuando el servicio es homogéneo y un impulsor domina. Es transparente y fácil de operar. Una clave múltiple usa distintas variables para componentes separados; por ejemplo, TI por usuarios y cuentas por facturas. Requiere segmentar costos antes de distribuir.
Una clave compuesta pondera variables dentro del mismo servicio, como 50% usuarios, 30% tickets y 20% dispositivos. Puede representar mejor el beneficio, pero añade juicio y riesgo de manipulación. Justifique cada peso con análisis, no con el resultado deseado. Pruebe sensibilidad.
No confunda sofisticación con calidad. Si la información es débil, una fórmula compleja amplifica errores. Prefiera el modelo más sencillo que conserve una relación razonable y pueda operarse regularmente.
Si una sola clave de ingresos reparte RH, TI, legal y tesorería, conviene segmentar la base y comparar impulsores antes del próximo cargo.
Pruebas de razonabilidad
Revise resultados absolutos y relativos. ¿Una entidad sin empleados recibe RH? ¿Una entidad con sistema propio recibe TI global completo? ¿México absorbe un salto por devaluación o por cambio real de consumo? Compare contra año anterior, presupuesto, uso y explicaciones operativas.
Calcule sensibilidad con una o dos alternativas razonables. No se busca seleccionar el menor cargo, sino comprender cuánto depende el resultado del juicio. Una diferencia material exige documentación y quizá mejores datos.
Analice beneficiarios excluidos. Si una entidad recibió entregables pero quedó fuera del denominador, las demás subsidian su costo. Revise entidades con resultado cero, valores extremos y claves manuales. Obtenga confirmación de dueños locales.
Pruebe que el total asignado reconcilia exactamente con el pool, antes del margen y después de ajustes. Explique redondeos y moneda. El control debe permitir recorrer en ambos sentidos: factura a cuenta original y cuenta a facturas.
Expediente de la clave
| Documento | Contenido mínimo | Dueño |
|---|---|---|
| Política | servicios, método, frecuencia, excepciones | fiscal/TP |
| Catálogo | alcance y receptores | negocio |
| Puente de costos | balanza a pool depurado | finanzas prestador |
| Memorando de selección | impulsor, alternativas y conclusión | TP |
| Diccionario de datos | definición, fuente y periodo | data owner |
| Extracción | archivo original y fecha | sistemas/finanzas |
| Cálculo | fórmulas, denominador, porcentajes | contraloría |
| Pruebas | variaciones, extremos y sensibilidad | fiscal |
| Aprobación | responsables y excepciones | comité |
| Conciliación | cálculo a factura, póliza y pago | contabilidad |
Conserve versiones. El archivo final sin datos fuente ni decisiones no permite reproducir el cálculo. Evite enlaces rotos a carpetas personales.
Cambios y ajustes de cierre
La clave puede estimarse durante el año y actualizarse con datos reales. La política debe indicar periodicidad, umbral y tratamiento del true-up. Un ajuste no debe sorprender a receptores ni cambiar retrospectivamente la lógica para alcanzar un margen objetivo.
Los cambios de negocio exigen revisión: adquisición, venta, migración de ERP, centralización, automatización, nueva plataforma o cambio de alcance. Distinga cambio metodológico de actualización de datos. El primero necesita justificación y aprobación; la segunda sigue la política.
Al cierre, concilie población, pool, clave, margen, facturas y contabilidad. Determine efectos fiscales y documentales del ajuste. Conserve tanto estimaciones como resultados reales y explique diferencias.
Errores frecuentes
- Usar ingresos para todos los servicios.
- Elegir la clave después de observar el resultado.
- Repartir costos directos en un pool común.
- Mantener entidades no beneficiarias en el denominador.
- Excluir beneficiarios porque carecen de datos.
- Mezclar headcount de cierre y promedio.
- No separar costos de accionista o duplicados.
- Aplicar margen sobre toda partida sin análisis.
- Usar fórmulas complejas sin control de fuente.
- Cambiar la clave cada año sin explicación.
- No reconciliar el total a facturas y balanza.
- Documentar sólo porcentajes, no beneficio.
Implementación práctica
Durante la primera semana, catalogue servicios y mapee centros de costo. En la segunda, depure la base e identifique medidas directas. En la tercera, evalúe claves, calidad de datos y sensibilidad. En la cuarta, apruebe política, ejecute un cálculo piloto y concilie a registros.
Asigne un dueño de servicio y otro de datos. El primero valida beneficio; el segundo integridad de la variable. Fiscal y precios de transferencia revisan clasificación y metodología. Contabilidad opera factura y ajuste. Jurídico verifica que el contrato describa la asignación.
El objetivo no es diseñar una fórmula eterna. Es crear un control repetible que cambie cuando cambian los hechos y conserve el historial suficiente para explicar cada factura.
Documente también el tratamiento de errores. Si una entidad reportó un dato incorrecto, conserve la extracción original, la corrección, la aprobación y el efecto en facturas. La trazabilidad de una corrección razonable fortalece el control; sobrescribir silenciosamente el archivo lo debilita.
Fuentes y fecha de corte
Contenido verificado al 2 de agosto de 2026. Consulte la LISR vigente, el perfil OCDE de México y las Guías OCDE 2022. La selección debe adaptarse a hechos, ley mexicana y obligaciones aplicables; la tabla no establece una clave obligatoria.
Un Allocation Key Review de Zugzwang revisa catálogo, base, impulsores, fuentes, sensibilidad y conciliación para convertir una prorrata histórica en un cálculo reproducible y explicable.