Conciliación bancaria automática en gestorías: qué puede automatizarse y qué debe revisar una persona

El banco ya está sincronizado. El trabajo no ha terminado.

Una gestoría puede tener los movimientos bancarios importados cada mañana y seguir dedicando horas a comprobar cobros, pagos, facturas, comisiones y diferencias. La sincronización elimina una tarea concreta: descargar y cargar información. No resuelve por sí sola qué significa cada movimiento.

Ahí aparece la conciliación. El movimiento bancario tiene que relacionarse con una realidad contable: una factura de cliente, una factura de proveedor, un pago registrado, una transferencia interna, una comisión, una remesa o cualquier otra contrapartida válida.

La diferencia parece pequeña, pero cambia por completo el diseño de la automatización. En una gestoría que ya automatiza parte de su operativa, traer el banco es solo la entrada del proceso. La decisión importante viene después: qué evidencia hace falta para dar una coincidencia por buena.

Importar no es conciliar: cinco capas distintas

Separar el proceso en capas evita que todo se etiquete como “conciliación automática”. Cada una resuelve un problema distinto.

La primera capa puede llegar desde una sincronización bancaria, un proveedor autorizado, un fichero o una integración del propio software contable. La segunda limpia el dato. La tercera busca candidatos. La cuarta toma una decisión. La quinta reconoce que esa decisión todavía no puede tomarse con seguridad.

Ese último estado es fundamental. Un sistema serio no está obligado a encontrar una respuesta para todo. También tiene que saber dejar algo abierto.

La escalera de confianza: no todos los matches merecen el mismo nivel de autonomía

Una automatización útil puede trabajar con cuatro niveles. No hace falta asignarles un porcentaje universal; cada gestoría puede definir sus propios umbrales y condiciones según el software, los clientes y el tipo de movimiento.

El beneficio de este enfoque es que la automatización deja de medirse por una cifra de “conciliación automática” aislada. Importa mucho más qué tipos de movimiento resuelve y con cuántas correcciones posteriores.

Qué coincidencias suelen ser buenos candidatos para automatizar

Hay movimientos donde las evidencias encajan de forma tan clara que la revisión manual aporta poco valor. Por ejemplo, un cobro contiene una referencia única de factura, coincide el importe, el cliente es el esperado y la factura sigue abierta.

Otros patrones también pueden automatizarse cuando están bien definidos:

• Cobros de factura con referencia inequívoca e importe compatible.
• Pagos a proveedores con tercero, documento e identificadores coherentes.
• Transferencias internas entre cuentas propias reconocidas.
• Comisiones bancarias con un patrón estable y una regla contable aprobada.
• Remesas cuando existe un identificador que permite reconstruir su composición.
• Movimientos recurrentes asociados a reglas ya validadas.
• Pagos ya enlazados desde una plataforma o ERP mediante identificadores fiables.

Ninguna de esas señales debería analizarse de forma aislada. Una referencia fuerte puede pesar más que una descripción bancaria genérica. El importe ayuda, pero no identifica por sí solo una factura. La cuenta de origen puede reforzar una coincidencia, pero tampoco garantiza que el movimiento corresponda al documento que parece.

La solución funciona mejor cuando acumula evidencias y puede explicar por qué ha encontrado un candidato.

Siete excepciones que parecen pequeñas hasta que empiezan a acumularse

La conciliación real se complica justo donde desaparece la relación uno a uno. Estos casos merecen una ruta específica.

El error más peligroso sería intentar vaciar esa lista a cualquier precio. Una cola pequeña de movimientos pendientes es mejor que una contabilidad aparentemente limpia construida sobre coincidencias débiles.

Reglas antes que IA

Una buena parte de la conciliación no necesita un modelo generativo. Los propios ERPs modernos ya trabajan con reglas de coincidencia y modelos de conciliación. Odoo 19, por ejemplo, documenta matching con referencias, partner, importe y modelos automáticos o manuales para flujos recurrentes.

Ese enfoque tiene una ventaja importante: cuando la regla se cumple, sabemos por qué se ha cumplido.

La IA sí puede aportar valor donde el texto viene mal estructurado. Un concepto como “TRF REC CLIENTE 0045 FACT MARZO” puede necesitar normalización. También puede ayudar a relacionar un descriptor bancario con un tercero conocido o a ordenar candidatos.

