Exportación a ERP: por qué preferimos bloquearla antes que mandarla mal mapeada

Casi todo el software de back-office para transporte trae la misma frase en su página de producto: "se integra con tu ERP". Casi ninguno explica qué pasa la primera vez que esa integración corre contra datos reales — qué campo del layout de tu SAP Business One o tu CONTPAQi mapea a qué cuenta, con qué ejercicio fiscal, con qué estructura de centros de costo. Esa parte, la que de verdad determina si la promesa se cumple, casi nunca se cuenta.

Lo que "se integra con tu ERP" no dice

Cada flota tiene su propio catálogo de cuentas, su propia estructura de pólizas y, casi siempre, un contador que ya decidió cómo quiere ver reflejado cada concepto. Un archivo genérico que "tu ERP ya sabe importar" es una frase que suena bien en una demo y se cae en la primera póliza real: importa, sí, pero a la cuenta equivocada, o sin el desglose que el contador necesita para su declaración.

El resultado de una integración mal mapeada no es un error visible — es una póliza que sí entra al ERP, se ve completa, y está mal. Eso es más caro que si la exportación simplemente no hubiera corrido.

Cómo funciona la exportación cuando la plantilla ya está confirmada

En el piloto, Likida configura y valida junto con el contador de la flota la plantilla exacta para SAP Business One o CONTPAQi: qué cuenta corresponde a cada concepto de gasto, cómo se refleja el anticipo, dónde va la diferencia a favor o en contra del operador. Una vez que esa plantilla queda confirmada, la exportación genera la póliza lista para importar, viaje por viaje, sin que el contador tenga que capturar nada a mano.

Qué necesita el contador para confirmar la plantilla

• El catálogo de cuentas real de la flota, no uno genérico de ejemplo.
• Cómo quiere ver el anticipo del operador: como una cuenta por cobrar, como un fondo revolvente, o como lo que ya usa hoy.
• El criterio de la flota para diferencias — a favor, en contra, y qué pasa con las que quedan pendientes de aclarar.

Qué pasa mientras la plantilla NO está confirmada

Aquí está la parte que la mayoría del software no dice: hasta que esa plantilla queda validada con el contador, Likida no genera una exportación contable como si estuviera lista. La exportación se bloquea, no se manda a medias. Es una decisión de diseño, no una limitación técnica — generar una póliza sin la plantilla confirmada sería fabricar un archivo que se ve terminado y no lo está.

La alternativa —exportar algo genérico "por si sirve"— traslada el riesgo de un mapeo mal hecho al contador, que es exactamente la persona que menos debería absorberlo en silencio.

Por qué esto es distinto de "no se integra"

No integrarse con el ERP y bloquear una exportación hasta que esté bien mapeada son cosas muy distintas, aunque el resultado inmediato —nada sale todavía— se vea igual desde afuera. En el primer caso el problema es que la herramienta no llega a esa capa. En el segundo, la herramienta ya sabe generar la póliza; lo que falta es la confirmación de que el mapeo es el correcto para esa flota específica, y esa confirmación toma minutos con el contador, no meses de desarrollo.

Qué preguntar antes de creer una promesa de integración

• ¿El archivo que genera respeta MI catálogo de cuentas, o uno genérico?
• ¿Quién confirma que el mapeo es correcto antes de la primera exportación real — mi contador, o nadie?
• ¿Qué hace el sistema si el mapeo todavía no está confirmado: manda algo de todos modos, o avisa que falta ese paso?
• ¿Puedo ver una póliza real de ejemplo, con la estructura exacta que va a entrar a mi ERP?

Lo que sí se puede prometer hoy

Una vez confirmada la plantilla, la exportación corre sola, viaje por viaje, sin que nadie vuelva a capturar el mismo dato dos veces. Eso es lo que "sin recaptura" significa cuando se cumple de verdad: no que la integración exista desde el primer día sin que nadie la revise, sino que después de revisarla una vez, deja de pedirle trabajo manual al contador.