Gestión Automática de Cobros

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

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

Este flujo de n8n automatiza la gestión de cobros recurrentes y la recuperación de facturas vencidas para reducir el trabajo manual del equipo de crédito y mejorar el ciclo de conversión de caja. Identifica facturas morosas, envía recordatorios escalonados, intenta cobros automáticos cuando procede, registra eventos en sistemas contables y CRM, y deriva excepciones al equipo de cobranza. El flujo está diseñado para integrarse con pasarelas de pago, plataformas de facturación y herramientas de comunicación (email/SMS), manteniendo trazabilidad y registros auditables.

Problema que resuelve: muchas organizaciones gestionan cobros de forma manual o semiautomática, lo que genera altos costes operativos, errores, retrasos y falta de seguimiento consistente. El resultado es un aumento del DSO (Days Sales Outstanding), pérdida de liquidez y escalado ineficiente de incidencias de pago. Este flujo reduce intervenciones humanas repetitivas, homogeniza la comunicación con clientes y automatiza las acciones según reglas de negocio (por ejemplo, número de recordatorios, intervalos, límites de importe y políticas de escalado).

• Beneficios operativos: menor carga administrativa, menor tiempo por caso, trazabilidad completa.
• Beneficios financieros: reducción del DSO, mejora del flujo de caja y detección temprana de riesgos crediticios.
• Beneficios de cumplimiento: registros centralizados y control de comunicaciones para auditoría y políticas de protección de datos.

Ejemplo ejecutivo: En la empresa ficticia FinRetail Distribuciones S.A., el equipo de crédito enfrentaba un promedio de 350 facturas vencidas activas mensuales y un DSO de 48 días. Tras implementar este flujo en n8n, FinRetail automatizó la identificación diaria de facturas vencidas, envió comunicaciones escalonadas (email + SMS para cuentas críticas), ejecutó cobros automáticos sobre tarjetas tokenizadas y generó tareas para el equipo de cobranza solo para casos excepcionales. Resultado esperado: reducción del DSO a 32 días y 60% menos intervenciones manuales del equipo de crédito en el primer trimestre.

Ámbito de integración y gobernanza: el flujo opera como una capa de orquestación entre sistemas financieros (ERP, pasarela de pagos), CRM y herramientas de comunicación. Está pensado para operaciones con volúmenes medios a altos, incluyendo controles de idempotencia, límites de reintentos y registros de auditoría. Roles involucrados: CFO (definición de políticas), responsable de crédito (reglas de escalado), IT (conexiones y seguridad) y cumplimiento (protección de datos y trazabilidad).

En síntesis, este flujo transforma un proceso fragmentado y manual en una operación gobernada, repetible y medible que mejora la liquidez y la eficiencia del equipo de cobranza, sin eliminar la intervención humana en escenarios que requieren juicio comercial.

Cuándo usar este flujo

Definición de la matriz de escalado

Definición de la matriz de escalado

La matriz de escalado es el núcleo operativo que determina qué acción tomar según antigüedad de deuda, importe y segmento de cliente. En n8n se implementa como una serie de nodos que evalúan las condiciones y enrutan la ejecución hacia recordatorios, alertas, llamadas o entrega a cobro externo. A continuación se presenta una guía paso a paso con configuración de nodos, un ejemplo práctico con la empresa ficticia FinGestión S.A., problemas frecuentes y variantes para adaptar el flujo a distintos contextos.

Pasos y configuración específica de nodos n8n

1. Lectura de cartera

   Node: Google Sheets (o Airtable/Base de datos).

   1. Resource: 'Spreadsheet'.
   2. Operation: 'Read Range'.
   3. Spreadsheet ID: '1a2B3cFinGestionDemo'.
   4. Range: 'Deudas!A2:E'. (columnas: cliente_id, nombre, email, dias_vencidos, importe)
   5. Return All: true.
2. Cálculo de nivel de escalado

   Node: Function. Lógica clave:

   1. Calcular nivel = función de (dias_vencidos, importe, segmento).
   2. Ejemplo de regla: si dias <=15 -> nivel 0; 16-30 -> nivel 1; 31-60 -> nivel 2; >60 -> nivel 3.
   3. Salida: añadir campo escalationLevel y actionCode para enrutamiento.
