Integración CRM y ERP: 6 flujos de datos y quién es dueño

La integración entre CRM y ERP es el acuerdo entre comercial, finanzas y TI sobre qué datos gobierna cada sistema, en qué dirección y con qué frecuencia viaja cada dato, en qué momento el negocio ganado se vuelve pedido y quién corrige el mensaje que falló, y el conector elegido es la última de esas decisiones. El CRM, sistema de gestión de la relación con el cliente, registra la intención y la negociación, y el ERP, sistema de gestión empresarial, registra la obligación: pedido, factura, cuenta por cobrar e inventario. En la TIC Empresas 2025, que entrevistó a 4.174 empresas brasileñas con diez o más personas ocupadas, el 76% de las empresas con 250 o más personas usó ERP para integrar datos y procesos de los departamentos (Cetic.br, 2026) y el 56% usó alguna aplicación de CRM en los últimos 12 meses (Cetic.br, 2026). La suma supera el 100%, así que al menos el 32% de las grandes empresas mantiene los dos sistemas, y la pregunta de la dirección pasa a ser cómo conversan entre sí.

La escena que encuentro con frecuencia empieza con una llamada. El vendedor busca al cliente para ofrecerle la renovación y escucha que la empresa todavía discute tres facturas vencidas con finanzas, información que estaba en el ERP desde el mes anterior. El mismo día, finanzas retiene un pedido por falta de crédito sin saber que el director comercial aprobó una condición especial para ese cliente. Los dos sistemas tienen razón y ninguno ve al otro. El proceso del lead al dinero en la cuenta está en lead to cash, y el dueño de cada entidad de la operación, en arquitectura de datos de ingresos. La conexión entre CRM y ERP pide decisiones propias, que el proyecto de TI suele saltarse.

¿Qué gobierna el CRM y qué gobierna el ERP?

Cada dato necesita un sistema maestro, el único lugar donde alguien lo crea o lo modifica, y los demás sistemas reciben una copia o lo consultan. Lo que nace en la relación comercial pertenece al CRM: lead, contacto, oportunidad, etapa, valor previsto, propuesta y descuento aprobado. Lo que nace de una obligación fiscal, contable o logística pertenece al ERP: registro fiscal del cliente, código y tributación del producto, pedido, factura, cuenta por cobrar, límite de crédito y saldo de inventario. Los datos de frontera consumen la mayor parte del tiempo del proyecto.

El cliente es el primero de ellos. Nace en el CRM como empresa prospectada, muchas veces sin identificación fiscal, y solo se convierte en registro fiscal en el ERP cuando alguien necesita emitir factura. El diseño que funciona separa los dos momentos: el CRM es dueño de la empresa mientras es prospecto, y el ERP asume los datos fiscales cuando finanzas aprueba el registro, momento en que esos campos quedan solo de lectura en el CRM. El precio es el segundo dato de frontera. La lista oficial nace en el ERP o en contraloría, y el precio aplicado nace en la negociación, con el descuento que la política de descuentos autorizó. La dirección tiene que decidir cuál de los dos prevalece en el pedido, porque un ERP configurado para recalcular según la lista borra el descuento aprobado y la factura sale con un valor distinto al del contrato.

¿Qué datos viajan entre CRM y ERP, en qué dirección y con qué frecuencia?

La tabla cubre los seis grupos de datos que aparecen en casi toda integración entre CRM y ERP en una operación B2B. Los campos del CRM que reciben esos datos, con tipo y quién los completa, salen del modelo de datos del CRM.

Dato	Origen (sistema maestro)	Destino	Qué viaja y cuándo	Frecuencia
Cliente	CRM hasta el registro aprobado, ERP después	ERP, con retorno al CRM	Al ganar, van razón social, identificación fiscal, dirección y contacto de facturación; vuelven código del cliente, situación y límite de crédito	En el evento, y diaria para la situación
Producto y lista de precios	ERP	CRM	Código, descripción, tributación y precio de lista; el artículo desactivado sale de la cotización	Diaria, y en el evento cuando la lista cambia
Pedido	El CRM lo crea, el ERP lo gobierna después	ERP	El negocio que llega a la etapa acordada genera el pedido; el ERP devuelve número y situación	En el evento, en minutos
Facturación	ERP	CRM	Número, fecha y valor de la factura, con anulación y reemisión	En el evento o cada hora
Cuentas por cobrar	ERP	CRM	Vencimiento, valor y días de atraso por cliente	Diaria, antes de la jornada
Inventario	ERP	CRM	Saldo disponible del artículo al momento de cotizar, sin copia guardada	Bajo demanda

