Qué deja de hacerse a mano.
- Alta del cliente en ambos sistemas
- Datos fiscales y de facturación
- Presupuestos aceptados
- Emisión de facturas
- Estado de cobro
- Vencimientos e impagos
Ventas y administración necesitan cosas distintas.
El error habitual es intentar que ambos sistemas contengan lo mismo. No hace falta: al comercial le basta con saber si el cliente está al corriente de pago y qué se le ha facturado, y a administración le basta con recibir datos fiscales correctos sin tener que perseguirlos.
Definir esa frontera con precisión es lo que evita una integración pesada que sincroniza de más y acaba generando conflictos entre los dos sistemas.
Dónde suele fallar.
- NIF y razón social incompletos
- Clientes duplicados por nombre
- Series de facturación mal mapeadas
- Impuestos y recargos especiales
- Rectificativas y abonos
- Quién manda en el dato fiscal
Cómo decidimos la vía técnica.
- Conector nativo si existe y basta
Es lo más barato de mantener. Si cubre el caso, no hay razón para construir nada.
- Automatización no-code si hay lógica
Make o n8n cuando hay condiciones, transformaciones o varios pasos encadenados.
- API y webhooks si hay volumen o reglas propias
Cuando el caso es específico, el volumen alto o hace falta control sobre errores y reintentos.
- Siempre con registro de errores
Toda integración falla alguna vez. La diferencia es si te enteras el mismo día o tres semanas después.
Preguntas frecuentes
¿Se pueden emitir facturas desde el CRM?
Se puede desencadenar la emisión en Holded desde el CRM, manteniendo la facturación y la numeración oficial en el sistema contable, que es donde deben estar.
¿Sirve con otro programa de facturación?
Sí. El planteamiento es el mismo con cualquier sistema que tenga API; cambian los campos y los detalles concretos.
¿Qué pasa con los datos fiscales incorrectos?
Se definen validaciones antes de enviar, para que el error se detecte al darlo de alta y no al emitir la factura.