Conciliación Bancaria Automática

¿Qué hace este flujo y qué problema resuelve?

Problema operativo: los equipos de tesorería dedican horas cada día a localizar manualmente la correspondencia entre movimientos bancarios y facturas del ERP. Ese trabajo repetitivo genera retrasos en el cierre contable, errores de imputación y una visibilidad deficiente del efectivo disponible.

Qué hace este flujo: automatiza la conciliación bancaria diaria mediante un proceso orquestado en n8n que descarga el extracto bancario (vía API PSD2/Open Banking o MT940), normaliza los movimientos, consulta facturas pendientes en el ERP, aplica reglas de matching y actualiza el estado en el ERP. Los movimientos que no cumplen reglas quedan en un reporte de excepciones para revisión humana.

Beneficio directo: reducir el esfuerzo manual al concentrar la revisión solo en excepciones. En entornos con volúmenes medios (50-1.000 movimientos diarios) puede automatizarse el 80-95% de las conciliaciones, acelerando el cierre y reduciendo errores de imputación.

Resumen técnico ejecutivo:

• Entrada: extracto bancario MT940 o payload PSD2 (pagos/abonos)
• Proceso: parseo → normalización → matching con reglas configurables → actualización en ERP → reporte de excepciones
• Salida: facturas marcadas como cobradas/pagadas, asiento propuesto y reporte de excepciones por email

Cuadro de responsabilidades breves:

• CFO/Director Financiero: define tolerancias, regla de prioridad (importe exacto, referencia, fecha), valida excepciones críticas
• Tesorería: revisa excepciones y valida ajustes contables
• IT: implementa conexiones API/MT940, mantiene n8n en infraestructura segura y desarrolla reglas de matching

Ejemplo breve: InnovaLogis S.A. automatiza la descarga MT940 a las 08:00, aplica reglas que priorizan coincidencia de referencia alfanumérica y tolerancia de importe ±1%, y reduce el tiempo de conciliación de 3 horas a 20 minutos diarios.

Cuándo usar este flujo

Prerrequisitos

Prerrequisitos técnicos:

• Acceso a extractos bancarios: API PSD2/Open Banking con alcance de movimientos o exportación MT940 programable. Para MT940, debe existir canal SFTP o correo con adjunto automatizable.
• Acceso al ERP: API REST para consultar facturas pendientes y actualizar estado, o credenciales de lectura segura a la base de datos (solo para IT). Se recomienda un servicio intermedio con endpoints de consulta y actualización.
• n8n desplegado: recomendable n8n self-hosted dentro de la red corporativa o en VPC privada. Configurar TLS, autenticación y almacenamiento cifrado para credenciales.
• Política de seguridad: listado de cuentas bancarias permitidas, control de acceso por roles, registro de auditoría y políticas de retención de logs.

Prerrequisitos organizativos:

• Reglas de matching definidas por finanzas: tolerancia de importe, prioridad de campos (referencia, NIF, concepto), ventana temporal de coincidencia (por ejemplo ±3 días), y tratamiento de cobros parciales.
• Acuerdo del proveedor ERP para habilitar endpoints o proporcionar dumps periódicos con facturas pendientes.
• Plan de contingencia: proceso manual documentado mientras se ajustan reglas y se depuran excepciones iniciales.

Checklist mínimo antes de arrancar:

• Credenciales API bancaria y lista de IBANs/IDs bancarios autorizados.
• Endpoint y credenciales del ERP con permisos de consulta/actualización.
• Servidor n8n configurado con certificados y acceso interno.
• Contacto de tesorería y administrador ERP para pruebas y validación.

Ejemplo: Para Papelera Norte S.L., IT debe obtener del banco el endpoint PSD2 y del ERP un endpoint REST /invoices/pending con parámetros ?status=pending&company_id=[COMPANY_ID].

Descarga del extracto bancario

Explicación del paso:

La primera etapa garantiza obtener el extracto diario en un formato estructurado. Si el banco ofrece PSD2, se hace una llamada API para listar movimientos. Si solo existe MT940, se descarga el archivo, se valida su integridad y se pasa al parser MT940. Este paso debe ejecutarse en horario fijo (ej. 08:00) y registrar metadatos (fecha de corte, canal, hash del fichero).