3. Decision routing

   Node: Switch o If: evaluar escrowLevel/actionCode y dirigir a los nodos correspondientes.

   1. Regla 1: escalationLevel == 0 -> enviar recordatorio por email.
   2. Regla 2: escalationLevel == 1 -> email + SMS (Twilio node).
   3. Regla 3: escalationLevel == 2 -> asignar tarea a gestor (Webhook a CRM) y notificación interna (Slack/email).
   4. Regla 4: escalationLevel == 3 -> marcar para entrega a agencia (Webhook/HTTP Request a API del partner).
4. Acciones configuradas
   1. Email: Node SMTP / Gmail — Para plantilla use parámetros: subject 'Recordatorio de pago - {{ $json.nombre }}', body con motivo, importe y link de pago.
   2. SMS: Node Twilio — From: '+123456789', To: '{{ $json.phone }}', Body: mensaje conciso con link de pago.
   3. Asignación a gestor: Node HTTP Request — POST a 'https://crm.fingestion.example/api/tasks' con JSON {cliente_id, prioridad, notas}.
   4. Entrega a agencia: Node HTTP Request con autenticación API Key y payload estandarizado.
5. Registro y control

   Node: Set / Google Sheets update para registrar fecha de acción, responsable y resultado.

Ejemplo práctico (FinGestión S.A.)

Reglas definidas para FinGestión S.A.:

Registro de ejemplo para un cliente (Output esperado)

• cliente_id: FG-2025-001
• nombre: Empresa Alpha S.L.
• dias_vencidos: 38
• importe: 4,250.00 EUR
• escalationLevel: 2
• accion: 'Asignar gestor - llamada prioritaria'
• registro_accion.fecha: '2026-07-10'
• registro_accion.responsable: 'Gestor_JPerez'

Problemas frecuentes

Error: Datos incompletos desde la hoja

Síntoma: Filas sin número telefónico o email. Causa: Rango leído incorrecto o filas vacías. Solución: Validar mapa de columnas en el nodo Google Sheets y filtrar registros con campos obligatorios en un nodo Function previo.

Error: Nodos de envío fallan por autenticación

Síntoma: Respuestas 401/403 en nodos SMTP/Twilio/HTTP Request. Causa: Credenciales expiradas o mal configuradas. Solución: Actualizar credenciales en n8n Credentials; probar con nodos de prueba y regenerar API Keys si procede.

Error: Enrutamiento incorrecto

Síntoma: Clientes con 20 días vencidos enviados a nivel 2. Causa: Lógica en Function con operadores inequívocos o tipos de datos string en lugar de numéricos. Solución: Forzar parseInt/parseFloat y escribir pruebas unitarias con casos límite.

Error: Duplicación de notificaciones

Síntoma: Mismo cliente recibe múltiples emails. Causa: Flujo es disparado varias veces por el trigger (ej. trigger por cambio y trigger por horario). Solución: Implementar marca temporal y flag 'ultima_accion' en la fila; antes de enviar, comprobar si ya se ejecutó la acción en las últimas X horas.

Error: Entrega a agencia rechazada

Síntoma: API del partner retorna errores de validación. Causa: Formato de payload no coincide con el contrato. Solución: Revisar especificación del partner, mapear campos requeridos y validar con entorno de sandbox antes de producción.

Adaptaciones para otros contextos

• Sector B2C (volumen alto, importe medio): Priorizar canales automáticos (email + SMS), reducir intervención humana hasta nivel 3; usar segmentación por importe para escalado.
• Sector B2B (grandes importes): Añadir evaluaciones de riesgo financiero y aprobación humana en nivel 1-2; integrar con ERP para bloqueos automáticos de crédito.
• Suscripciones SaaS (recurrencia): En lugar de entrega a agencia, integrar retry de pago automático (Stripe Retry) y comunicar con eventos webhook para gestionar suspensiones de servicio.
• Contexto internacional: Añadir reglas según jurisdicción (períodos legales), localización de mensajes y selección de partner de cobro por país.

