Un ERP a medida no se paga una vez: se paga cada vez que cambia algo de fuera, una versión nueva del sistema, un modelo de la Agencia Tributaria o el fichero de un banco. El presupuesto que te enseñan cubre el año cero y la factura vive en los años uno, dos y tres.
Lo comprobamos el 22 de septiembre de 2026 abriendo once de las doce páginas que salían primero para esta búsqueda en España y midiéndolas con la misma vara. Ninguna publica un importe. Ninguna compara contra un estándar con tarifa pública. Y ninguna pone precio a adaptar lo tuyo cuando sale una versión nueva: las que hablan de actualizaciones dicen, como mucho, de quién es la tarea.
- La diferencia de coste que no sale en el presupuesto no está en construir, está en mantener.
- En un estándar solo hay que adaptar aquello en lo que te saliste del estándar, aunque probar la versión nueva siempre te toca a ti. En un ERP a medida, todo lo que haya que adaptar es tuyo: no hay fabricante que se ocupe de ninguna parte.
- Diez usuarios en el plan Estándar de Odoo con facturación anual son 1.428 euros el primer año, sin IVA y con el descuento de entrada, y 1.788 euros cada año siguiente, según la tarifa pública consultada el 24 de septiembre de 2026.
- La declaración responsable de VeriFactu la firma quien produce el sistema, y si lo desarrolla la propia empresa, la firma ella. Si facturas con un programa, tiene que estar adaptado antes del 1 de enero de 2027 si tu empresa paga el Impuesto sobre Sociedades. En el resto de casos, autónomos incluidos, antes del 1 de julio de 2027. Quien lleva el SII queda fuera.
- Antes de firmar un ERP a medida, pide por escrito quién lo adapta en la próxima versión y con qué tarifa.
¿Qué es un ERP a medida y qué te están vendiendo cuando te lo ofrecen?
Un ERP a medida es código escrito para ti que el fabricante no conoce ni mantiene salvo que le pagues por hacerlo, a diferencia de lo que se configura en una implantación estándar. Todo lo que se resuelve con las opciones del producto no es desarrollo: es configuración, y la mantiene el fabricante. Lo hecho con Studio también entra en la actualización, en cualquier alojamiento, mientras Studio siga instalado y con su suscripción. El código Python que se añada, aunque sea desde Studio, solo entra si pagas su mantenimiento.
Un ERP a medida se construye desde cero, o casi, para replicar tu forma de trabajar. Enfrente está el estándar, que ya existe y se amplía por donde el fabricante deja preparado: el camino de una implantación de Odoo normal. Entre los dos hay un caso intermedio: un estándar con módulos propios encima. Ahí pagas la licencia, en el plan Personalizado, y además mantienes ese código en cada versión. El ejemplo de más abajo es de este tipo.
La frontera no está donde suele contarse. Crear campos, cambiar un informe o automatizar un aviso es configuración, no desarrollo propio.
Pregunta qué parte de lo que te ofrecen es configuración y qué parte es código: la factura de dentro de tres años sale sobre todo de la segunda, y conviene separarlas ya en el alcance cerrado o en la fase de análisis.
¿De verdad tu proceso es especial?
Muchas de las necesidades que una pyme da por únicas ya tienen nombre propio dentro de un estándar. La que sobrevive a esa criba es el desarrollo de verdad, y esa es la que hay que presupuestar con cuidado.
Muchas empresas creen que su forma de vender es única. A veces lo es. A menudo lleva años resuelto en una función que nadie le enseñó al comprador.
El ejercicio que merece la pena antes de pedirnos presupuesto: coge las necesidades que darías por especiales y busca cuál no tiene equivalente. Lo que sobreviva es el desarrollo real.
¿Tu proceso especial ya existe?
| Lo que crees que es tuyo | Lo que ya existe |
|---|---|
| Precios distintos por cliente | Listas de precios. Una lista por cliente o por grupo, con reglas por cantidad y vigencia por fechas. |
| Series de facturación separadas | Diarios. Cada diario de facturación lleva su propia secuencia y se pueden tener varias a la vez. |
| Control de lotes y caducidad | Números de serie y lote, y fechas de caducidad. Trazabilidad por lote o número de serie, con fecha de caducidad, de consumo preferente y de eliminación. |
| Portal para que el cliente vea sus pedidos | Portal de cliente. El cliente entra con su usuario y ve presupuestos, pedidos, albaranes y facturas. |
| Aprobación de pedidos por importe | Aprobación del pedido de compra. Un pedido de compra por encima del importe mínimo que fijes queda «A aprobar» hasta que un responsable lo aprueba (de serie). En pedidos de venta se hace con las reglas de aprobación de Studio, que exige el plan Personalizado. |
| Comisiones del comercial | Planes de comisiones (Odoo 18, 19 y 20, solo Enterprise): por objetivos o por logros, por comercial o por equipo, y por producto o categoría. Lo que no encaje en esos planes es de las pocas cosas que acaban en código. |
¿Cuánto cuesta un ERP a medida frente al estándar?
Diez usuarios en el plan Estándar de Odoo con facturación anual son 1.428 euros el primer año, con el descuento de entrada, y 1.788 euros a partir del segundo: 5.004 euros de licencia en tres años, sin IVA ni implantación, con las actualizaciones incluidas. El desglose completo está en lo que cuesta implantar Odoo. Un desarrollo propio no tiene licencia, pero sí una factura de mantenimiento que conviene presupuestar.
La comparación honesta necesita dos columnas y una fecha: lo que cuesta empezar, lo que cuesta seguir y de cuándo es el dato. Casi nadie publica lo tercero.
Un estándar con tarifa pública se calcula delante del cliente, con el dato del 24 de septiembre de 2026.
Un desarrollo propio no tiene licencia, y ahí gana. Lo que tiene es la cuenta de volver a tocar el código cada vez que cambia el suelo. En los escenarios de implantación está lo que cuesta el otro.
| Concepto | ERP estándar | ERP a medida |
|---|---|---|
| Licencia | Tarifa pública por usuario y mes | No hay |
| Puesta en marcha | Configuración y datos | Análisis, construcción y pruebas |
| Versión nueva | Incluida para las aplicaciones estándar y para lo hecho con Studio (que exige el plan Personalizado), en cualquier alojamiento | La adapta quien mantiene el módulo |
| Cambio normativo | Suele llegar en la localización del fabricante (VeriFactu llegó así en Odoo 17, 18, 19 y 20) | Hay que encargarlo |
| Si el proveedor desaparece | Cambias de implantador y el producto sigue | Depende de si tienes el código y de quién sepa leerlo |
| Lo que pagas cada año | Licencia y soporte | Las horas de mantener vivo lo tuyo |
La línea que no aparece en el presupuesto
No es un cliente nuestro ni lleva cifras nuestras: es un escenario construido con el ciclo de versiones que documenta Odoo.
Una empresa de diez personas pide un módulo de pedidos a medida: precio por cliente con descuento por volumen, aviso al comercial cuando uno lleva sesenta días sin pedir y albarán con el formato que exige su mayor cliente.
Parte de eso ya lo cubren las listas de precios, pero el proveedor lo resuelve con un módulo propio que toca el pedido y la lista de precios y añade una tarea programada. Ese trabajo tiene coste en horas y sí aparece en el presupuesto. Lo que no aparece es que cada año sale una versión nueva y, cada vez que actualices, alguien tiene que abrir ese módulo, probarlo y adaptarlo. De ahí salen las decisiones que conviene cerrar antes de firmar.
Cuando sale la versión nueva, ¿quién adapta lo tuyo?
Con la suscripción, la actualización viene incluida para las aplicaciones estándar y para lo hecho con Studio, que exige el plan Personalizado. Da igual que estés en Odoo Online, en Odoo.sh o en servidor propio. Los módulos propios los adapta quien los mantiene. Odoo solo se encarga de convertirlos si pagas su mantenimiento: una cuota mensual por cada cien líneas de código. Y si trabajas con un partner, ese servicio se lo subcontrata a él. Si no, es tuya o de tu proveedor: pídela por escrito.
Un estándar publica su calendario. Odoo mantiene tres versiones a la vez y saca una al año, y cada una tiene tres años de soporte estándar desde que sale. La 19 salió en septiembre de 2025 y lo tiene hasta septiembre de 2028, según la previsión de Odoo. Después, en Odoo.sh o en servidor propio entra en soporte extendido, que se paga aparte: un recargo del 25 % del precio anual. En Odoo.sh tienes, además, dos años más para actualizar. En Odoo Online no hay soporte extendido y hay que actualizar antes: como mucho, cada dos años. No es una sorpresa, es una fecha.
En un estándar solo hay que adaptar aquello en lo que te saliste del estándar (probar la versión nueva te toca siempre a ti). En un desarrollo propio, todo lo que haya que adaptar es tuyo. Tener el código, con los derechos para modificarlo por escrito, te deja cambiar de proveedor; no te ahorra la adaptación, y eso es lo que conviene cerrar por contrato.
- Año 0. Se construye el módulo sobre la versión vigente.
- Años 1 y 2. Sale una versión nueva cada año. En cada salto alguien abre el módulo, lo prueba y lo adapta.
- Año 3. La versión de partida sale del soporte estándar. En Odoo.sh o en servidor propio pasa al soporte extendido, que se paga aparte. En Odoo.sh tienes dos años más para actualizar. En Odoo Online no se pueden instalar módulos propios, y hay que actualizar como mucho cada dos años.
¿Quién responde de esto?
| Situación | Con un ERP estándar | Con un desarrollo propio |
|---|---|---|
| Sale la versión nueva del ERP | El fabricante (incluida para apps estándar y para Studio, en cualquier alojamiento; la prueba final es tuya) | Quien lo mantenga (si tu contrato lo dice) |
| La Agencia Tributaria cambia un modelo | El fabricante, normalmente (llega en la localización) | Quien lo mantenga (hay que encargarlo) |
| El desarrollador cierra o deja de atender | Cambias de implantador (el producto sigue existiendo) | Depende del código (y de quién sepa leerlo) |
| Hay que conectar un banco nuevo | Conector del catálogo (si ese banco está) | Desarrollo (cada integración, aparte) |
| Algo falla un sábado por la tarde | Tu implantador (si su contrato cubre el fin de semana; el soporte de Odoo atiende de lunes a viernes, aunque vigila su nube las 24 horas) | Lo que ponga el contrato (si no lo pone, nadie) |
| Llega la fecha de VeriFactu | Quien produce el sistema (RD 1007/2023, artículo 13); si tu implantador añade módulos que tocan la facturación, él certifica esos módulos | La propia empresa si lo desarrolla con sus medios; si lo encarga, quien lo produce (criterio de la Agencia Tributaria) |
¿Y si cambia la ley? VeriFactu y las fechas de 2027
La declaración responsable la firma quien produce el sistema informático, y las fechas límite son antes del 1 de enero de 2027 para los contribuyentes del Impuesto sobre Sociedades y antes del 1 de julio de 2027 para el resto (Real Decreto-ley 15/2025).
El reglamento obliga a que sea el productor quien certifique, mediante declaración responsable, que el sistema cumple, y pide que conste de forma visible en el propio programa.
La orden que desarrolla el reglamento lo dice para las ampliaciones: si otro añade componentes a un programa, aporta su propia declaración (Orden HAC/1177/2024, artículo 15.4). Y la Agencia Tributaria aclara el resto en sus preguntas frecuentes. Si la empresa hace el desarrollo con sus medios, aunque sea con personal contratado a su cargo, lo certifica ella. Si lo encarga como producto a un tercero, lo certifica ese tercero. Por eso la pregunta de quién firma se hace antes de encargar el desarrollo.
¿Cuándo sí compensa un ERP a medida?
Cuando el proceso que te diferencia es el producto que vendes, cuando ningún estándar toca tu sector o cuando el número de usuarios hace que la licencia deje de salir. Y siempre que puedas escribir quién lo adapta dentro de dos años.
Hay casos en los que un ERP a medida es la respuesta correcta y conviene decirlo, y de hecho hacemos desarrollo a medida cuando es así. Esto no va de vender una opción sobre la otra, va de que la cuenta esté completa antes de firmar.
La señal no es cuál te gusta más: es si puedes escribir hoy quién adapta el sistema dentro de dos años y con qué tarifa. Si está firmado, se defiende solo. Si no, es una apuesta. Y si la duda es de proceso, empieza por ordenar los procesos.
Lo que haríamos nosotros
Empezaríamos por el camino del estándar y nos saldríamos solo en lo que de verdad no encaja, que casi siempre es menos de lo que parece. Y antes de firmar pediríamos dos líneas: quién lo adapta en la próxima versión y con qué tarifa.
Con lo que no estamos de acuerdo
Con la comparación que se publica. Cuando se compara contra un estándar sin precio, o contra SAP, la conclusión viene puesta de casa. Uno con tarifa pública de dos cifras cambia la cuenta, y no salía en ninguna de las once que medimos el 22 de septiembre.
Lo que todavía no sabemos
Si la Agencia Tributaria publicará más ejemplos de declaración responsable. En su sede ya hay uno: el de un programa comercial que solo funciona en modo VERI*FACTU. No hay ninguno para el desarrollo propio ni para la ampliación a medida de un programa certificado, que es lo que afecta a cualquiera que venga de una migración con desarrollo propio. A 28 de septiembre de 2026, sus preguntas frecuentes siguen diciendo que se publicarán modelos.
Preguntas frecuentes sobre el ERP a medida y el estándar
¿Un ERP a medida sale más barato que uno estándar?
¿Qué diferencia hay entre personalizar un estándar y hacer un desarrollo a medida?
Si tengo el código fuente, ¿ya estoy cubierto?
¿Cada cuánto hay que actualizar un ERP estándar?
¿Quién firma la declaración responsable de VeriFactu?
¿Qué pasa si el desarrollador de mi ERP desaparece?
¿Qué conviene pedir por escrito antes de firmar?
¿Cuál de los dos caminos le sale a cuenta a tu empresa?
Mándanos las funciones que te han presupuestado y te decimos cuáles se resuelven configurando, cuáles son desarrollo y qué cuesta mantener lo segundo. Si lo que te encaja es el estándar, en cómo implantamos el estándar lo contamos entero, y en desarrollo a medida qué hacemos cuando de verdad hace falta código.