Configuración específica de nodos n8n:

• Cron node: programar a las 08:00. Parámetro: '0 8 * * *'.
• HTTP Request (PSD2): método GET, URL 'https://[BANK_API]/accounts/[IBAN]/transactions?from=[FECHA_INICIO]&to=[FECHA_FIN]'. Headers: 'Authorization: Bearer [TOKEN]'.
• FTP/SFTP node (MT940): descargar '/exports/mt940/[CUENTA]/[FECHA].mt940'.
• Function/Code node (parser): si PSD2 devuelve JSON, normalizar campos a {date, amount, currency, description, counterparty, reference, transactionId}. Si MT940, ejecutar parser MT940 con expresiones regulares y convertir a la misma estructura.
• IF node: verificar si la lista está vacía y enviar alerta si no se recibe extracto.

Consideraciones técnicas y de negocio:

• Seguridad: almacenar credenciales en n8n Credentials manager, restringir acceso y usar rotación de tokens. Registrar hashes de archivos MT940 para detectar duplicados o corrupción.
• Latencia: planificar reintentos exponenciales para llamadas a API bancaria; registrar códigos de respuesta y respuesta completa por 7 días para auditoría.
• Formateo: homogeneizar signos de importe (positivo para abono, negativo para cargo) y zona horaria a UTC para coincidencia fiable con ERP.

Ejemplo concreto:

AguaClara Distribuciones programa Cron 08:00. HTTP Request a 'https://api.bankexample.com/accounts/ES9121000418450200051332/transactions?from=[FECHA_INICIO]&to=[FECHA_FIN]' con 'Authorization: Bearer [TOKEN]'. El Function node transforma la respuesta en:

[{ 'date': '2026-07-14', 'amount': 1250.00, 'currency': 'EUR', 'description': 'Pago Fact 2026-0456', 'counterparty': 'Comercial Norte S.L.', 'reference': 'F2026-0456', 'transactionId': 'TX123456' }]

Prompts ready-to-use en n8n (reemplazar variables entre [CORCHETES]):

HTTP Request - URL: 'https://[BANK_API]/accounts/[IBAN]/transactions?from=[FECHA_INICIO]&to=[FECHA_FIN]'
Headers: 'Authorization: Bearer [TOKEN]'
Method: GET

Extracción de facturas pendientes del ERP

Explicación del paso:

Este paso obtiene el conjunto de facturas que pueden coincidir con los movimientos bancarios. Es crítico que la consulta incluya facturas pendientes de cobro/pago dentro de una ventana temporal razonable (por ejemplo, facturas emitidas y vencidas o próximas a vencimiento: -30/+7 días respecto a la fecha del movimiento). Se deben traer campos que faciliten el matching: identificador de factura, importe, moneda, fecha de emisión y vencimiento, referencia de cliente/proveedor (NIF/CIF), y notas o referencias internas.

Configuración específica de nodos n8n:

• HTTP Request node (ERP API): GET 'https://[ERP_DOMAIN]/api/invoices?status=pending&company_id=[COMPANY_ID]&from=[FECHA_INICIO]&to=[FECHA_FIN]'. Headers: 'Authorization: Bearer [ERP_TOKEN]'.
• SQL node (si el ERP no tiene API): Query parametrizada 'SELECT id, invoice_number, net_amount, currency, due_date, party_id, party_vat, reference FROM invoices WHERE status = ''pending'' AND company_id = [COMPANY_ID] AND due_date BETWEEN [FECHA_INICIO] AND [FECHA_FIN];'.
• Set/Function node: normalizar la respuesta a la estructura usada en el flujo: {invoiceId, invoiceNumber, amount, currency, dueDate, partyVat, reference}.

Consideraciones técnicas y de negocio:

