Casi todas las evaluaciones de software de automatización tienen el mismo momento. En la tercera o cuarta diapositiva aparece una pared de logos: tu ERP, tu banco, tu CRM, tu correo, tu almacenamiento en la nube y doscientos más. La frase que lo acompaña suele ser alguna variante de "se conecta con todo".
Es una pregunta razonable de hacer. Si la herramienta no puede leer ni escribir en tus sistemas, no sirve. Pero la respuesta a "¿se conecta?" solo te dice que los datos pueden moverse. No te dice nada sobre lo que pasa cuando la factura no coincide con la orden de compra por un 2%, cuando el proveedor aparece dos veces en el maestro o cuando un pago necesita la aprobación de alguien que está de vacaciones.
Y ahí, no en el conector, es donde se ganan o se pierden los proyectos de automatización financiera.
1. Lo que un conector realmente resuelve (y lo que no)
Un conector hace tres cosas: se autentica contra un sistema, lee o escribe registros y traduce campos de un formato a otro. Es transporte. Hace diez años eso era difícil y caro; hoy es, en buena medida, un commodity. Muchas plataformas lo hacen bien.
Lo que un conector no resuelve es el significado del proceso: qué campo es la fuente de verdad, qué tolerancia aplica a cada tipo de gasto, qué se hace cuando la referencia bancaria llega truncada, quién decide en cada caso dudoso y qué evidencia va a pedir el auditor. Eso no viene en el catálogo de integraciones.
2. Por qué la amplitud se vende primero
No hay mala fe en esto; hay una razón estructural. La amplitud es fácil de demostrar (un logo es un logo), fácil de contar (cuatrocientos es más que doscientos) y fácil de comparar en una planilla de RFP. La profundidad, en cambio, solo se puede demostrar con tus datos y tus excepciones, y eso no cabe en una demo de cuarenta minutos.
Además, una plataforma horizontal tiene que servir a miles de empresas en industrias distintas. Es lógico que optimice para lo que todas comparten —el transporte— y deje lo específico en manos de quien la implementa. Es una decisión de diseño legítima. El punto es que el trabajo de profundidad no desaparece: se traslada a tu equipo o a un integrador. La pregunta útil es si sabías que estabas comprando eso.
"Un conector te dice que dos sistemas pueden hablar. No te dice si saben qué decirse."
3. Dónde se nota la diferencia: un ejemplo en cuentas por pagar
Toma el cruce a tres vías: factura, orden de compra y recepción. En la demo, una factura limpia llega por correo, se lee, se cruza con la OC en el ERP y se aprueba. Funciona. Se conecta con todo.
Ahora piensa en lo que llega un martes cualquiera:
- Una factura con tres líneas contra una OC de dos, porque el proveedor desglosó el flete.
- Una recepción parcial: llegó el 60% de la mercadería y la factura viene por el total.
- Un proveedor dado de alta dos veces con identificadores distintos, algo que explicamos en por qué los pagos duplicados son un problema de datos antes de ser un problema de IA.
- Una factura en otra moneda, con tipo de cambio de una fecha distinta a la de la OC.
- Una tolerancia que debería ser distinta para insumos que para servicios profesionales.
Todas las herramientas del mercado pueden leer esas facturas. La diferencia está en si alguien identificó estos casos antes del piloto y definió, para cada uno, un comportamiento explícito: procesar automáticamente, desviar a una persona o bloquear. En la práctica, la mayor parte del trabajo de diseño de un proceso financiero automatizado suele estar ahí, en las excepciones, no en el camino feliz.
4. Reformular la pregunta
No se trata de dejar de preguntar por integraciones, sino de hacer primero las preguntas que revelan profundidad. Algunas reformulaciones concretas:
| Pregunta de amplitud | Pregunta de profundidad |
|---|---|
| "¿Se conecta con nuestro ERP?" | "¿Qué hace cuando la factura y la OC en nuestro ERP no coinciden?" |
| "¿Lee PDFs?" | "¿Qué hace con un PDF escaneado torcido o con dos facturas en el mismo archivo?" |
| "¿Tiene flujo de aprobaciones?" | "¿Quién define los umbrales, quién puede cambiarlos y dónde queda registrado?" |
| "¿Es no-code?" | "¿Quién mantiene la lógica cuando el proceso cambia, y con qué documentación?" |
| "¿Cuánto tarda la implementación?" | "¿Cuánto tarda en procesar bien nuestros datos reales, incluidas las excepciones?" |
Una señal útil: observa si quien te presenta la solución te pregunta por tus excepciones antes de mostrarte la herramienta. Quien entiende un proceso a fondo sabe dónde se rompe y quiere saber cómo se rompe el tuyo.
5. Cuándo la amplitud sí es la pregunta correcta
Para ser justos: hay escenarios donde la cantidad de conectores es exactamente lo que importa.
- Sincronizar datos estructurados entre sistemas modernos. Si necesitas que los clientes del CRM aparezcan en el ERP con los mismos campos, el problema es de transporte y una plataforma de integración amplia es la herramienta adecuada. Lo desarrollamos en RPA, iPaaS o agentes de IA: qué te están vendiendo realmente.
- Muchos flujos simples en lugar de uno crítico. Notificaciones, copias de archivos, recordatorios: tareas con poca lógica y bajo riesgo.
- Un equipo interno con capacidad de construir la profundidad. Si tienes gente que conoce el proceso y sabe modelar sus reglas, una plataforma amplia puede ser una buena base.
La amplitud no es un defecto. Simplemente no es la primera pregunta cuando el proceso involucra juicio, dinero y una auditoría al final.
Un orden práctico para tu próxima evaluación
- Elige un proceso concreto. No "automatizar finanzas", sino "cruce a tres vías de facturas de proveedores nacionales". Idealmente, uno representativo y no solo el más fácil, como planteamos en lo que los equipos de finanzas hacen mal al empezar en pequeño.
- Documenta sus excepciones antes de hablar con proveedores. Las diez más frecuentes, con un ejemplo real de cada una. Este documento vale más que cualquier RFP.
- Lleva esos casos a la demo y pide que los procesen. Con tus datos, no con los del proveedor. Si no es posible en una demo, que sea en un piloto acotado.
- Recién entonces, verifica conectores. No "¿cuántos tienen?", sino "¿llegan a los sistemas que este proceso necesita?".
- Evalúa cómo se gobierna. Qué decisiones requieren aprobación, quién puede cambiar las reglas y qué evidencia queda. Las cinco pruebas de la diferencia real entre un dashboard y un control sirven aquí.
La lista de conectores responde si algo es posible. La profundidad responde si va a funcionar el día de cierre, con la factura que nadie esperaba. Si quieres contrastar la lista de excepciones de tu proceso con alguien que ya ha recorrido varias, escríbeme.