Pero hay una diferencia importante entre proponer una correspondencia y crear el asiento correcto. Cuanto más se acerque el sistema a la escritura contable definitiva, mayor debe ser la calidad de la evidencia y más explícita la política de validación.

Casos que parecen fáciles y no lo son

Dos facturas de 1.250 €. Llega una transferencia por 1.250 €. Importe correcto, mismo cliente y fechas próximas. Sin una referencia adicional, el sistema tiene dos candidatos razonables. No existe motivo para elegir uno al azar.

Tres facturas, un único ingreso. El cliente paga 4.820 € y esa cifra es exactamente la suma de tres documentos. El match puede ser muy sólido, pero el motor tiene que saber trabajar con combinaciones, no solo con igualdad uno a uno.

Factura de 1.000 €, ingreso de 997,50 €. Los 2,50 € pueden ser una comisión, una diferencia acordada, un redondeo o un error. El sistema puede reconocer un patrón conocido; no debería inventar la causa.

Devolución semanas después. El nuevo movimiento no se entiende bien sin el historial. Puede exigir reabrir un estado, vincularlo al cobro original o iniciar otra tarea.

Estos ejemplos explican por qué el diseño de excepciones importa tanto como el matching.

Open banking puede traer los movimientos. Sigue sin decidir qué significan.

PSD2 introdujo en Europa un marco específico para los servicios de información sobre cuentas. Un proveedor autorizado puede prestar ese servicio sobre cuentas accesibles online, con consentimiento explícito del usuario y limitado a las cuentas y transacciones designadas.

Eso facilita una parte del proceso: disponer de información bancaria sin que alguien descargue un fichero de cada entidad. No convierte la conexión bancaria en un motor de conciliación.

También conviene separar dos conceptos que PSD2 trata de forma distinta:

• Servicio de información sobre cuentas. Accede a información de cuentas y movimientos para ofrecerla de forma agregada o utilizarla en el servicio solicitado.
• Servicio de iniciación de pagos. Permite iniciar una orden de pago a petición del usuario.

Esta entrada se ocupa del primer terreno: lectura y tratamiento de movimientos para conciliarlos. No proponemos mezclar esa lógica con ejecución de pagos. Si una gestoría quisiera automatizar pagos, sería otro proyecto, con otros permisos, riesgos y controles.

El Banco de España mantiene un registro de entidades autorizadas o registradas para prestar servicios de información sobre cuentas. No tiene sentido plantear una arquitectura basada en guardar credenciales bancarias en un workflow propio cuando existen mecanismos regulados para acceder a esa información.

Arquitectura técnica: de la transacción bancaria a una decisión trazable

El flujo puede montarse de formas distintas según el software contable y el proveedor bancario. La arquitectura lógica, sin embargo, suele necesitar las mismas piezas.

1. Fuente bancaria. Sincronización del ERP, proveedor de información sobre cuentas, fichero o integración autorizada.
2. Ingestión. Cada movimiento recibe un identificador y se controla que no entre dos veces.
3. Normalización. Fecha, importe, moneda, concepto, referencia, cuenta y contraparte quedan en un formato consistente.
4. Datos contables. El sistema consulta facturas, pagos, terceros, estados y cuentas del ERP o software contable.
5. Motor de reglas. Prueba coincidencias exactas, referencias, ventanas temporales y modelos recurrentes.
6. IA opcional. Interpreta texto variable, propone candidatos o clasifica excepciones.
7. Scoring de confianza. Registra qué evidencias soportan la propuesta.
8. Staging. Mantiene propuestas antes de escribir cuando el riesgo lo aconseja.
9. Salida. Conciliación automática autorizada o cola de revisión.
10. Auditoría. Queda rastro de qué regla, usuario o sistema tomó la decisión.

El patrón de staging y validación que utilizamos en automatización documental para gestorías encaja especialmente bien aquí. Antes de convertir una interpretación en un cambio contable definitivo, puede existir una capa intermedia donde se comprueba la evidencia.

La arquitectura debe adaptarse al software que utiliza cada despacho. No todas las plataformas ofrecen las mismas APIs, sincronizaciones bancarias o niveles de automatización, y esas capacidades cambian con el tiempo.