• Consistencia: usar snapshot de la BBDD o transacciones para evitar condiciones de carrera si se actualiza el ERP en paralelo.
• Privilegios: el usuario API debe tener solo permisos mínimos (lectura para consulta y escritura limitada para marcación posterior).
• Ventana temporal: ajustar ventana de búsqueda para evitar false positives. Por ejemplo en Compañía Solarix S.A. se usa -60/+15 días por operaciones de leasing que tardan más en registrarse.

Ejemplo concreto:

Consulta para ERP de InnovaLogis S.A.:

HTTP Request - URL: 'https://erp.innova.local/api/invoices?status=pending&company_id=1001&from=[FECHA_INICIO]&to=[FECHA_FIN]'
Headers: 'Authorization: Bearer [ERP_TOKEN]'
Expected output JSON fields: 'invoice_number','net_amount','currency','due_date','party_vat','reference'

El Set node transforma cada registro a:

{ 'invoiceId': 'INV-2026-0456', 'invoiceNumber': '2026-0456', 'amount': 1250.00, 'currency': 'EUR', 'dueDate': '2026-07-01', 'partyVat': 'B12345678', 'reference': 'F2026-0456' }

Algoritmo de matching

Explicación detallada del paso:

El algoritmo de matching aplica reglas jerarquizadas para emparejar movimientos bancarios con facturas. Las reglas típicas, de mayor a menor prioridad, son: 1) coincidencia exacta de referencia + importe; 2) coincidencia de importe y NIF/identificador de contrapartida; 3) coincidencia de importe y proximidad temporal (por ejemplo ±3 días); 4) pagos parciales o múltiples facturas que suman el importe del movimiento.

Configuración específica de nodos n8n:

• SplitInBatches node: iterar sobre movimientos bancarios.
• Function node (JS) - Matching: implementar lógica con prioridades y tolerancia. Entrada: movimiento normalizado y lista de facturas. Salida: objeto con estado 'matched'|'partial'|'unmatched', invoiceId si coincide, score y motivo.
• IF node: rutas según resultado (matched → actualización ERP; partial/unmatched → añadir a lista de excepciones).
• Merge node: consolidar resultados y calcular métricas (tasa automática, importe conciliado).

Consideraciones técnicas y de negocio:

• Tolerancia de importe: definir porcentaje (por ejemplo 1%) o importe absoluto. En contratos con comisiones o diferencias cambiarias usar regla con margen mayor.
• Pago parcial: permitir marcar una factura como parcialmente pagada y generar asiento por la parte abonada; registrar saldo pendiente.
• Conciliación múltiple: un movimiento puede corresponder a varias facturas; el algoritmo debe intentar combinaciones (backtracking limitado) hasta un máximo de combinaciones para evitar coste computacional excesivo.
• Auditabilidad: guardar 'score' y 'regla aplicada' para cada match para revisión y entrenamiento posterior de reglas.

Ejemplo concreto con datos:

Movimiento: { 'transactionId': 'TX123', 'date': '2026-07-14', 'amount': 3750.00, 'currency': 'EUR', 'description': 'Pago conjunto F2026-0450, F2026-0451', 'reference': 'GRP-2026-07' }
Facturas candidatas: [INV-0450 amount 1500.00, INV-0451 amount 2250.00, INV-0460 amount 3750.00]
Resultado del Function node: matched with invoices ['INV-0450','INV-0451'], reason: 'suma importes == importe movimiento', score: 0.95

Prompt listo para usar en node Function (reemplazar [VARIABLES]):

// Entrada: items[0].json.transaction, items[0].json.candidateInvoices
const transaction = items[0].json.transaction;
const invoices = items[0].json.candidateInvoices;
// Implementar reglas: referencia exacta, importe exacto, suma combinatoria, NIF match, proximidad fecha
// [INCLUIR LÓGICA COMERCIAL ESPECÍFICA]
return [{ json: { transactionId: transaction.transactionId, result: 'matched', invoices: ['INV-0450','INV-0451'], score: 0.95, rule: 'sum-match' } }];

Actualización del ERP y reporte

Explicación del paso:

Una vez el algoritmo determina coincidencias, el flujo actualiza el ERP para marcar facturas como cobradas/pagadas o parciales, genera asientos sugeridos y produce un reporte consolidado de excepciones. Las acciones en ERP deben ser transaccionales y registradas para auditoría. Además, el flujo notifica por email a tesorería con un resumen y un enlace al tablero de excepciones.