Conclusión: Defina reglas claras, traduzca las reglas a condiciones lógicas en un nodo Function, y use Switch/If para enrutamiento. Documente cada nivel en la matriz y registre toda acción para auditoría y mejora continua.

Extracción de facturas vencidas del ERP

Extracción de facturas vencidas del ERP (step2)

Descripción ejecutiva: este paso se encarga de consultar el ERP y extraer el conjunto de facturas cuya fecha de vencimiento haya pasado y que cumplan las reglas de negocio (estado, cliente, importe mínimo). El objetivo es entregar un dataset limpio y normalizado que alimentará los procesos de notificación y gestión de cobros automáticos en los siguientes pasos del flujo n8n.

Configuración recomendada de nodos n8n

1. Cron
   1. Tipo: Cron periódico (diario a las 08:00 o según ventana operativa).
   2. Salida: dispara el flujo cada día hábil.
2. HTTP Request / ERP API
   1. Método: GET.
   2. URL: https://api.erp-ejemplo.com/v1/invoices (o endpoint equivalente del ERP).
   3. Encabezados: Authorization: Bearer <API_TOKEN>, Accept: application/json.
   4. Query params sugeridos: status=issued,pending&due_before={{ $now.toISOString() }}&min_amount=50.00&page=1&page_size=200.
   5. Paginación: implementar bucle con node SplitInBatches o paginar mediante next_page token en un nodo Function que controle hasta agotar resultados.
3. Function - Normalización
   1. Transformar campos: invoice_id, customer_id, customer_name, amount, due_date, currency, status.
   2. Calcular campos derivados: days_overdue = Math.floor((Date.now() - new Date(due_date))/86400000).
   3. Filtrar facturas irrelevantes: amount <= 0, internal_notes contiene ‘test’.
4. IF - Reglas de negocio
   1. Condiciones: days_overdue >= 1 AND status IN (issued, pending) AND amount >= 50.
   2. Ruta true: enviar a la cola de cobros / siguiente paso del flujo.
5. Set / Store
   1. Opcional: guardar resultado en un Storage (e.g., Google Sheets, Airtable, o base interna) para trazabilidad y auditoría.

Substeps técnicos (secuencia práctica)

1. Configurar Cron con ventana operativa.
2. Conectar nodo HTTP Request al endpoint ERP; probar con token de integración.
3. Agregar Function para normalizar nombres y calcular days_overdue; validar con 10 registros de prueba.
4. Insertar nodo IF para aplicar reglas de negocio y ruta de exclusión.
5. Registrar salida en un destino de auditoría y pasar datos al nodo de cola de cobros.

Ejemplo práctico (empresa ficticia)

La financiera ficticia "Financo S.A." emplea este flujo para extraer facturas vencidas de su ERP. Configura el HTTP Request contra https://api.financo-erp.com/v1/invoices con un API token de lectura. Reglas específicas: excluir facturas internas marcadas como "test", considerar overdue desde 1 día, y solo facturas mayores a 100 EUR para acciones automatizadas. Tras la extracción, Financo registra las filas en una hoja de cálculo interna para auditoría antes de pasar a la automatización de llamadas y notificaciones.

Output esperado

Ejemplo de salida tras el nodo de normalización (lista resumida):

Problemas frecuentes

Error: Respuesta 401 o 403 del ERP

Síntoma: HTTP Request devuelve estado 401/403. Causa: token inválido, credenciales caducadas o permisos insuficientes. Solución: renovar token, revisar scopes en el ERP y validar IPs permitidas en el firewall.

Error: Timeout o latencia alta

Síntoma: llamadas API tardan o fallan por timeout. Causa: endpoint bajo carga, límites de rate o mala configuración de tiempo de espera. Solución: implementar retry con backoff exponencial, paginar resultados y coordinar ventanas fuera de pico.

Error: Campos nulos o esquema inesperado

Síntoma: Function falla por new Date(due_date) inválida. Causa: cambio en el contrato API o facturas con formato de fecha distinto. Solución: añadir validaciones defensivas, normalizar formatos y registrar ejemplos erróneos en auditoría para corrección en el ERP.

