Cómo elegir un ERP para desarrolladoras inmobiliarias: checklist de 15 puntos

Elegir un ERP para una desarrolladora inmobiliaria se hace con un checklist, no con el nombre del software. Revisa 15 puntos en cuatro bloques: operación, técnico, proveedor e implementación. El sistema tiene que seguir la unidad desde el apartado hasta la escrituración, hablar con el banco y con el SAT, dejarte claro qué recibes al cierre, y llegar a producción con un calendario escrito. Si un punto no se demuestra con una unidad y un esquema de pago tuyos, no está resuelto.

Esta página es esa lista, lista para llevar a la demo. No ordena marcas ni publica precios. Si lo que buscas es de qué depende el costo, está en qué define el precio de un ERP inmobiliario en México.

Para quién sirve esta lista

Sirve cuando ya tienes más de un desarrollo, o cobranza a plazos, y las hojas de cálculo empiezan a fallar en cosas concretas: una unidad apartada dos veces, un saldo que no cuadra con el banco, un expediente que se persigue por mensajes, un reporte para socios que alguien arma el fin de semana. Una operación de un solo desarrollo y pocas decenas de clientes puede seguir con herramientas simples. El ERP se justifica cuando la cartera, el inventario o la escrituración ya no caben ahí.

Kalibra se fundó en enero de 2025. Es un desarrollo a la medida, no un SaaS. Hoy lo usan 3 desarrolladoras en Mérida y Playa del Carmen, con más de 25 desarrollos en conjunto. No publicamos sus nombres. El sistema está descrito en el ERP para desarrolladores inmobiliarios. Las preguntas de abajo aplican igual si evalúas a Kalibra o a otro proveedor: lo que no se puede mostrar en pantalla, no lo des por hecho.

Los 15 puntos, en una tabla

Llévala a la junta. La tercera columna es lo que tienes que ver, no lo que dice el folleto. Si la respuesta es «eso se configura después» y nadie abre la pantalla, anótalo como pendiente.

Operación: el ciclo de la unidad

Los primeros seis puntos preguntan si el sistema entiende una desarrolladora. El ciclo que importa es el de la unidad: disponible, apartada, vendida, en cobranza, en escrituración. Si para verlo hay que abrir ventas en un lado, el saldo en una hoja y el expediente en una carpeta, el ERP todavía no es uno.

En el software de ventas y apartados cada unidad tiene estatus visible, el master plan muestra la disponibilidad y el apartado aplica tus reglas de monto, vigencia y documentos. En la demo, aparta una unidad y pide que otro usuario intente apartarla otra vez. Si el sistema lo permite, el doble apartado sigue siendo un riesgo de la operación.

El esquema de pago tiene que ser el tuyo. Pregunta por crédito INFONAVIT, cofinanciamiento, crédito bancario y pago directo, con los hitos de cada uno en la venta y en la escrituración. Si el desarrollo los usa, también por pagos domiciliados, tarjetas y tiendas de conveniencia. Un calendario de mensualidades iguales no describe esas operaciones.

El expediente digital cambia el checklist según la operación: contado, crédito bancario o esquemas como INFONAVIT y Fovissste. Cada archivo guarda quién lo subió, cuándo y si reemplaza una versión anterior. Ventas, administración y dirección no tienen por qué ver lo mismo. Pide el expediente de la unidad que apartaste: un folder de PDFs sin checklist no alcanza.

En cobranza, cada pago queda en semáforo —al corriente, por vencer o vencido— con calendario y alertas antes y después de la fecha. La cartera se consulta por antigüedad, desarrollo, esquema y asesor. Si la única forma de saber quién debe es el cierre de mes, la cobranza sigue siendo reactiva.

La escrituración es un flujo: expediente, solicitud de crédito, avalúo, autorización, firma ante notario, registro y entrega. Las etapas cambian si la operación es de contado o de crédito, y pueden exigir documentos o pagos al corriente antes de avanzar. Pregunta quién responde la etapa y qué pasa cuando se vence la fecha.

Técnico: banco, SAT, datos y reportes

Los puntos 7 a 10 son las conexiones que, si fallan, devuelven el trabajo a Excel.

La conciliación bancaria con IA importa estados de cuenta de los principales bancos de México y propone el cruce con el pago, con un nivel de confianza para lo automático y lo que queda a revisión. Lleva a la demo un estado de cuenta y un pago que ya identificas. Si el archivo no se puede importar, ese mes sigue siendo manual.