Configuración específica de nodos n8n:

• HTTP Request node (ERP Update): método POST/PUT a 'https://[ERP_DOMAIN]/api/invoices/[INVOICE_ID]/reconcile' con body {'transactionId': '[TRANSACTION_ID]','amount': [AMOUNT_APPLIED],'date': '[DATE]','note':'Reconciled by n8n'} y header 'Authorization: Bearer [ERP_TOKEN]'.
• HTTP Request node (Create Journal): opcional. Enviar asiento sugerido: POST 'https://[ERP_DOMAIN]/api/journals' con payload adaptado a la contabilidad.
• Spreadsheet or S3 node: almacenar reporte CSV/Excel diario con columnas: transactionId,bankDate,amount,currency,invoicesMatched,score,rule,status.
• Email node: enviar resumen a 'tesoreria@[COMPANY].local' con enlace al fichero y al tablero de excepciones.

Consideraciones técnicas y de negocio:

• Atomicidad: cuando se actualizan múltiples facturas por un movimiento, implementar compensación en caso de fallo parcial (rollback lógico) o marcar transacción como pendiente manual.
• Permisos: registrar quién ejecutó la conciliación automática y conservar payload y respuesta del ERP para 7 años según normativa.
• Notificación: clasificar excepciones por gravedad (alta = importe > [UMBRAL_ALTO] o coincidencia baja) y pedir acción directa de un responsable.

Ejemplo concreto:

Movimiento TX123 matcheado con INV-0450 e INV-0451. Se llama:

POST 'https://erp.papeleranorte.local/api/invoices/INV-0450/reconcile'
Body: { 'transactionId': 'TX123', 'amount': 1500.00, 'date': '2026-07-14', 'note': 'Reconciled by n8n - rule sum-match' }
POST 'https://erp.papeleranorte.local/api/invoices/INV-0451/reconcile' ...

Reporte diario almacenado en S3: 's3://reports/conciliacion/2026-07-14_conciliation.csv' y email enviado con resumen: 'Conciliación automática 14-07-2026: 92% conciliado; 8 movimientos en excepciones (ver enlace)'.

Output esperado del flujo

Resultados operativos esperados:

• Tasa de conciliación automática: 80-95% según calidad de referencias en las transferencias.
• Reducción de tiempo de conciliación manual a menos de 30 minutos diarios para revisión de excepciones.
• Reporte diario con métricas y registro de auditoría para cada movimiento.

Formato y ejemplo concreto de output (fila por movimiento):

Campos explicados:

• transactionId: identificador de la transacción bancaria.
• bankDate: fecha registrada por el banco.
• amount/currency: importe estandarizado en la moneda base.
• invoicesMatched: lista de identificadores de facturas conciliadas.
• status: 'matched'|'partial'|'unmatched'.
• score: métrica interna que refleja confiabilidad del match (0-1).
• rule: la regla aplicada para el match.

Salida adicional: fichero CSV/Excel con resumen y JSON de auditoría con payloads originales de banco y ERP por transacción. Ejemplo de enlace al informe: 'https://reports.internal/conciliacion/2026-07-14_conciliation.csv'.

Problemas frecuentes y cómo resolverlos

Listado de errores comunes con síntoma, causa y solución:

1. Síntoma: No se descargan extractos en la ejecución programada.
   Causa: Token API bancario expirado o IP bloqueada por el proveedor.
   Solución: Renovar token, verificar rotación automática de credenciales y permitir la IP del servidor n8n en la whitelist del banco. Añadir retry con backoff y alertas al administrador.
2. Síntoma: Alta tasa de 'unmatched' pese a que facturas existen.
   Causa: Discrepancia en formato de referencia (prefijos, guiones, espacios) o diferencias de signo en importes por comisiones.
   Solución: Normalizar referencias (eliminar espacios/prefijos comunes) en el parser; incrementar tolerancia del importe o establecer reglas específicas para comisiones y cargos bancarios.
