Automatizar facturas con n8n fue el tema central de este taller, en el que se construyó un flujo completo capaz de leer una cuenta de correo, detectar los mensajes que traen archivos XML y PDF, y separar ese trabajo en dos caminos: uno para respaldar los documentos en una carpeta de Drive y otro para analizarlos y validarlos. Se mostró cómo un nodo de código en JavaScript filtra los adjuntos para quedarse únicamente con XML y PDF, ignorando cualquier otro tipo de archivo que llegue por error, y cómo, a partir de ahí, el flujo convierte el XML en un formato JSON más manejable mediante nodos de transformación de datos. Con esa información ya estructurada, se limpia y se queda solo con los campos relevantes de la factura, fecha, folio, tipo de comprobante y montos entre otros, que luego se registran en una hoja de cálculo con pestañas separadas para facturas válidas y rechazadas, dejando un historial ordenado de todo lo que el flujo va procesando.
La parte de validación se construyó con reglas propias del negocio: que el comprobante sea CFDI, que corresponda a la versión 4.0, que esté emitido a nombre del RFC correcto y que los montos cuadren, y cualquier factura que incumpla alguna de estas condiciones se envía automáticamente a rechazados. También se explicó cómo etiquetar los correos ya procesados para no analizarlos dos veces y cómo un nodo especializado permite eliminar duplicados entre distintas ejecuciones, algo que un flujo normal no puede hacer por sí solo porque sus datos se pierden al terminar cada corrida y no hay forma de comparar una ejecución con la anterior sin ese tipo de memoria. Sobre este mismo ejercicio se repasó además un error real de configuración, en el que una factura válida terminó en la hoja equivocada por una mala selección del nodo de Google Sheets, lo que sirvió para remarcar la importancia de revisar bien las credenciales y el mapeo de columnas antes de dar un flujo por terminado, ya que un detalle tan pequeño puede alterar por completo el resultado de la automatización.
A partir de esta base, se compartió el caso de un proyecto real cotizado para un cliente con alrededor de cuarenta estaciones de gasolina que buscaba automatizar la facturación a partir de una foto del recibo enviada por WhatsApp. Se explicó cómo se calculó el volumen esperado, cerca de cuatro mil facturas diarias, y cómo ese número llevó a investigar qué tanta carga soporta n8n en modo cola antes de definir la infraestructura necesaria para que el sistema no colapsara en los momentos de mayor demanda. También se detalló el cálculo de costos: el consumo de tokens de un modelo de lenguaje para interpretar los datos de cada recibo, la tarifa de una API externa para timbrar las facturas, el gasto de servidor y el margen que debía dejar la cotización final por sucursal, dejando ver que calcular bien estos números es tan importante como la parte técnica del flujo, porque un mal cálculo de costos puede hacer que un proyecto en apariencia rentable termine generando pérdidas.
Para la parte práctica de este caso se simuló el canal de WhatsApp con un bot de Telegram, al que se le envió la foto de un recibo para que un nodo de análisis de imágenes extrajera la sucursal, el folio y el total, entregando esa información en un formato estructurado listo para usarse en el resto del flujo. Se mostró cómo consultar en una base de datos si el número de quien escribe ya está registrado para generar la factura de inmediato, o cómo pedirle sus datos cuando es la primera vez que interactúa, y cómo convertir en subflujos reutilizables las partes que se repetían, como el análisis de la imagen o la generación de la factura, de modo que cualquier ajuste futuro se haga en un solo lugar en vez de repetirlo en cada nodo del proyecto. Con esto, el taller deja un recorrido completo que va desde la lectura y validación de documentos hasta el diseño de un proyecto de facturación automatizada pensado para operar a gran escala sin perder el control de cada paso del proceso.
