De todos los módulos de un ERP, la nómina es el que peor viaja. Un catálogo de productos funciona igual en San Salvador que en Lisboa; una nómina no. Depende de porcentajes de seguridad social, de tablas de retención, de cómo se calcula la indemnización y de qué formato pide el instituto para el envío mensual.
Por eso conviene separar dos cosas que se suelen mezclar.
Lo que sí es genérico
El motor de nómina —el mecanismo que toma unas entradas y produce un recibo— es igual en todas partes, y los proyectos libres lo tienen resuelto:
- Contratos y estructuras salariales: quién cobra qué, cada cuánto, con qué complementos.
- Reglas de cálculo encadenadas: una regla produce un importe que otra usa como base.
- Entradas variables: horas extra, comisiones, ausencias, anticipos.
- Generación del recibo y su envío al empleado.
- Asientos contables automáticos a la contabilidad, que es la mitad del valor.
Ese último punto es el que a menudo justifica el módulo por sí solo. Si la nómina la lleva una gestoría externa, alguien acaba tecleando el asiento resumen a mano cada mes. Con el módulo integrado, el asiento sale solo y cuadrado, como pasa con el resto del circuito que describimos en del presupuesto a la factura sin teclear dos veces.
Lo que hay que localizar
Y aquí está el trabajo real:
- Los porcentajes y topes de cotización, que cambian con cierta frecuencia.
- La tabla de retención del impuesto sobre la renta y su forma de aplicarse.
- Los conceptos propios del país: aguinaldo, vacación proporcional, indemnización, días de asueto.
- Los ficheros de envío a los institutos, cada uno con su formato.
Para algunos países existe una localización mantenida por la comunidad o por un partner. Para otros no, y entonces hay que construirla. No es imposible —son reglas de cálculo, no magia— pero es un proyecto con nombre y presupuesto, no una casilla que se activa.
La pregunta que hay que hacer antes de nada: ¿existe localización de nómina para mi país, quién la mantiene y cuándo la actualizó por última vez? Si la respuesta es «hay un módulo en GitHub de hace tres años», eso no es una localización, es un punto de partida.
El error de mantener las reglas a mano
Una tentación frecuente: en lugar de instalar una localización, alguien teclea las reglas de cálculo directamente en el sistema, con los porcentajes de este año escritos dentro.
Funciona. Hasta que cambia un porcentaje y nadie se acuerda de dónde estaba escrito, o la persona que lo montó ya no está. Una nómina mal calculada no es un error contable cualquiera: se paga mal a alguien, y eso tiene consecuencias legales y humanas.
Si se hace así, que sea con dos condiciones: las tasas en parámetros con fecha de vigencia, nunca dentro de la fórmula, y una persona con nombre responsable de revisarlas cada año.
Cuándo seguir externalizando
Externalizar la nómina no es rendirse. Tiene una ventaja difícil de replicar: la gestoría asume parte de la responsabilidad de que el cálculo esté bien y sigue los cambios normativos como parte de su trabajo.
Seguir externalizando tiene sentido si la plantilla es pequeña, si no hay localización disponible, o si nadie dentro puede asumir el seguimiento normativo. Lo que sí conviene hacer en todos los casos es llevar los datos de personal internamente —contratos, ausencias, variables— y enviar a la gestoría lo que necesita, en lugar de que los datos vivan en su sistema. De eso va el expediente de personal.
Así, el día que quieras internalizar la nómina, tienes los datos. Y si no, al menos no dependes de un tercero para saber cuántos días de vacaciones le quedan a alguien.
Resumen honesto
La nómina es el módulo donde más se nota si tienes localización o no. Con ella, es uno de los ahorros más claros. Sin ella, es el módulo por el que no conviene empezar.