3. Síntoma: Actualizaciones parciales en el ERP; algunas facturas marcadas y otras no tras un mismo movimiento.
   Causa: Fallo transaccional o permisos insuficientes para escribir múltiples registros en una operación.

Solución: Implementar mecanismo de compensación: si alguna actualización falla, revertir las ya aplicadas o marcar la transacción como 'pendiente manual' y notificar. Revisar permisos API.
4. Síntoma: Falsos positivos en matches por suma combinatoria que coinciden por azar.
   Causa: Combinaciones permitidas demasiado amplias o falta de condiciones adicionales (NIF, referencia).

Solución: Limitar combinaciones permitidas (ej. máximo 3 facturas) y exigir coincidencia adicional (como NIF o palabras clave en la descripción) para validar suma-match. Registrar score y umbral mínimo aceptable.
5. Síntoma: Incumplimiento normativo en registro de auditoría (ausencia de evidencia de cómo se concilió una factura).

Causa: No se almacenaron payloads de entrada y salida por restricciones de retención de logs.
Solución: Ajustar políticas de retención y almacenamiento cifrado para mantener payloads por el periodo exigido por normativa; incluir metadata mínima que explique la regla aplicada y el operador que aprobó el cambio.

Procedimiento de escalado: definir umbrales de alerta (por ejemplo, >10% unmatched en un día) que disparen revisión por parte de tesorería y soporte IT. Documentar casos recurrentes para ajustar reglas y actualizar el algoritmo.

Adaptaciones del flujo para otros contextos

Adaptaciones comunes para distintos modelos de negocio:

• Pagos masivos (marketplaces): en plataformas con cientos de pagos pequeños, priorizar matching por identificador de operación interno que el marketplace incluye en la referencia. Reducir combinatoria y usar hashing de referencia interna. Ejemplo: MercadoPro S.L. usa 'MP-[ORDER_ID]' en referencia.
• Multimoneda y cambio: cuando hay cobros en divisa distinta a la factura, incorporar conversión con tipo de cambio de la fecha bancaria y tolerancia adicional por redondeos. Ejemplo: Solarix S.A. registra facturas en EUR pero recibe pagos en USD; el algoritmo usa la tasa del banco del día y permite ±0.5% por diferencia de cambio.
• Cobros con plataformas de pago (Stripe, PayPal): estas plataformas generan fees y pagos agregados. Incluir reglas que separen fees y reconozcan 'gross amount' vs 'net amount'. Ejemplo: TiendaX S.L. concilia cargos netos contra facturas y registra fees como gasto.
• Conciliación parcial y anticipos: adaptar para anticipos y notas de crédito que afectan saldos. Permitir marcar facturas como parcialmente pagadas y generar registro de anticipo. Ejemplo: Construcciones Delta S.A. recibe pagos anticipados que se asignan a órdenes de trabajo posteriores.

Consejo ejecutivo: evaluar la variante en un piloto de 1 mes con un subconjunto de cuentas y ajustar reglas antes de desplegar al total de compañías o cuentas bancarias.

¿Qué hacer ahora?

Plan de acción inmediato en 5 pasos para directivos:

1. Validar prerrequisitos: confirmar que el banco y el ERP pueden exponer los datos necesarios y designar contactos técnicos.
2. Pilotar: realizar una prueba de 2 semanas con un volumen representativo (mínimo 500 movimientos históricos) y medir tasa de coincidencia.
3. Definir reglas: tesorería debe aprobar la matriz de reglas (tolerancias, prioridad de campos, tratamiento de parciales).
4. Desplegar infraestructura: garantizar n8n self-hosted en red segura, configurar rotación de credenciales y retención de auditoría.
5. Medir y ajustar: revisar excepciones semanalmente durante el primer mes y ajustar reglas; formalizar SLA de revisión de excepciones.

Contacto de ejemplo interno para inicio de proyecto: Jefe de Tesorería: 'tesoreria@innova.local', Responsable IT: 'it-infra@innova.local'.

Resultado esperado a 90 días: reducción de tiempo de conciliación manual en al menos 70% y mejora en la precisión de cierre contable.