La frecuencia de cada fila sale de una pregunta al dueño del dato: cuánto retraso acepta su proceso. Las cuentas por cobrar y la lista de precios aguantan una carga por lotes de madrugada, y el pedido tiene que llegar en minutos, porque finanzas y logística trabajan sobre él el mismo día. El inventario pide una consulta al ERP en el momento de cotizar, ya que un saldo copiado a las seis de la mañana está equivocado a las tres de la tarde. Tiempo real en todos los flujos encarece el proyecto y el mantenimiento sin mejorar ninguna decisión.

¿Cómo funcionan la clave única y la tabla de equivalencias?

La clave única es el identificador que permite a los dos sistemas reconocer el mismo registro, y la regla de matriz, sucursal y grupo económico está en la arquitectura de datos. En la integración, el camino seguro es la clave cruzada: el CRM guarda el código del cliente en el ERP, el ERP guarda el identificador del registro en el CRM, y la integración busca por la clave antes de crear cualquier registro. La identificación fiscal (el CNPJ, en Brasil) sirve de validación y de criterio para cruzar las bases en la primera carga. El campo tiene que aceptar letras en los dos sistemas, porque la Receita Federal de Brasil empezó a asignar CNPJ alfanumérico a las nuevas inscripciones desde julio de 2026, y los números antiguos siguen válidos (Receita Federal, 2024). Cuando las bases ya existen en los dos lados, alguien cruza los registros, resuelve los duplicados y graba la clave cruzada antes de encender la integración, con las reglas de calidad de datos en el CRM. Encender el flujo antes de ese cruce traslada de una vez los duplicados del CRM al ERP, donde corregirlos, con facturas ya emitidas, cuesta mucho más.

La tabla de equivalencias es la correspondencia entre los valores de una lista en un sistema y los valores de la misma lista en el otro. La condición de pago “30/60 días” del CRM corresponde a un código en el ERP, el vendedor dueño de la cuenta corresponde a un código de representante que define comisión y centro de costo, y la unidad de negocio corresponde a la empresa o sucursal que emite la factura. Cada tabla de equivalencias tiene como dueña al área que gobierna esa lista en el sistema maestro. Un valor nuevo sin fila correspondiente en la tabla deja el pedido detenido en la cola de errores, por eso quien crea una condición de pago o un producto nuevo crea la fila de equivalencia el mismo día.

¿Cuándo el negocio ganado se vuelve pedido?

El momento en que el negocio se vuelve pedido define quién puede cambiar qué después, y cada tipo de venta pide un diseño. En la reposición a clientes con registro y crédito aprobados, el negocio ganado crea el pedido ya liberado. En la venta B2B a un cliente nuevo, crea el pedido bloqueado hasta que finanzas revisa registro, crédito y condición de pago. En proyectos y contratos recurrentes, el pedido nace solo después del contrato firmado o de la orden de compra del cliente.

En cualquier diseño, la etapa de ganado exige los campos que el ERP necesita, con una validación que impide al vendedor avanzar sin ellos, y la integración usa el identificador del negocio como referencia del pedido. Sin ese candado, el negocio marcado como ganado el último día del mes para cumplir la meta se vuelve pedido de un cliente sin crédito aprobado. El ERP devuelve el número del pedido al CRM, y desde ese momento los valores y los artículos del negocio quedan bloqueados. El descuento extra que el cliente pide después del cierre pasa por la política de descuentos y se convierte en un cambio registrado en el pedido del ERP o en un negocio de adenda, nunca en una edición en el CRM que el ERP no recibe.

¿Cómo tratar errores y reprocesamiento en la integración?

