Integrar CRM y ERP en una pyme: dónde se rompen los datos entre venta, pedido y factura
Dónde se pierden datos entre venta, pedido y factura, y qué alcance mínimo tiene sentido para integrar CRM y ERP en una pyme sin automatizar el error.
El calendario de factura electrónica B2B añade un motivo concreto para revisar cómo pasan los datos de la venta a la factura. La Orden HAC/1028/2026, publicada el 5 de octubre, entró en vigor el día 6 y activa los plazos de aplicación (BOE). Integrar CRM y ERP en una pyme debería comenzar por localizar las diferencias entre lo acordado, lo registrado y lo facturado. Un conector aporta valor cuando transmite una operación que el equipo ya puede explicar.
Seguir una venta desde la propuesta hasta el cobro
El CRM suele reunir oportunidades, contactos y propuestas; el ERP gestiona pedidos, recursos y administración, según su configuración. Para revisar la conexión conviene elegir una operación reciente y reconstruir su recorrido: versión aceptada, pedido, entrega, factura y cobro. Cada paso necesita un identificador que permita relacionarlo con el anterior.
El marco B2B prevé aplicación general desde el 6 de octubre de 2027 para quienes hayan superado ocho millones de euros de volumen de operaciones en el año natural anterior y desde el 6 de octubre de 2028 para el resto, dentro de su ámbito y excepciones (BOE, Real Decreto 238/2026). Ese calendario no obliga por sí solo a conectar todo el CRM: exige preparar los datos y el circuito de facturación que corresponda.
Conviene separar esta obligación de los requisitos de los sistemas informáticos de facturación. A fecha de 9 de octubre de 2026, Hacienda ha anunciado la previsión de aplazar obligaciones pendientes del Reglamento SIF hasta octubre de 2028 (Ministerio de Hacienda). El anuncio debe distinguirse de su aprobación normativa; la planificación necesita contrastar el calendario legal aplicable.
Los tres puntos donde suelen romperse los datos
El primer punto es la identidad del cliente. Una marca comercial puede tener varias sociedades, direcciones de entrega o contactos. Si cada equipo crea una ficha distinta, el pedido puede asociarse a la entidad equivocada aunque el nombre resulte familiar. La coincidencia por nombre no sustituye una identificación controlada.
El segundo aparece al convertir la oferta en pedido: referencias, cantidades, descuentos, transporte y condiciones de pago pueden cambiar durante la negociación. Copiar una propuesta anterior deja un importe coherente con un documento que ya no representa el acuerdo.
El tercero está entre entrega, factura y cobro. Una entrega parcial puede requerir facturación distinta de la propuesta inicial. Un pedido aceptado no demuestra que todo se haya entregado ni que la factura esté pagada. Los estados deben representar hechos diferentes y conservar sus relaciones.
Quién responde de cada dato antes de decidir qué sistema manda
La empresa necesita asignar responsables antes de fijar la dirección del intercambio. Comercial valida el alcance y la versión aceptada; operaciones confirma qué puede entregarse; administración comprueba identidad fiscal, impuestos y condiciones de facturación. Esta distribución es una propuesta y debe ajustarse a la organización.
Para cada campo se define dónde se crea, quién puede modificarlo y qué ocurre después de aprobarlo. Un cambio de dirección fiscal no debería propagarse del mismo modo que una nota de seguimiento. Tampoco conviene sobrescribir documentos emitidos como si fueran borradores.
La regla puede quedar en una matriz breve: dato, responsable, sistema de referencia, validación y tratamiento de cambios. Cuando dos sistemas discrepan, esa matriz permite resolver el conflicto con evidencia, evitando que prevalezca simplemente la última actualización.
Cuándo sincronizar resuelve el problema y cuándo solo lo copia más rápido
Sincronizar ayuda cuando se repite una carga manual bien definida: trasladar un pedido aprobado o devolver su estado al equipo comercial. Si el precio todavía depende de acuerdos que nadie registra, la integración transmitirá antes una información incompleta.
Hay que comprobar la documentación oficial de las versiones y planes contratados: permisos, campos, límites, autenticación y mecanismos disponibles para comunicar cambios. Que ambos productos anuncien una API no garantiza que el intercambio previsto sea viable. También deben contemplarse las restricciones del proveedor y la conservación de registros.
El diseño necesita detectar duplicados, registrar errores y permitir reintentos controlados. Un corte de conexión no debe generar un segundo pedido al recuperar el servicio. Si una operación falla, el equipo necesita saber qué quedó pendiente y quién debe resolverlo.
Un caso simulado: un pedido registrado tres veces con tres importes
Este escenario es completamente simulado. Una pyme vende diez equipos a 1.000 € cada uno y acuerda un descuento del 10%, más 200 € de transporte. Se supone un IVA del 21% para ilustrar el cálculo; el tratamiento fiscal real depende de la operación.
| Registro simulado | Base sin IVA | Total con IVA |
|---|---|---|
| Oferta aceptada con descuento y transporte | 9.200 € | 11.132 € |
| Pedido que omite el descuento | 10.200 € | 12.342 € |
| Borrador de factura que omite el transporte | 9.000 € | 10.890 € |
El pedido supera en 1.210 € el total aceptado y el borrador de factura queda 242 € por debajo. No son tres ventas diferentes: son tres representaciones incompatibles de una misma operación. Automatizar cualquiera de ellas sin validar el acuerdo mantendría el problema.
La revisión debe identificar la versión aceptada, corregir el pedido y preparar el documento correspondiente por el procedimiento autorizado. Si una factura ya se ha emitido, su corrección sigue el circuito de facturación aplicable. La integración necesita enlazar identificadores y preservar el historial.
Qué alcance mínimo tiene sentido en una primera sincronización
Un primer alcance puede limitarse a clientes validados, pedidos aprobados y devolución de estado. La oportunidad permanece en el CRM; el ERP recibe únicamente lo necesario para tramitarla. Los campos elegidos deben tener significado común, incluidos moneda, unidades e impuestos.
El piloto debe probar cambios de cantidad, cancelaciones, entregas parciales, reintentos y clientes con varias direcciones. Conviene empezar con operaciones supervisadas y establecer qué ocurre si el conector deja de funcionar. Un procedimiento temporal documentado permite continuar sin perder la conciliación.
La aprobación comercial debe preceder al envío cuando corresponda. Emitir facturas o modificar condiciones económicas requiere controles propios; no debería quedar activado solo porque técnicamente es posible conectar los sistemas.
Medir la mejora en errores, plazos y conciliación
La línea base puede recoger pedidos recapturados, discrepancias de importe, documentos corregidos y tiempo desde aceptación hasta registro. Cada indicador necesita una definición estable y un volumen de operaciones comparable.
También hay que medir pendientes de sincronización, antigüedad de los errores y tiempo de resolución. Una integración que reduce la carga manual pero acumula incidencias invisibles puede desplazar el trabajo hacia una conciliación posterior más costosa.
Ordenar los trabajos según lo que cuesta cada error
La prioridad debería considerar frecuencia, impacto económico y dificultad de detección. Un error poco frecuente que factura a otra sociedad puede merecer atención antes que una duplicación habitual de notas comerciales.
Integrar CRM y ERP en una pyme da resultado cuando el presupuesto cubre revisión del proceso, limpieza de datos, desarrollo, pruebas y mantenimiento, y cuando la empresa prioriza según lo que cuesta cada error de sincronización. La factura electrónica refuerza la necesidad de trazabilidad, pero la mejora real empieza por poder explicar una venta completa de principio a fin; solo entonces conviene automatizar el tramo que ya tiene responsables y reglas verificables.