La cola de excepciones es el verdadero puesto de trabajo del equipo

Si la automatización elimina los movimientos obvios, el profesional no debería entrar a una pantalla con todo el extracto. Debería ver una lista pequeña de casos que necesitan una decisión.

Cada excepción debería mostrar suficiente contexto para resolverla sin abrir cinco aplicaciones:

• Movimiento bancario.
• Candidatos encontrados.
• Referencia y tercero detectados.
• Diferencia de importe.
• Documento o información que falta.
• Evidencias a favor y en contra.
• Motivo por el que el sistema no ha conciliado.
• Acciones disponibles: seleccionar, dividir, dejar abierto, solicitar soporte o escalar.

Esta cola también sirve para mejorar el sistema. Si todos los meses aparecen veinte movimientos iguales que terminan resolviéndose de la misma manera, probablemente ya existe material suficiente para crear una regla nueva. La automatización madura cuando convierte excepciones repetidas en procesos explícitos.

Una gestoría concilia para muchos clientes: los permisos no pueden mezclarse

En una empresa que concilia sus propias cuentas hay un único perímetro. En una gestoría, el sistema puede trabajar con decenas o cientos de clientes. Ese cambio obliga a tratar la segregación como parte central de la arquitectura.

• Cada conexión bancaria debe quedar asociada al cliente y cuenta correctos.
• Los tokens y permisos no deben reutilizarse entre clientes.
• El componente que solo necesita leer movimientos no necesita capacidad para iniciar pagos.
• Los usuarios internos deben ver únicamente las carteras que les corresponden.
• Los logs tienen que permitir saber qué ocurrió en cada cliente.
• Los datos bancarios no deberían copiarse a sistemas que no los necesitan.
• Si una IA analiza conceptos, debe recibir los campos estrictamente necesarios para esa función.

Minimización y exactitud importan además cuando interviene IA. Si el sistema propone una correspondencia a partir de un descriptor bancario, tanto los datos de entrada como la salida generada deben ser adecuados para la finalidad. Guardar más información no hace automáticamente mejor el matching.

Cómo lanzaría un piloto sin poner la contabilidad en manos del algoritmo

El piloto debería empezar en modo conservador. Antes de automatizar conciliaciones, conviene comprobar cuántos casos se resuelven con reglas y qué tipos de excepción aparecen de verdad.

1. Elegir uno o dos clientes con volumen suficiente y casuística conocida.
2. Importar y normalizar movimientos sin escritura automática.
3. Medir reglas simples. Referencia, importe, tercero, estado y patrones recurrentes.
4. Definir qué coincidencias pueden cerrarse sin intervención.
5. Crear la cola de excepciones.
6. Medir falsos positivos y falsos negativos.
7. Introducir IA solo donde haga falta por variabilidad de texto o dificultad de ranking.
8. Activar escritura automática únicamente para niveles aprobados.
9. Revisar correcciones posteriores.
10. Ampliar a más clientes cuando permisos, soporte y trazabilidad estén estabilizados.

Para medir si una automatización funciona, las métricas deberían mostrar algo más que “porcentaje automático”. Conviene medir movimientos procesados, coincidencias deterministas, reglas recurrentes, propuestas aceptadas, excepciones, tiempo medio de revisión, movimientos abiertos al cierre y conciliaciones que tuvieron que corregirse.

Conclusión: automatizar lo claro y hacer visible lo dudoso

La conciliación bancaria automática funciona mejor cuando deja de perseguir una cifra del 100 %. Hay movimientos que pueden resolverse con reglas sólidas y otros que necesitan contexto, documentos o criterio profesional.

El salto de productividad aparece cuando esos dos grupos dejan de mezclarse. Los casos claros desaparecen de la cola y los casos dudosos llegan al contable con candidatos, evidencias y motivo de excepción.

En ese modelo, la IA tiene un papel útil pero concreto. Ayuda a entender lo variable. No sustituye una referencia única, un dato maestro correcto ni una regla contable bien definida.

El resultado no es una gestoría que “deja la conciliación a la IA”. Es un despacho donde las personas dejan de revisar una y otra vez los movimientos que el sistema ya puede demostrar.