La integración va a fallar algún día, y el diseño decide si la falla aparece en minutos o cuando el cliente reclama por la factura. Empieza por la cola de errores, la lista de mensajes que no llegaron al destino, con el motivo escrito en un lenguaje que el área entiende y una alerta para una persona con nombre. El negocio en el CRM gana un campo de situación de la integración, y el vendedor lee “pedido pendiente: condición de pago sin correspondencia en el ERP” sin abrir un ticket.

Dos propiedades técnicas evitan el daño mayor. La idempotencia es la capacidad de recibir el mismo mensaje dos veces y producir un único resultado: la integración reconoce la referencia del negocio y no crea un segundo pedido cuando alguien lo reenvía. El orden de dependencia retiene el pedido hasta que el cliente existe en el ERP y reprocesa los dos en la secuencia correcta.

Tipo de error	Ejemplo	Quién corrige	Cómo se reprocesa	Plazo
Dato incompleto	Cliente sin inscripción estatal	Ventas, en el CRM	Reenvío automático después de la corrección	Un día hábil
Equivalencia ausente	Condición de pago nueva sin código en el ERP	Dueño de la lista	Reprocesa la cola después de crear la fila	Un día hábil
Regla del ERP	Crédito bloqueado, producto inactivo	Finanzas o contraloría	Libera el pedido o lo devuelve al vendedor, con motivo	Dos días hábiles
Indisponibilidad	ERP caído, límite de llamadas alcanzado	TI	Reintentos automáticos, alerta si se vence el plazo	Dos horas

¿Conector nativo, plataforma de integración o desarrollo a medida?

El conector nativo es el que ofrece el proveedor de uno de los sistemas, con campos ya mapeados. La plataforma de integración, o iPaaS (integration platform as a service), es un servicio en la nube donde armas flujos entre sistemas con conectores y reglas configuradas, con poco o ningún código. El desarrollo a medida es código propio escrito sobre las API de los dos sistemas, las interfaces por las que cada uno recibe y entrega datos.

Opción	Cuándo sirve	Ventajas	Límites	Quién la mantiene
Conector nativo	Proceso cercano al estándar de los dos sistemas	Activación rápida, costo inicial bajo, actualización a cargo del proveedor	Mapeo fijo; una regla propia, como el pedido bloqueado, muchas veces no cabe	Administrador del CRM
Plataforma de integración	Reglas propias, más de dos sistemas, ERP sin conector	Cola de errores y reprocesamiento listos; la regla cambia sin programar	Suscripción o cobro por volumen; exige a alguien que domine la herramienta	Operaciones de ingresos o TI
Desarrollo a medida	ERP antiguo o muy personalizado, volumen alto	Control total de la regla y del desempeño	Costo inicial mayor; la cola y el reprocesamiento hay que construirlos	TI o proveedor

La decisión parte de la tabla de flujos. Marca las filas que el conector nativo cubre por completo, con disparador, equivalencias y tratamiento de errores. Si las cubre todas, la elección está hecha, y si dos o más filas piden reglas propias, la plataforma suele salir más barata en el segundo año. El desarrollo a medida entra cuando el ERP no ofrece una API utilizable, y exige una segunda persona capaz de hacerse cargo del código.

¿Cuánto cuesta mantener una integración CRM y ERP?

El presupuesto aprobado suele cubrir la construcción y olvidar el mantenimiento. Este incluye la revisión diaria de la cola, los ajustes cuando el proceso cambia, las adaptaciones a cada nueva versión de los sistemas y la suscripción de la plataforma. En los proyectos que acompaño, el cambio de proceso pesa más que el técnico: comercial lanza una oferta nueva y nadie avisa que necesita una fila en la tabla de equivalencias.

En un ejemplo hipotético, un proyecto de integración cuesta R$ 60.000. El mantenimiento consume 10 horas por mes a R$ 200 la hora, o R$ 24.000 por año, y la plataforma cuesta R$ 1.000 por mes, o R$ 12.000 por año. Mantener la integración cuesta R$ 36.000 por año, el 60% del valor del proyecto, y la dirección que aprueba sin esa línea descubre la cuenta en el primer cambio de lista de precios.