Error: Duplicados en la downstream (múltiples extracciones)

Síntoma: la misma factura aparece varias veces en el sistema de cobros. Causa: falta de idempotencia o ausencia de control de estado. Solución: mantener marcador de extracción (last_run_timestamp) o campo processed=true en almacenamiento intermedio y usar llave única invoice_id.

Error: Paginación incompleta

Síntoma: número de facturas extraídas inferior al esperado. Causa: mal manejo de next_page o límite de page_size. Solución: implementar bucle de paginación en n8n (SplitInBatches o loop en Function) y verificar header de paginación del ERP.

Adaptaciones y variantes del flujo

• Acceso directo a base de datos: usar nodo PostgreSQL/MySQL para ejecutar una consulta SQL que devuelva facturas vencidas. Útil cuando el ERP no expone API o para integraciones on-premise.
• ERP basado en SOAP o OData: emplear nodo HTTP Request con body XML o usar conector OData; añadir parsing XML en nodo Function o XMLRead para normalizar.
• Multi-tenant: parametrizar Cron y credenciales por cliente; iterar lista de tenants en un nodo Function y ejecutar llamadas en paralelo limitadas por concurrency para respetar límites de cada ERP.
• Escalado a eventos: en vez de Cron, suscribirse a webhooks del ERP que notifiquen facturas vencidas o cambios de estado, reduciendo latencia y carga de consultas periódicas.

Conclusión: diseñe la extracción con tolerancia a errores, registro exhaustivo y controles idempotentes. Validar con datos de prueba de la empresa (por ejemplo, Financo S.A.) antes de poner el flujo en producción.

Enrutamiento por días de retraso

Enrutamiento por días de retraso

Objetivo: definir reglas automáticas en n8n para dirigir facturas al canal de acción adecuado según su antigüedad en mora. El enrutamiento por días de retraso reduce tiempos de gestión, prioriza cuentas críticas y garantiza que los escalados humanos se ejecuten cuando corresponde.

Resumen ejecutivo: implemente un flujo que calcule días de retraso, evalúe rangos predefinidos y dispare acciones diferenciadas (recordatorio por email, llamada de cobranza, notificación de gestor, escalado legal). A continuación se detallan los nodos y la configuración recomendada para un entorno de producción.

Configuración de nodos n8n y pasos

1. Lectura de facturas

   Nodo: 'HTTP Request' o 'Postgres' según origen. Parámetros sugeridos:

   • Credenciales: DB / API con rol de lectura
   • Query: SELECT id, due_date, amount, customer_id FROM invoices WHERE status = 'open'

2. Calcular días de retraso

   Nodo: 'Function'. Código recomendado para calcular días:

   const due = new Date($json['due_date']); const today = new Date(); const diff = Math.floor((today - due) / (1000*60*60*24)); return [{ json: { ...$json, days_overdue: diff } }];

3. Enrutamiento

   Nodo: 'Switch' (Mode: Multiple). Configure condiciones por rango:

   1. Rango 0-3 días: condición: {{$json['days_overdue'] >= 0 && $json['days_overdue'] <= 3}}
   2. Rango 4-15 días: condición: {{$json['days_overdue'] >= 4 && $json['days_overdue'] <= 15}}
   3. Rango 16-30 días: condición: {{$json['days_overdue'] >= 16 && $json['days_overdue'] <= 30}}
   4. Rango >30 días: condición: {{$json['days_overdue'] > 30}}

   Cada salida conecta a nodos de acción específicos (Email/SMS/Human task/HTTP Request a CRM).

4. Acciones por rama

   Ejemplos de nodos a conectar:

   • 0-3 días: 'Send Email' con plantilla de recordatorio automático.
   • 4-15 días: 'Send Email' + 'SMS' y 'Update' al CRM (HTTP Request) marcando prioridad media.
   • 16-30 días: 'Create Task' en herramienta de gestión para gestor de cobranza.
   • >30 días: 'Slack' o 'Microsoft Teams' + 'HTTP Request' a servicio legal (escalado).