El CFDI se emite desde la plataforma, ligado a la venta o al cobro. Basta ver que la factura no vive en otro programa desconectado del saldo. Si facturan fuera, pregunta cómo regresa ese dato a la unidad.

Kalibra opera en la nube, con respaldo automático, encriptación en tránsito y en reposo, y acceso por rol. Los datos se exportan. Al cierre del desarrollo a la medida, el código fuente es del cliente. Pide lo mismo por escrito a cualquier proveedor: quién entra, cómo se respalda, cómo te llevas la información y si el código queda contigo.

Los reportes y dashboards juntan unidades disponibles, apartadas y vendidas, cobranza esperada frente a cobrada, cartera vencida y escrituraciones en proceso. Se exportan a Excel y a PDF. Pide el tablero de un desarrollo y el mismo corte en archivo. Si alguien tiene que armarlo, el tablero todavía no existe.

Proveedor: quién construye y qué te deja

Un folleto puede nombrar los seis módulos y aun así no conocer tu operación. Los puntos 11 a 13 separan el discurso de quien se va a sentar contigo.

Lleva una unidad, su esquema de pago y, si puedes, un expediente incompleto. Pide que el recorrido use eso, no un edificio de muestra. Ahí se ve si el apartado, el enganche y la escrituración salen de origen o si cada uno es una adaptación que todavía no existe. Kalibra parte del ciclo de una desarrolladora y se configura a tus reglas, porque no hay dos operaciones iguales.

El modelo tiene que quedar dicho. Hay productos cerrados y hay desarrollo a la medida. Kalibra es lo segundo: no es un SaaS. El sistema se adapta a los procesos de cada cliente y el código fuente queda del cliente al cierre. Un producto cerrado puede alcanzar si tu operación cabe en él. El desarrollo a la medida se justifica cuando el apartado, la cobranza o la escrituración tienen reglas propias. No firmes sin saber cuál de los dos te están vendiendo y qué recibes al terminar.

Pregunta quién acompaña las primeras semanas y si la capacitación es por rol: ventas, administración y dirección no usan las mismas pantallas. Pregunta también cuántas desarrolladoras usan el sistema y en qué ciudades, sin exigir nombres. Kalibra puede decir esto: 3 desarrolladoras en Mérida y Playa del Carmen, con más de 25 desarrollos en conjunto. Una referencia que no se puede verificar no suma.

Implementación: plazo, etapas y datos

En Kalibra el plazo típico es de 6 a 8 meses, según el alcance. La implementación tiene cinco etapas: diagnóstico, configuración a la medida, migración de datos, capacitación por rol y acompañamiento ya en uso. Arrancar por cobranza o por ventas no es el mismo trabajo que cubrir inventario, expediente, escrituración y reportes desde el primer día. Pide el plan escrito: reuniones, quién de tu lado asiste y qué cierra cada etapa.

Tu equipo pone tiempo. Alguien de dirección o administración es el contacto, alguien conoce los saldos y alguien valida que lo migrado es lo real. Si te dicen que ellos cargan todo y tu gente no revisa, el cierre queda sin dueño.

En la migración entran clientes, ventas, pagos, saldos y documentos que sí se usan el primer día. Lo que nadie consulta no tiene por qué cargarse: meter archivos «por si acaso» alarga el arranque y arrastra errores viejos. Acuerden qué se carga, en qué formato y quién lo depura. Se puede empezar por el módulo que más urge y sumar el resto después.

Cómo usar la lista en la junta

Llega con un desarrollo activo, una unidad y su esquema de pago, un saldo que hoy cruzas contra el banco y la lista de documentos para escriturar. Recorre los 15 puntos sobre ese caso. Marca sí, no o «queda para la propuesta».

Tres cierres son sanos. El sistema cubre la operación y el calendario cabe en un alcance que reconoces. Cubre una parte y el resto queda por escrito para después. O tu operación todavía cabe en las herramientas actuales y el proyecto no se justifica. Lo que no sirve es una demo genérica y una propuesta con los 15 puntos sin responder.

El precio no entra en este checklist. Sin módulos, integraciones, procesos, número de desarrollos y alcance de la migración, una cifra no describe el proyecto. Cuando la lista esté marcada, la conversación de costo tiene de dónde agarrarse.