¿Cómo homologar la integración CRM y ERP?

La homologación es el período en que las áreas prueban la integración en un ambiente de pruebas, una copia de los sistemas sin efecto fiscal, con escenarios reales de la operación, y firman la aceptación antes del arranque. La lista de verificación de abajo es el instrumento que entrego a los liderazgos.

Escenario de prueba	Resultado esperado	Quién aprueba
Cliente nuevo con registro completo	Cliente creado en el ERP y código devuelto al CRM	Finanzas
Cliente que ya existe en el ERP	La integración lo encuentra por la clave y no duplica	Finanzas
Sucursal de un cliente existente	Nuevo establecimiento vinculado a la misma cuenta	Finanzas y comercial
Cliente con CNPJ alfanumérico	Registro aceptado en los dos sistemas	TI
Descuento aprobado por debajo de la lista	Pedido con el precio negociado, sin recálculo	Comercial y contraloría
Producto desactivado entre la cotización y el cierre	Error legible en la cola y aviso en el negocio	Comercial
Mismo mensaje enviado dos veces	Un único pedido en el ERP	TI
Cuenta pagada y cuenta vencida	Situación correcta en el cliente al día siguiente	Finanzas y CS
Volumen del último día hábil del mes	Cola procesada dentro del plazo	TI

El arranque se hace por flujo. El catálogo va primero, porque no crea nada en el ERP y el pedido depende del código del producto, cliente y pedido vienen después, y facturación y cuentas por cobrar cierran la secuencia. En la primera semana de cada flujo, el dueño de la cola revisa los errores todos los días con las áreas.

¿Quién es dueño de la integración entre CRM y ERP?

La tabla separa a quien ejecuta de quien aprueba.

Rol	Responde por	Aprueba
Dirección comercial	Campos obligatorios del cierre y uso de pedido y cuentas por cobrar por el equipo	Cuándo el cierre se vuelve pedido y excepciones de precio
Dirección financiera o contraloría	Registro fiscal, catálogo, lista de precios y equivalencias financieras	Liberación de pedido y cambios en las listas que gobierna
TI	Acceso, ambiente de pruebas, disponibilidad, seguridad y proveedores	Cambios técnicos, de versión y de proveedor
Operaciones de ingresos	Tabla de flujos, ficha de la integración y reglas de disparo	Cambios de campo y de regla, con las áreas dueñas
Dueño de la cola de errores	Revisión diaria de la cola, derivación y seguimiento de plazos	Nada; ejecuta y escala

El dueño de la cola necesita nombre y un suplente para las vacaciones. El patrocinador en la dirección arbitra los conflictos entre áreas, como el vendedor que quiere editar el pedido después del cierre, y lleva a la reunión mensual tres números: errores abiertos, tiempo medio de corrección y pedidos creados sin intervención manual.

¿Cuáles son los errores comunes en la integración CRM y ERP?

Integración sin cola de errores

Sin cola y sin alerta, el mensaje que falló desaparece. Finanzas descubre el pedido que no llegó cuando el cliente reclama la factura, semanas después, y nadie sabe decir cuántos otros se perdieron en el camino.

Probar solo el camino feliz

La prueba con el cliente perfecto, el producto activo y el ERP en línea pasa al primer intento. La operación real tiene sucursales, productos desactivados, descuentos por debajo de la lista y un ERP lento en el cierre del mes, y esos son los escenarios que la lista de verificación tiene que cubrir.

Guardar la regla en la cabeza de quien desarrolló

El flujo que solo una persona entiende se detiene el día en que ella deja el proyecto. La ficha de la integración, con disparadores, equivalencias, tratamiento de errores y responsables, queda junto a la tabla de flujos y cambia con cada modificación aprobada.

Capacitación: quién necesita aprender qué