5. Persistencia y auditoría

   Conectar cada acción a un nodo 'Postgres' o 'Google Sheets' para registrar la decisión: id, days_overdue, action, timestamp, operator_id.

Ejemplo práctico (empresa ficticia)

FinServ Solutions S.A. opera cuentas B2B. Caso: factura #INV-2025-087, due_date '2026-06-01'. Flujo:

• Lectura: recupera invoice #INV-2025-087
• Function calcula days_overdue = 20
• Switch dirige a rama 16-30 días
• Se crea tarea de cobranza asignada al gestor 'Lucía Ramos' y se actualiza CRM con prioridad 'Alta'

Problemas frecuentes

1) Síntoma: todos los registros caen en la misma rama del Switch

Causa: expresiones mal formuladas o campo days_overdue no calculado correctamente.

Solución: verificar salida del nodo 'Function' con un nodo 'NoOp' o 'Set' intermedio; revisar formato de fecha y tipo numérico.

2) Síntoma: emails no se envían

Causa: credenciales SMTP/Gmail inválidas o límites de envío alcanzados.

Solución: validar credenciales en la sección de credenciales de n8n, revisar logs de proveedor y configurar backoff/colapso de envíos.

3) Síntoma: datos no actualizan el CRM

Causa: endpoint HTTP Request con URL o headers incorrectos, token expirado.

Solución: probar llamada con Postman, actualizar token/credenciales, habilitar reintentos en nodo HTTP Request.

4) Síntoma: rangos de días solapan o quedan huecos

Causa: condiciones del Switch mal definidas (por ejemplo < o <= inconsistentes).

Solución: estandarizar condiciones usando inclusive/exclusive coherente; documentar los rangos; agregar test unitarios con ejemplos de fechas.

5) Síntoma: flujo lento en picos

Causa: consultas masivas sin paginación o llamadas API secuenciales.

Solución: implementar paginación, procesar en lotes y usar nodos 'SplitInBatches' con tamaño controlado.

Adaptaciones sugeridas

• B2C (volumen alto, menor importe): priorizar canales digitales. Variante: 0-7 días email/SMS, 8-30 días notificación push, >30 días llamada automatizada + retención de acceso a servicio.
• Suscripciones recurrentes: integrar con plataforma de pagos. Variante: antes de enrutar a cobro, intentar 'Retry Payment' vía 'HTTP Request' a PSP; sólo escalar si falla 2 intentos.
• Clientes estratégicos: flujo con aprobación humana. Variante: para cuentas marcadas como 'key-account', enviar alerta a gestor y esperar confirmación con un nodo 'Wait for Signal' antes de enviar comunicaciones formales.
• Operaciones internacionales: adaptar a zonas horarias y legislaciones. Variante: calcular días según locale del cliente, y enrutar a equipos regionales usando una tabla de mapeo en 'Lookup' (Postgres o Google Sheets).

Implementando este enrutamiento se logra priorizar recursos, reducir riesgo de litigio y mejorar la experiencia del cliente. Documente siempre las reglas de negocio y mantenga pruebas automáticas con datos ficticios antes de desplegar en producción.

Ejecución de acciones automáticas

En esta sección describimos la ejecución de acciones automáticas en n8n para la gestión de cobros: desencadenado, filtrado, acción sobre cada factura y actualización del sistema. El objetivo es que el flujo actúe de forma autónoma sobre facturas vencidas o próximas al vencimiento y registre las comunicaciones y cambios de estado en el sistema contable.

1. Trigger (Cron o Webhook)
   1. Insertar node Cron o Webhook según preferencia. Configuración recomendada para Cron: frecuencia diaria a las 08:00.
2. Consulta de facturas pendientes
   1. Node: MySQL / PostgreSQL o Google Sheets según almacén. SQL de ejemplo: SELECT id, cliente_email, monto, vencimiento FROM facturas WHERE estado = 'pendiente' AND vencimiento <= DATE_ADD(CURDATE(), INTERVAL 3 DAY);
   2. Salida esperada: lista de registros con campos id, cliente_email, monto, vencimiento, cliente_nombre.
