Integraciones de un ERP inmobiliario: bancos, CFDI, CRM y portales

Un ERP para una desarrolladora inmobiliaria tiene que conectarse con lo que ya mueve el dinero, el comprobante, el prospecto y la unidad. Cuatro familias cubren casi siempre esa conversación: bancos (estado de cuenta, referencia de pago y conciliación), facturación CFDI (timbrado vía PAC y, cuando el pago llega después, el complemento), el CRM o embudo de ventas (prospectos, apartados e inventario disponible) y los portales inmobiliarios junto con el sitio (publicación de inventario y captura de leads). Contabilidad, WhatsApp o el expediente digital entran si el dato ya vive ahí y alguien lo vuelve a escribir en el ERP.

Cada integración resuelve un problema, mueve datos en una dirección y se cae de una forma distinta. Una conexión de catálogo, igual para cualquier empresa, deja fuera el esquema o el estatus de la unidad, y el equipo regresa a la hoja. La doble captura y el inventario desfasado se ven el viernes: el portal dice disponible, el CRM dice apartado y cobranza no ve el depósito.

Kalibra se fundó en enero de 2025. Todo lo que vende es desarrollo a la medida, incluido el CRM. Hoy lo usan 3 desarrolladoras en Mérida y Playa del Carmen, con más de 25 desarrollos en conjunto. No publicamos sus nombres ni una tarifa. El sistema está en el ERP para desarrolladoras inmobiliarias. Las integraciones se acotan durante la implementación, de 6 a 8 meses según el alcance, sobre los bancos, el PAC, los portales y las herramientas de esa desarrolladora. Después del arranque hay acompañamiento de 2 a 3 meses. La demo dura 30 minutos.

Qué responde esta página

Sirve a quien evalúa un ERP y quiere saber qué debería conectar, y por qué. El corte entre embudo y unidad está en ERP frente a CRM inmobiliario. En qué etapa se construye cada conexión está en la implementación, etapa por etapa, y los cinco pasos están en el proceso de implementación. El CFDI y el banco se quedan en la conexión: qué sistema habla con cuál y qué dato viaja. Lo de Kalibra sale de las páginas publicadas. No añadimos bancos, portales ni PAC que esas páginas no nombran.

La tabla, en una hoja

Léela con un desarrollo activo encima de la mesa. Donde Kalibra publica un comportamiento, la celda lo dice. Donde no, pide acotarlo en el alcance.

Cuatro preguntas que valen para cualquier conexión

Si la respuesta es «viene incluido», pide el caso de una unidad de tu desarrollo. API o archivo: una API mueve el dato cuando ocurre; un layout —estado de cuenta, CSV o Excel— lo mueve cuando alguien lo carga. Los dos pueden servir. El archivo se detiene el día que nadie lo descarga. La API se rompe cuando el otro lado cambia un campo. Pregunta cuál está en el alcance y quién avisa si el formato cambia.

Apartar una unidad no espera al corte de la noche. El reporte para socios sí puede. El dueño es el equipo del ERP, el banco, el PAC, el portal o la desarrolladora: si nadie lo nombra, el primer cambio de layout se queda solo. Si falla, tiene que verse que no llegó el archivo, que el timbrado rechazó el comprobante o que el portal no publicó. En silencio, cobranza cree que el mes cuadra.

Bancos: estado de cuenta, referencia y conciliación

El problema es el depósito que no sabe de qué unidad es. El cliente paga el enganche o la mensualidad, el dinero entra a una cuenta del desarrollo y administración busca monto, fecha, referencia y nombre. Si la referencia no viajó, o si varios pagos vienen en un solo movimiento, el saldo y el banco dejan de ser el mismo hecho.

Entra el estado de cuenta y se queda el pago contra el calendario de esa unidad. El esquema de pago vive en ventas y apartados y en la cobranza. La conexión que trae el movimiento es otra cosa. En Kalibra, la conciliación bancaria con IA importa estados de cuenta de los principales bancos de México y propone el cruce. El sitio no nombra una conexión en línea con un banco: otro formato o otra frecuencia van al alcance. «Acepta bancos» no dice quién carga el archivo ni qué pasa si la referencia viene vacía. Anotarlo en una hoja y que el archivo lo proponga otra vez deja dos registros.

CFDI: timbrado y complemento de pago

El problema es el comprobante que no conoce a la unidad. Ventas cierra, administración factura en otro sistema y el PDF se queda en una carpeta. Cuando el cliente paga a meses, hace falta un segundo comprobante por el dinero que sí entró. Si ese folio no está en la venta ni en el cobro, el expediente pregunta por un papel que el ERP no tiene.

El dato sale hacia quien timbra —el PAC de la desarrolladora, o el que el alcance elija— y regresa el comprobante ligado a la venta o al cobro. El SAT indica que el complemento de recepción de pagos se expide por pagos en parcialidades, cuando no se paga en una sola exhibición, y cuando el pago ocurre después de la factura, también en operaciones a crédito. En una desarrolladora eso es el enganche y las mensualidades. Aquí la pregunta es si el conector cubre ese complemento.