La regla se vuelve hábito cuando cada área sabe qué hace la otra con el dato. Los vendedores aprenden los campos que exige el cierre, a leer la situación de la integración en el negocio y a revisar las cuentas por cobrar del cliente antes de llamar. Los gerentes comerciales empiezan a usar pedido y atraso en la reunión de pipeline. Finanzas aprende a tratar la cola y a mantener las equivalencias que gobierna, y operaciones de ingresos y TI aprenden a actualizar la ficha y a reprocesar sin duplicar. La formación rinde más con las áreas juntas, recorriendo en el ambiente de pruebas los escenarios de la homologación.

Hoja de ruta de 30 días para el liderazgo

1. Semana 1: escribe la tabla de flujos. Comercial, finanzas y TI completan los seis grupos de datos.
2. Semana 1: nombra a los dueños. Aplica la pregunta del recuadro a cada fila y a cada tabla de equivalencias.
3. Semana 2: decide cuándo el cierre se vuelve pedido. Elige el diseño por tipo de venta.
4. Semana 2: mide las bases. Cuenta cuántos clientes del CRM coinciden con el ERP por identificación fiscal, cuántos duplicados aparecen y si el campo acepta letras.
5. Semana 3: compara las opciones de integración. Marca lo que cada opción cubre de serie y presupuesta el mantenimiento anual.
6. Semana 3: escribe la homologación y los plazos de error. Adapta la lista de verificación y define el plazo de corrección por tipo de error.
7. Semana 4: aprueba en la dirección. Lleva dueño, cronograma por flujo, presupuesto de mantenimiento y los indicadores de la cola.

Si tu empresa tiene CRM y ERP y todavía depende de mensajes entre el vendedor y finanzas para saber si el pedido salió o si el cliente pagó, ese es el trabajo del formación in company de Revenue Operations. Conduzco la formación con comercial, finanzas, TI y operaciones de ingresos juntos, sobre los flujos reales de la operación. El grupo sale con el SLA entre marketing, ventas y CS extendido a los traspasos con finanzas y con la matriz de métricas de RevOps, que indica de qué sistema sale cada número e incluye los indicadores de la integración.

Preguntas frecuentes

¿Qué es la integración entre CRM y ERP?

Es la conexión que hace circular los datos comerciales del CRM y los datos fiscales y financieros del ERP sin volver a digitarlos. Incluye el sistema maestro de cada dato, la dirección y la frecuencia de cada flujo, la clave que une los registros y el tratamiento de errores. El conector es la parte técnica que ejecuta esos acuerdos.

¿Qué datos deben ir del CRM al ERP?

Del CRM al ERP van el cliente con sus datos de registro y el pedido generado por el negocio ganado, con artículos, precio negociado y condición de pago. Del ERP al CRM vuelven el código del cliente, el catálogo y la lista de precios, la situación del pedido, las facturas emitidas, las cuentas por cobrar y la consulta de inventario.

¿El cliente se registra en el CRM o en el ERP?

En los dos, con dueños distintos en momentos distintos. El CRM es dueño de la empresa mientras es prospecto, y el ERP asume los datos fiscales cuando finanzas aprueba el registro, momento en que esos campos quedan solo de lectura en el CRM. Cada sistema guarda la clave del otro.

¿Conector nativo, plataforma o desarrollo a medida: cuál elegir?

Elige la opción más simple que cubra todas las filas de la tabla de flujos con disparador, equivalencias y tratamiento de errores. El conector nativo sirve cuando el proceso es cercano al estándar, la plataforma de integración cuando hay reglas propias o más de dos sistemas, y el desarrollo a medida cuando el ERP o el volumen superan lo que cubren las herramientas.

¿Cómo evitar pedidos duplicados en la integración?

Usa el identificador del negocio en el CRM como referencia del pedido en el ERP y configura la integración para buscar esa referencia antes de crear. Así, un mensaje reenviado actualiza el pedido existente en lugar de crear otro. Incluye ese escenario en la homologación.

¿Cómo preparar al equipo para usar la integración entre CRM y ERP?

Capacita juntos a ventas, finanzas, TI y operaciones de ingresos, recorriendo en el ambiente de pruebas los escenarios de la lista de homologación. Cada perfil aprende qué registra, qué consulta y qué hace cuando la cola muestra un error. Mide por los errores abiertos, el tiempo de corrección y los pedidos creados sin intervención manual.