3. Procesado por factura (SplitInBatches)
   1. Node: SplitInBatches: batchSize = 10 para controlar llamadas a API externas y evitar límites.
   2. Node: Set para formatear payloads (plantilla de correo, asunto y variables).
4. Condicionales y rutas de acción
   1. Node: IF / Switch para decidir canal: si cliente.prefiere_sms = true → HTTP Request a proveedor SMS; si cliente.prefiere_email → Email Send.
   2. Node: HTTP Request (pasarela de pagos): Method = POST, URL = https://api.pagodemo.local/v1/links, Headers: Authorization: Bearer {{ $env.PG_API_KEY }}, Body (x-www-form-urlencoded o JSON según proveedor). Usar campo invoice_id y amount.
5. Registro y actualización
   1. Node: HTTP Request / DB Update para actualizar factura: estado = 'recordado' / 'link_enviado', fecha_ultimo_recordatorio = now().
   2. Node: Google Sheets / Airtable / DB Insert para registrar trazabilidad: tipo = correo/sms, destinatario, plantila_id, response_code.

Ejemplo operativo (empresa ficticia): InnovaFin S.A. utiliza este flujo para gestionar facturas B2B. A las 08:00 Cron lanza la consulta al esquema contable en PostgreSQL. Para la factura #F-2026-041 (cliente: Constructora Vega, vencimiento: 2026-07-20, monto: 12,450.00 EUR) el flujo:

Detalles de configuración práctica de nodos clave:

• Email Send: Service = SendGrid; From = 'cobros@innovafin.local'; To = {{$json["cliente_email"]}}; Subject = 'Recordatorio de pago factura {{$json["id"]}}'; Body = plantilla HTML con {{amount}} y {{payment_link}}.
• HTTP Request a pasarela: Method = POST; Content-Type = application/json; Body = { invoice_id: {{$json["id"]}}, amount: {{$json["monto"]}}, return_url: 'https://app.innovafin.local/pagos/confirm' }.
• DB Update: Query parametrizada: UPDATE facturas SET estado = 'link_enviado', pago_link = {{$response.body.link}}, fecha_ultimo_recordatorio = NOW() WHERE id = {{$json["id"]}};

Problemas frecuentes

Symptom: Correos no llegan al cliente.

Causa: Credenciales de SendGrid inválidas o remitente no verificado. Solución: Verificar API Key en Variables de entorno y confirmar dominio remitente en SendGrid; revisar logs del node Email Send para códigos 4xx/5xx.

Symptom: Errores 429 o límites de API al enviar SMS/correos.

Causa: Exceso de llamadas simultáneas al proveedor. Solución: Reducir batchSize en SplitInBatches o introducir node Wait/Throttle; implementar reintentos exponenciales con node Function o Retry.

Symptom: No se actualiza el estado de la factura en la base de datos.

Causa: Query SQL malformada o permisos insuficientes. Solución: Probar la consulta en entorno seguro; revisar credenciales DB en credenciales de n8n; comprobar errores en ejecución del node SQL.

Symptom: Links de pago inválidos o caducan inmediatamente.

Causa: Parámetros incorrectos enviados a la pasarela (currency, amount, expiración). Solución: Validar payload contra documentación de la pasarela; registrar request/response y ajustar formato.

Symptom: Flujos paralelos duplican recordatorios.

Causa: Trigger programado en múltiples instancias o falta de control de estado. Solución: Añadir locking lógico: campo procesando = true con check en consulta inicial; usar node If para filtrar facturas ya marcadas.

Adaptaciones y variantes del flujo

• Variante para B2C con grandes volúmenes: usar colas (RabbitMQ/Kafka) y procesar mediante workers n8n con SplitInBatches muy pequeños; canales priotarios: SMS y notificaciones push.
• Integración con gateway de pago para generar cargos automáticos (domiciliación): añadir nodo HTTP Request a endpoint de débito directo y manejar respuestas de rechazo para reintentos programados.
• Escalada para mora prolongada: si vencimiento > 60 días, agregar ruta que notifica al equipo de cobros vía Slack + crear ticket en sistema CRM (Airtable/Jira) y cambiar estrategia de comunicación.
• Reconciliación bancaria en tiempo real: recibir webhook del banco con movimientos y conciliar pagos contra facturas; en caso de match, actualizar estado a pagado y enviar recibo al cliente automáticamente.