Kalibra publica la emisión de CFDI desde la plataforma, vinculada a la venta o al cobro, en las preguntas frecuentes y en el ERP para desarrolladoras. No nombra un PAC. Qué PAC, si el complemento entra al primer alcance y qué se hace si el timbrado rechaza el comprobante se definen en la implementación. Un timbrado que no conoce el plan de pagos de la unidad obliga a capturar al cliente en los dos lados.

CRM: prospectos, apartados e inventario

El problema es el apartado que existe en el embudo y no en la cobranza. Comercial registra prospecto, visita y apartado. Administración necesita ese mismo hecho como expediente y como plan de pagos. Si cada área tiene su sistema, alguien copia cliente, unidad, monto y vigencia. En la copia se pierde el origen del lead o se ofrece una unidad que ya no está libre.

Si son dos productos, el apartado va hacia el ERP y la disponibilidad —disponible, apartada, vendida— regresa al embudo. Si la vuelta tarda, dos asesores ofrecen la misma unidad. Si el CRM es el módulo comercial del mismo ERP, el apartado del asesor es el registro que hereda cobranza. Esa diferencia está en ERP frente a CRM inmobiliario.

En Kalibra el CRM inmobiliario es desarrollo a la medida: prospectos, asesores, inventario, comisiones y apartado con monto, vigencia y documentos. Los leads de portales, campañas, redes, referidos y caseta entran a un solo lugar. El bloqueo de la unidad está en ventas y apartados. El sitio no describe un conector con un CRM de otra marca. Si el embudo vive en otro producto, se decide en el proceso de implementación. Una exportación nocturna sigue siendo dos verdades durante el día.

Portales inmobiliarios y sitio web

Hay dos puntas. Publicar una unidad ya vendida, o esconder una que sigue disponible. Y el lead que el portal deja en un correo, sin origen. El inventario público y el interno dejan de ser el mismo, y comercial no sabe cuántos interesados llegaron por ese canal.

Sale el estatus que sí se puede anunciar. Entra el lead: nombre, contacto, unidad o desarrollo, y el origen. El sitio de la desarrolladora es la misma conexión, con formulario propio. Un portal con nombre no está en las páginas de Kalibra. Si esa publicación hace falta, el alcance dice qué desarrollos, qué estatus, qué campos y cada cuándo.

En el CRM, el prospecto del portal entra al mismo embudo que el de campaña, referido o caseta. Eso ordena la entrada. No afirma una publicación automática en un portal concreto. El fallo clásico es subir una hoja «mientras conectamos» y apartar la unidad el mismo día, o publicar unidades que no están en preventa. Pregunta qué estatus salen y qué queda anunciado si la sincronización falla.

Contabilidad, WhatsApp y expediente

Entran cuando el dato ya se captura fuera y el ERP lo vuelve a pedir. El sitio no publica un módulo de contabilidad general. Sí publica la conciliación del pago de la unidad y la exportación de reportes a Excel y PDF. Un layout hacia el sistema del contador —qué sale, cada cuándo, quién revisa un folio que no cuadra— se escribe en el alcance si hace falta.

La página del CRM describe que, en la versión móvil, el asesor puede enviar una cotización por WhatsApp y actualizar al prospecto. No describe un conector que archive cada chat: si hace falta, es alcance. El expediente digital guarda checklist y versiones. La escrituración sigue la unidad hasta la firma ante notario. Una firma electrónica de un proveedor concreto no está en esas páginas. Si el contrato se firma en otra herramienta, hay que decir quién regresa el documento al expediente.

Qué se acota en la implementación

Porque Kalibra es desarrollo a la medida, la lista de conexiones sale del diagnóstico: qué bancos usa la desarrolladora, con qué PAC factura, qué portales y qué sitio publican, y si el embudo ya vive en otra herramienta. En la configuración se construye lo que ese plan nombra. Un esquema que no se usa —INFONAVIT, cofinanciamiento, crédito bancario o pago directo— no entra por si acaso. El detalle está en qué pasa en los 6 a 8 meses.

Conectar bancos, CFDI o esquemas de crédito suma trabajo y entra al alcance. No hay tarifa publicada. La demo dura 30 minutos. Si el proyecto no se justifica, se dice antes de cotizar.

¿Qué integraciones necesita tu desarrolladora?

Márcala con un desarrollo activo, un estado de cuenta del mes y el lugar donde hoy cae el lead.

1. ¿El depósito de la mensualidad se cruza con el estado de cuenta, o alguien lo busca a mano?
2. ¿La referencia de pago viaja con el depósito, y qué pasa cuando viene vacía?
3. ¿El CFDI de la venta y el del pago quedan ligados a la unidad, con el PAC que ya usas?
4. ¿El apartado del asesor abre el expediente y el plan de pagos sin una segunda captura?
5. ¿La unidad disponible es la misma en el embudo, en cobranza y en lo que ve el cliente?
6. ¿El portal o el sitio reciben el estatus correcto, y el lead entra con su origen?
7. ¿El contador, el chat o el expediente siguen pidiendo el mismo dato que el ERP ya tiene?
8. ¿Está escrito quién mantiene cada conexión y qué se ve el día que falla?

Las tres primeras miran el dinero y el comprobante. La cuarta y la quinta, el embudo y la unidad. La sexta, lo que se publica. La octava, si la conexión sobrevive al primer cambio de layout.