Estos pasos y configuraciones permiten que el flujo de n8n gestione cobros de manera previsiblemente automática, con trazabilidad y rutas de contingencia para errores frecuentes. Implementar controles de logging y alertas incrementa la gobernanza operativa.

Output esperado del flujo

Esta sección describe de forma concreta y ejecutiva el output esperado tras la ejecución del flujo n8n "Gestión Automática de Cobros". El flujo debe producir artefactos operativos y registros que permitan validar la actividad, conciliar con sistemas contables y generar seguimiento comercial. Los outputs se dividen en salidas inmediatas (notificaciones y actualizaciones), artefactos persistentes (registros, ficheros) y métricas de control.

Outputs inmediatos esperados:

• Notificaciones enviadas: correos de recordatorio, SMS o mensajes a CRM/Slack con el resultado de cada intento.
• Actualizaciones en CRM: estado de la factura actualizado a enviado/pendiente/reintentar/pagado.
• Creación de enlaces de pago: URL única para cada factura con token y vencimiento.
• Registro de intentos: entrada en tabla de audit log por cada intento con resultado y motivo.

Artefactos persistentes y formatos:

• CSV o JSON consolidado de ejecuciones del día para conciliación con contabilidad.
• PDF adjunto (factura) cuando corresponde, entregado junto con la notificación.
• Webhook payloads para sistemas externos con estructura JSON estándar.

Ejemplo concreto de salida por factura (datos ficticios):

Métricas y KPIs incluidos en el output diario:

• Porcentaje de cobros efectivos (pagado / total procesado).
• Monto recuperado en el periodo.
• Tasa de éxito por canal (email, SMS, enlace web).
• Promedio de días hasta pago tras primer recordatorio.

Validación operativa: tras la ejecución, revisar el CSV/JSON consolidado y el audit log para verificar que cada invoice_id tiene una entrada con action, status y timestamp. Comprobar además los endpoints externos (CRM y pasarela de pagos) para confirmar la conciliación. Ejemplo: el equipo de finanzas de "LogisticaNova S.A." deberá conciliar INV-2026-0041 con la línea del extracto bancario y cerrar en el ERP solo después de la confirmación de pago o del ajuste manual documentado en el registro.

Problemas frecuentes y cómo resolverlos

Adaptaciones del flujo para otros contextos

Esta sección describe variantes prácticas del flujo de n8n para "Gestión Automática de Cobros" y orienta sobre las adaptaciones técnicas necesarias para otros contextos empresariales. A continuación se presentan cuatro variantes habituales, pasos clave de configuración de nodos, un ejemplo de salida esperada y un apartado con problemas frecuentes, sus síntomas, causas y soluciones.

Variantes del flujo para otros contextos

• 1) Cobros recurrentes por suscripción (SaaS)

  Ideal para empresas con facturación periódica. Cambios principales: trigger por calendario, integración con pasarela de pagos y manejo de errores por rechazo de tarjeta.

  1. Trigger: utilizar nodo Cron para disparar cobranza mensual.
  2. Consulta de clientes: nodo HTTP Request o node MySQL para obtener clientes con suscripción activa y método de pago tokenizado.
  3. Pago: nodo Stripe (HTTP Request a la API de Stripe) con campos: amount, currency, customer_id, payment_method.
  4. Condicional: nodo IF para verificar respuesta de la pasarela (status == "succeeded").
  5. Post-proceso: nodo Set para generar registro de cobro y nodo Google Sheets o base de datos para almacenar recibos.

  Ejemplo: Finserve S.A. programa cron el día 1; el nodo HTTP Request llama a /customers?plan=pro; el nodo Function normaliza montos a centavos antes de Stripe.

• 2) Gestión de facturas B2B con aprobación manual

  Para empresas que requieren validación de crédito y aprobación antes del cobro automático.

  1. Trigger: Webhook que recibe factura pendiente desde ERP.
  2. Validación: nodo HTTP Request a servicio de scoring; nodo IF para decisión de riesgo.
  3. Aprobación: notificar a equipo de crédito con nodo Email o Slack y esperar respuesta mediante Webhook de devolución.
  4. Si aprobado: iniciar cobro con HTTP Request a la pasarela o generar cobro en sistema de domiciliación bancaria.

  Ejemplo: Distribuciones Norte SRL integra su ERP y solicita aprobación cuando el scoring supera umbral.

• 3) Reconciliación POS y cobro en punto de venta

  Flujo orientado a comercios con terminales POS y cierre diario.

  1. Trigger: nodo Cron diario para cierre de turno.
  2. Recopilación: nodo HTTP Request a API del proveedor POS para obtener transacciones del día.
  3. Reconciliación: nodo Function para comparar registros POS con facturación interna.
  4. Excepciones: generar alerta por email para discrepancias y marcar transacciones para revisión manual.

  Ejemplo: LogiTrans International ejecuta reconciliación a las 02:00 y crea un informe en Google Drive.

• 4) Cobros internacionales y multi-moneda

  Adaptación para empresas que facturan en distintas monedas y requieren conversión y reglas fiscales locales.

  1. Trigger: Webhook desde sistema de facturación con moneda y país.
  2. Tipo de cambio: nodo HTTP Request a proveedor de FX; nodo Function para normalizar a moneda base.
  3. Impuestos: nodo Set para aplicar reglas fiscales según país.
  4. Pago: envío a pasarela que soporte multi-moneda, registrando las comisiones por conversión.

  Ejemplo: Internacional Soluciones procesa facturas EUR y USD; el nodo Function aplica comisiones y convierte al libro contable en USD.

Configuración específica recomendada de nodos n8n (substeps clave)

1. Webhook: Path "/invoices/receive", HTTP Method "POST", Response Mode "On Received" para integraciones ERP.
2. HTTP Request (consulta clientes): Method "GET", URL "https://erp.example/api/customers?status=active", Authentication "Header Auth" con Bearer token.
3. Function (normalización): JavaScript para convertir montos a enteros en centavos y añadir meta datos necesarios para la pasarela.
4. IF: Condición "{{$json[\"payment_status\"]}} == 'succeeded'" para controlar ramas exitosas y de error.
5. SMTP/Email: From "cobros@empresa.com", Subject con plantilla que incluya {{ $json.invoice_id }} y enlace para recibo.

Output esperado (ejemplo práctico)

Problemas frecuentes

Síntoma: Nodo HTTP Request retorna 401 Unauthorized

Causa: Token de autenticación expirado o mal configurado en headers. Solución: renovar credenciales, verificar formato "Bearer " en el encabezado Authorization y probar con la herramienta de API del proveedor.

Síntoma: Cobros fallan con status "declined" pero el ERP marca "pago intentado"

Causa: Datos de tarjeta incompletos o token caducado. Solución: implementar reintento con notificación al cliente para actualizar método de pago; almacenar códigos de rechazo para análisis.

Síntoma: Diferencias en montos después de la conversión

Causa: Tipo de cambio obsoleto o aplicada doble conversión. Solución: centralizar la obtención del FX en un único nodo HTTP Request y normalizar montos en un nodo Function con precisión definida (p. ej., 2 decimales o centavos).

Síntoma: Webhook no recibe eventos del ERP

Causa: Ruta incorrecta o problemas de conectividad/firewall. Solución: comprobar URL pública del Webhook, probar con curl desde el ERP y revisar registros de n8n para errores de entrega.

Síntoma: Retrasos en ejecución nocturna del flujo

Causa: Lotes de datos muy grandes o límites de tasa en APIs externas. Solución: implementar paginación en consultas, procesar en batch con nodos SplitInBatches y configurar backoff exponencial en reintentos.

Conclusión: adaptar el flujo de cobros en n8n requiere planificar triggers, normalización de datos, control de errores y trazabilidad. Las variantes presentadas son punto de partida y deben ajustarse según las reglas comerciales, regulaciones fiscales y SLA de integración de cada empresa.