Conciliación a tres bandas sin ERP:
Un pipeline en Google Sheets del pedido a la aprobación
Nuestro análisis de por qué la conciliación a tres bandas falla en manufactura estableció que el cuello de botella no es el algoritmo de conciliación, sino la extracción de datos que lo precede. Los benchmarks de AP de Ardent Partners 2025 sitúan la tasa media de discrepancias iniciales en un 22%, y en manufactura —con pedidos abiertos, envíos parciales y desviaciones en la unidad de medida entre el muelle y la factura— esa cifra es aún mayor. El diagnóstico es claro: no puedes conciliar tres documentos si dos de ellos siguen atrapados en PDFs no estructurados. La pregunta que responde este artículo es: ¿qué construyes realmente para solucionarlo, y puedes hacerlo sin un ERP?
Conclusiones clave
- El 22% de discrepancias iniciales no es un fallo del algoritmo de conciliación, sino un fallo de extracción de datos disfrazado de problema de conciliación.
- El 66% de los equipos de AP ingresan manualmente los datos de facturas en su ERP, lo que significa que el módulo de conciliación pasa la mayor parte del tiempo inactivo esperando que alguien termine de escribir.
- La extracción de nombres de columna de ImageToTable.ai lee cualquier formato de proveedor sin plantillas, y el paso de conciliación, que antes requería una investigación de tres departamentos, se convierte en un VLOOKUP y una celda verde.
Lo que realmente exige la conciliación a tres bandas — más que umbrales de tolerancia
La conciliación a tres bandas es el proceso de comparar una orden de compra, un albarán de recepción y una factura de proveedor antes de autorizar el pago, verificando que lo pedido coincide con lo recibido y lo facturado. Según la cláusula 8.4 de la ISO 9001:2015, la verificación de que los productos adquiridos cumplen los requisitos especificados es obligatoria para los fabricantes certificados, y la conciliación a tres bandas es el mecanismo operativo que la mayoría de las empresas utiliza para cumplirla. El Informe a las Naciones 2024 de la ACFE — que estima que las organizaciones pierden el 5% de sus ingresos anuales por fraude laboral — la identifica como un control clave contra los esquemas de facturación. La lógica regulatoria es sólida. El problema de datos subyacente es lo que falla en la práctica.
La mayoría de los consejos para arreglar la conciliación a tres bandas se centran en la capa de emparejamiento: ajustar umbrales de tolerancia, añadir flujos de aprobación, configurar reglas de emparejamiento automático en el ERP. Nada de esto soluciona el problema de que los tres documentos llegan de tres sistemas diferentes en tres formatos distintos — y dos de ellos no están estructurados. La orden de compra reside en el sistema de compras. El albarán de recepción puede haberse introducido o no a partir de un albarán en papel. La factura del proveedor llega como PDF. Antes de que cualquier lógica de emparejamiento pueda comparar estos documentos, alguien tiene que extraer los datos de los dos que no están ya en un formato estructurado, introducirlos en un diseño comparable y esperar que las unidades y las líneas de pedido coincidan. La capa de emparejamiento — BUSCARV, declaraciones SI, formato condicional — es la parte fácil. La capa de extracción es donde el proceso vive o muere.
Un proceso de conciliación a tres bandas que funcione no comienza con mejores reglas de emparejamiento. Comienza por conseguir que los tres documentos estén en el mismo formato estructurado en la misma hoja de cálculo. Una vez que están ahí, el emparejamiento es un ejercicio de fórmulas. La parte difícil es llegar hasta ahí.
Por qué el consejo de ERP no encaja en un flujo de hojas de cálculo
El módulo MM de SAP, Oracle E-Business Suite, Microsoft Dynamics 365 — todos incluyen módulos de conciliación triple con tolerancias configurables. SAP, por ejemplo, maneja la conciliación a través de la cuenta de compensación GR/IR: la entrada de mercancías (transacción MIGO) registra un débito, la recepción de facturas (MIRO) registra un crédito, y el sistema compensa automáticamente las líneas conciliadas. La lógica es madura y está bien documentada.
La lógica también asume algo que en un número considerable de operaciones de compras no es cierto: que los tres documentos existen como datos estructurados y comparables dentro del ERP antes de que se ejecute la lógica de conciliación. La Encuesta de Tendencias de Automatización de AP de IFOL 2025 encontró que el 66% de los equipos de AP aún ingresan manualmente los datos de facturas en su ERP. Para los equipos de compras que gestionan relaciones con proveedores entre 50 y 200 vendedores — muchos de ellos pequeños talleres mecánicos, distribuidores locales y proveedores especializados que envían PDF por correo electrónico — cada factura es un evento de ingreso manual de datos antes de que pueda comenzar la conciliación.
Si estás en ese grupo — ya sea porque tu empresa gestiona compras con hojas de cálculo, porque la captura de facturas de tu ERP requiere configuración de plantillas por proveedor que no tienes tiempo de mantener, o porque tu base de proveedores incluye suficientes vendedores pequeños que el PDF es el único formato que envían — el módulo de conciliación de tu ERP está abordando un problema aguas abajo del que realmente tienes. No necesitas un mejor algoritmo de conciliación. Necesitas una forma de poner los datos de órdenes de compra, recepción y facturas en una vista estructurada — y la herramienta que ya usas para el seguimiento de compras probablemente sea una hoja de cálculo. La pregunta es cómo convertir esa hoja de cálculo en un pipeline.
La Arquitectura del Pipeline de Tres Capas
El pipeline tiene tres capas — una para cada documento en la conciliación triple — y una cuarta que se sitúa sobre ellas: el panel de conciliación. Las primeras tres capas extraen datos estructurados de documentos no estructurados. La cuarta los compara. Si alguna de las primeras tres capas produce datos inconsistentes o incompletos, la capa de conciliación no puede hacer su trabajo. La arquitectura es tan fuerte como su capa de extracción más débil.
Cada capa cubre un vacío específico en la cadena de compra a pago. La capa de OC establece la línea base — qué se pidió, a qué precio, a quién. La capa de recepción confirma lo que llegó físicamente. La capa de factura captura lo que facturó el proveedor. El panel de cruce es donde convergen las tres — y donde la hoja de cálculo reemplaza la investigación entre tres departamentos que el análisis del problema identificó como la debilidad estructural en los flujos de cruce tradicionales.
La herramienta que impulsa la conversión de no estructurado a estructurado en las capas 1 y 3 es la Extracción por Nombre de Columna: en lugar de dibujar recuadros alrededor de campos en cada documento o crear una plantilla por formato de proveedor, escribes los nombres de columna que deseas — "Número de OC", "Nombre del Proveedor", "Línea", "Cantidad", "Precio Unitario", "Total Línea" — y la IA lee el documento para encontrar esos valores entendiendo lo que significan, no dónde están en la página. Una OC estructurada del PDF de SAP y una OC manuscrita de un proveedor local no se parecen en nada. Pero ambas contienen un número de OC, nombre del proveedor, cantidades y precios. La extracción por nombre de columna busca el significado de esos campos en cualquier diseño — eliminando el mantenimiento de plantillas por proveedor y formato que hace que la OCR basada en plantillas sea poco práctica para equipos de compras que manejan docenas de formatos de documentos de proveedores diferentes.
Capa 1 — Extracción de Órdenes de Compra: La Referencia Base
Toda conciliación a tres bandas comienza con la orden de compra. La OC establece los términos: proveedor, artículos, cantidad, precio y fecha de entrega. En un entorno integrado con ERP, estos datos ya existen como líneas de pedido estructuradas — la OC se creó en el sistema. Pero en un flujo de trabajo basado en hojas de cálculo, las OC llegan en varios formatos: PDFs generados por el sistema del comprador, OC enviadas por correo por proveedores confirmando un pedido, o documentos escaneados de proveedores pequeños que operan en papel. Convertir los datos de la OC a un formato estructurado es el primer paso — y para equipos que usan hojas de cálculo, es un paso que determina si el resto del proceso es siquiera viable.
Las columnas de extracción de una OC dependen de lo que necesite referenciar su proceso de conciliación. Como mínimo:
| Columna | Qué Captura | Por Qué Importa para la Conciliación |
|---|---|---|
| N.º de OC | Identificador único de la OC | El campo clave — todo informe de recepción y factura debe referenciarlo para conciliar |
| Nombre del Proveedor | Nombre del proveedor tal como aparece en la OC | Referencia cruzada con el proveedor de la factura — confirma que es el mismo |
| Línea de Pedido | Descripción del artículo, SKU o número de pieza | Concilia con las líneas de recepción y factura para comparación a nivel de artículo |
| Cantidad | Cantidad pedida por línea | Se compara con la cantidad recibida y la facturada |
| Precio Unitario | Precio unitario acordado por línea | Verificación de variación de precio — la bandera de auditoría más común |
| Total por Línea | Cantidad × Precio Unitario por línea | Se compara con el total facturado por línea — detecta errores de extensión |
| Fecha de Entrega | Fecha de entrega prevista | Se usa para verificar fechas de recepción y marcar entregas tardías |
| Total de la OC | Suma de todos los totales por línea | El monto agregado que la factura no debe superar sin explicación |
Para órdenes de compra generadas internamente en un formato consistente — la plantilla de OC de su propia empresa — la extracción es directa. La IA lee los mismos campos del mismo diseño general cada vez. Para OC de confirmación de proveedor que llegan en el formato del vendedor, la extracción se adapta: los nombres de columna se mantienen iguales y la IA localiza los valores independientemente del diseño. Una sola ejecución de extracción completa la pestaña del registro de OC con datos estructurados — una fila por OC, o una fila por línea de pedido, según si se desea granularidad a nivel de cabecera o de línea para la conciliación. La guía de extracción de una sola OC con el complemento de Google Sheets explica la configuración de columnas y el primer flujo de extracción. Para equipos de alto volumen que procesan docenas de OC a la vez, el panel de procesamiento por lotes de OC aplica el mismo motor de extracción a múltiples OC en una sola sesión.
Los archivos se procesan de forma segura y no se almacenan.
La demo anterior usa la plantilla de orden de compra — un conjunto preconfigurado de columnas de extracción diseñado para documentos PO. Sube una orden de compra y observa cómo se completan los campos sin escribir. Si tus PO contienen campos que la plantilla no cubre (un recargo por mercancía, una sección de términos de flete, códigos internos de centro de costo), agrégalos como columnas personalizadas — el motor de extracción las trata igual. La plantilla te da el punto de partida. Tus columnas personalizadas la extienden para que coincida con los requisitos de tu panel de conciliación.
Capa 2 — Datos del Informe de Recepción: El Documento Intermedio Problemático
El comprobante de recepción de mercancías es el documento que con mayor frecuencia falta en un sistema estructurado — y es el documento que hace que la conciliación a tres bandas sea un proceso de tres vías. Sin confirmación de recepción, estás haciendo una conciliación a dos bandas (PO vs. factura) y pagando por bienes que no puedes confirmar que se entregaron. La ACFE identifica específicamente el comprobante de recepción como el control que previene el fraude en facturación — pagar por bienes nunca enviados. Omitirlo no es un atajo. Es una brecha en el marco de control.
Los datos de recepción son más difíciles de estructurar que los datos de PO debido a cómo se generan — en el muelle, a menudo en papel, por personal cuya prioridad es descargar camiones, no ingresar datos. El albarán suele ser un formulario de carbón multicopia o un documento de impresión térmica del transportista. El empleado de recepción lo firma, registra la cantidad recibida (a veces en unidades que difieren de la PO) y archiva la copia física. Que esos datos lleguen a un sistema digital depende de si alguien los escribe después — y ese paso es el primero que se omite durante un día de recepción ajetreado.
Para el pipeline, los datos de recepción tienen dos vías de entrada viables. La primera es la entrada manual directa: el empleado de recepción — o una persona designada para ingreso de datos — escribe los campos clave en una Google Sheet como parte del flujo de trabajo de recepción. Las columnas reflejan las columnas de PO: Número de PO (para vincular), Artículo Recibido, Cantidad Recibida, Fecha de Recepción, Transportista, Estado. Esta vía funciona cuando el volumen de recepción es moderado (menos de 30 envíos por día) y el muelle tiene acceso a un dispositivo con Sheets abierto. La ventaja es el control — los datos de recepción están estructurados desde el momento de ingreso, sin necesidad de conversión posterior.
El segundo camino es la extracción de documentos del propio albarán: tomar una foto o escaneo del albarán firmado y procesarlo con el mismo motor de extracción utilizado para pedidos y facturas. Esta vía funciona cuando la entrada manual no es viable — muelles de alta rotación, ubicaciones de recepción remotas, u operaciones donde el albarán es el único registro de recepción. Las columnas de extracción son las mismas: N.º de Pedido, Descripción del Artículo, Cantidad Recibida, Fecha de Recepción, Transportista. Una foto de un albarán procesada mediante el complemento de la barra lateral completa la pestaña de recepción en el mismo formato estructurado que los datos ingresados manualmente. La limitación clave: la escritura a mano en los albaranes reduce la precisión de la extracción en comparación con los pedidos y facturas impresos. Se recomienda verificar por muestreo en envíos críticos. Para un desglose detallado de precisión según la calidad del documento, consulte nuestra guía sobre precisión de extracción de documentos manuscritos — los mismos principios aplican a albaranes e informes de recepción.
Independientemente del camino que use, el resultado es el mismo: una pestaña de registro de recepción con el N.º de Pedido como campo clave que vincula cada recepción con su pedido de compra original. Sin ese vínculo, el panel de conciliación no puede funcionar.
Capa 3 — Extracción de Facturas de Proveedores: El Problema de Formato que Usted No Controla
Las facturas de proveedores son donde el problema de diversidad de formatos alcanza su punto máximo. Una sola operación de compras puede recibir facturas de un gran distribuidor MRO en un PDF estructurado generado por SAP, de un proveedor regional de metales en un formato casero de Excel a PDF, de un taller local como un documento manuscrito fotografiado, y de un proveedor internacional con diferentes formatos de fecha, convenciones de moneda y estructuras de líneas de impuestos. El OCR basado en plantillas — donde se crea una plantilla de mapeo de campos para el diseño de cada proveedor y se actualiza cuando el diseño cambia — se rompe bajo esta diversidad o consume tanto tiempo de mantenimiento que el esfuerzo de extracción iguala la entrada manual que se suponía debía reemplazar.
La Extracción de Columnas Personalizadas resuelve esto desacoplando la lógica de extracción de cualquier diseño específico. Los nombres de las columnas se definen una vez. La IA lee cada factura — independientemente del formato — y encuentra los valores que coinciden con esas definiciones de columna. Una configuración de columnas de factura para la conciliación triple normalmente incluye:
| Columna | Fuente | Rol de Coincidencia |
|---|---|---|
| Número de Factura | Extraído de la factura | Identificador único — evita pagos duplicados |
| Número de OC | Extraído de la factura | Campo de enlace crítico — debe coincidir con una OC en la pestaña de registro de OC para que funcione la coincidencia |
| Nombre del Proveedor | Extraído de la factura | Referencia cruzada contra el proveedor de la OC — detecta errores de referencia de OC incorrecta |
| Fecha de Factura | Extraído de la factura | Cálculo de plazo de pago; análisis de antigüedad |
| Fecha de Vencimiento | Extraído de la factura | Seguimiento de ventana de descuento por pago anticipado |
| Descripción del Artículo | Extraído de la factura | Coincidencia con artículo de OC — confirma que se facturan los mismos bienes pedidos |
| Cantidad | Extraído de la factura | Verificación de variación contra cantidad de OC y cantidad recibida |
| Precio Unitario | Extraído de la factura | Verificación de variación contra precio unitario de OC — detección de aumento de precio |
| Total del Artículo | Extraído de la factura | Verificación de extensión — confirma que Cant. × Precio Unit. = Total del Artículo en la factura |
| Total de Factura | Extraído de la factura | Coincidencia agregada contra total de OC ± tolerancia; activador de autorización de pago |
También puede agregar columnas inferidas — columnas que capturan datos no impresos explícitamente en la factura pero deducibles de su contexto. Por ejemplo, una columna definida como Estado de Coincidencia (opciones: Listo para Coincidir/Requiere Referencia OC/Artículos Faltantes) permite que la IA clasifique cada factura durante la extracción según si encontró un número de OC y si los artículos fueron extraíbles. Las facturas de proveedores que no incluyen números de OC en sus documentos se marcan de inmediato — ingresan al panel de coincidencia con un estado "Requiere Referencia OC", y el auxiliar de cuentas por pagar sabe que no debe intentar una coincidencia hasta que se agregue el número de OC. Esto es categorización-como-extracción: la decisión de clasificación ocurre en la misma pasada que completa los datos, no en un paso de revisión separado.
Las columnas calculadas manejan operaciones matemáticas que de otro modo requerirían fórmulas en hojas de cálculo posteriores a la extracción. Defina una columna como Verificación de Extensión (Total Línea - Cantidad * Precio Unitario) y la IA realiza el cálculo durante la extracción, marcando cualquier línea donde el total facturado no coincida con cantidad por precio unitario. El resultado es un número de variación: cero significa que la extensión es correcta, un valor distinto de cero identifica un error aritmético en la factura del proveedor. Esto cambia el rol del panel de conciliación de "encontrar errores" a "revisar las filas marcadas", un flujo donde la IA detecta y el humano decide. Para un tratamiento completo de la sintaxis y capacidades de columnas calculadas, consulte nuestra guía de columnas calculadas en extracción de documentos.
La misma capa de extracción de facturas que impulsa el proceso de conciliación a tres bandas es el motor detrás del proceso integral de facturas de proveedor a cuentas por pagar — la estructura de columnas difiere, pero el mecanismo de extracción es idéntico. Una vez creado para conciliación, el mismo proceso alimenta informes de cuentas por pagar, cálculos de devengo y documentación de auditoría.
El Panel de Conciliación: BUSCARV, SI y Formato Condicional
Con las tres capas completadas — registro de órdenes de compra, registro de recepción y registro de facturas — el panel de conciliación es donde convergen. Es una sola pestaña que extrae datos de las tres pestañas fuente mediante funciones de búsqueda y aplica lógica de comparación para marcar coincidencias, variaciones y datos faltantes. La lógica de conciliación en sí no es compleja. Una hoja de cálculo puede hacerlo. Lo que siempre fue complejo — y lo que el proceso resuelve — es preparar los datos para que la hoja de cálculo pueda hacerlo.
Estructura del panel de conciliación, creado en Google Sheets:
| Columna | Origen | Fórmula / Lógica |
|---|---|---|
| A: N.º de OC | Extraído del registro de facturas | Clave principal — todas las columnas siguientes la referencian |
| B: N.º de Factura | Del registro de facturas | Referencia directa: ='Invoice Register'!A2 |
| C: Proveedor | Del registro de facturas | Referencia directa |
| D: Proveedor de OC | VLOOKUP del registro de OC | =VLOOKUP(A2, 'PO Register'!A:H, 2, FALSE) |
| E: Cantidad de OC | VLOOKUP del registro de OC | Coincide con la cantidad de línea en la OC |
| F: Cantidad Recibida | VLOOKUP del registro de recepción | =VLOOKUP(A2, 'Receiving'!A:G, 3, FALSE) |
| G: Cantidad Facturada | Del registro de facturas | Referencia directa |
| H: Precio Unitario de OC | VLOOKUP del registro de OC | Base de precio para verificación de variación |
| I: Precio Unitario Facturado | Del registro de facturas | Referencia directa |
| J: Variación de Cantidad | Calculado | =G2-E2 — positivo significa facturado más de lo pedido |
| K: Variación de Precio | Calculado | =I2-H2 — positivo significa aumento de precio unitario vs. OC |
| L: Variación Total de Línea | Calculado | =(G2*I2)-(E2*H2) — efecto combinado de cantidad + precio |
| M: Recibido vs. Facturado | Calculado | =G2-F2 — cantidad facturada vs. lo recibido |
| N: Estado de Coincidencia | Calculado | =IF(AND(J2=0,K2=0,M2=0),"COINCIDEN",IF(F2="","SIN RECEPCIÓN","VARIACIÓN")) |
| O: Notas | Manual | Explicación de variaciones: "Recargo del proveedor no incluido en OC", "Envío parcial — saldo pendiente el próximo mes" |
El formato condicional convierte esta tabla en un panel de control: resalta la columna N en verde para "COINCIDIDO", ámbar para "SIN RECIBO", rojo para "DIFERENCIA". Aplica un borde rojo a cualquier fila donde la columna J (Diferencia de Cantidad) supere un umbral configurable — 5% para materiales a granel, 2% para componentes de ingeniería de alto valor. Agrega un resumen en la fila superior: =COUNTIF(N:N,"COINCIDIDO") para contar facturas coincidentes, =COUNTIF(N:N,"DIFERENCIA") para excepciones, =SUMIF(N:N,"DIFERENCIA",L:L) para el valor total en dólares de las diferencias.
La decisión arquitectónica clave es el Número de OC como clave universal. Cada BUSCARV en el panel de coincidencias hace referencia a la columna de Número de OC. Si una factura de proveedor no incluye un número de OC — y nuestro análisis del problema de coincidencias confirmó que esta es la causa raíz más común de fallos — la fila se llena con errores #N/A en todas las columnas BUSCARV, visibles de inmediato en el panel. La solución es simple: agregar el número de OC al registro de facturas y las fórmulas se recalculan. Pero la visibilidad es el punto. Sin el panel, una factura sin número de OC permanece en una cola hasta que alguien la note. Con el panel, se marca en el momento en que la fila se completa.
Las fórmulas de coincidencia no son la innovación. Cualquier auxiliar de cuentas por pagar que maneje BUSCARV ha creado una versión de esto en Excel. La innovación es que los datos que alimentan estas fórmulas — las líneas de OC, las cantidades recibidas, los detalles de facturas — llegan todos en el mismo formato estructurado, extraídos de sus documentos originales en segundos en lugar de escribirse manualmente. El panel de coincidencias funciona porque las capas de extracción funcionan. Sin ellas, es solo un diseño bonito esperando datos que nunca llegan.
Para entregas parciales — la complejidad más común en compras de manufactura donde una OC cubre múltiples envíos — agrega una columna "Número de Entrega" tanto al registro de recepciones como al de facturas. El BUSCARV se convierte en una búsqueda de dos claves: coincidir por Número de OC Y Número de Entrega. Cada entrega parcial obtiene su propia fila de coincidencia, y el cálculo de recibido acumulado (=SUMIFS(F:F, A:A, A2, [Entrega], "<="&[@Entrega])) rastrea cuánto de la cantidad total de la OC se ha entregado en todos los envíos parciales. La misma lógica maneja OC abiertas con liberaciones mensuales rotativas — el panel rastrea cantidades acumuladas contra la autorización total de la OC.
Enlace de Recogida — Permite que los proveedores envíen documentos directamente
Una de las ineficiencias persistentes en la conciliación a tres bandas es la transferencia de documentos del proveedor a tu equipo de cuentas por pagar. El proveedor envía la factura por correo electrónico. El auxiliar de cuentas por pagar descarga el archivo adjunto, lo guarda en una unidad compartida o carpeta local, y luego lo sube a la herramienta de extracción. Ese ciclo de descarga y recarga no es el cuello de botella, pero es un paso extra que acumula fricción cuando procesas más de 100 facturas al mes de 50 proveedores diferentes.
Un Enlace de Recogida elimina ese paso intermedio. Es una URL compartible (con el formato /c/xxxx) que generas y envías a un proveedor. El proveedor abre el enlace, ingresa un código de verificación breve que se muestra en la página y sube su factura directamente — sin necesidad de crear una cuenta, iniciar sesión ni instalar software. El archivo llega automáticamente a la cola de procesamiento de tu cuenta, identificando al proveedor por el enlace utilizado. Puedes crear un Enlace de Recogida separado para cada proveedor (o uno por grupo de proveedores), de modo que los archivos entrantes se preseleccionen por origen antes de que comience la extracción.
Aplicado al flujo de conciliación a tres bandas, un Enlace de Recogida cambia el flujo de documentos de "el proveedor envía la factura por correo → tú descargas → tú subes → tú extraes" a "el proveedor sube directamente → el archivo aparece en tu cola → tú extraes". Elimina por completo el paso de descarga y recarga. Para los proveedores que envían varios documentos — un albarán y una factura para el mismo envío — un solo Enlace de Recogida captura ambos archivos, y el motor de extracción procesa cada uno según las definiciones de columna de la hoja. Para la configuración detallada y el flujo de trabajo, consulta nuestra guía de recogida de documentos con extracción.
El Enlace de Recogida no reemplaza las relaciones con los proveedores por un portal. Reemplaza el bucle de descarga de archivos adjuntos de correo electrónico con una ruta de carga directa. El proveedor no necesita capacitación, credenciales ni software. Necesita el enlace y el código de verificación. El resto es el mismo proceso de extracción, solo que con un paso menos entre "el proveedor envía" y "los datos están en tu hoja".
Qué reemplaza — y qué no
Un pipeline es una afirmación concreta: dice "esta secuencia de pasos produce este resultado". Es importante ser precisos sobre qué reemplaza el pipeline aquí descrito, qué complementa y para qué nunca fue diseñado.
Qué reemplaza:
- La entrada manual de datos de OC y facturas en hojas de cálculo. Las capas de extracción convierten documentos no estructurados en filas estructuradas. Escribir líneas de OC y campos de factura en una hoja de seguimiento es el paso que desaparece.
- El mantenimiento de plantillas OCR por proveedor. La extracción de nombres de columna lee cualquier diseño de documento sin plantillas preconfiguradas. Un nuevo proveedor se incorpora enviándole un Enlace de Recogida — sin necesidad de crear plantillas.
- El bucle de investigación entre tres departamentos. Cuando los datos de OC, recepción y factura están todos en un panel estructurado, la pregunta "¿coincide la factura con la OC?" se responde mirando una celda con formato condicional, no llamando a compras ni al muelle de recepción.
- Los puntos ciegos de documentos faltantes. La estructura BUSCARV del panel expone las brechas de inmediato: #N/A en la BUSCARV de OC significa que la factura no referencia una OC válida. En blanco en la cantidad recibida significa que nunca se registró la entrada de mercancía. Estos no son hallazgos de una auditoría mensual — son visibles en cada fila en tiempo real.
Qué no reemplaza:
- Un ERP para organizaciones que lo necesitan. Con 2,000–3,000 facturas al mes, un panel de conciliación basado en hojas de cálculo alcanza su límite práctico. El volumen de excepciones abruma la revisión manual. A esa escala, el valor del ERP — conciliación automatizada, pistas de auditoría integradas, cumplimiento de segregación de funciones — se vuelve necesario, no opcional. El pipeline alimenta al ERP con datos estructurados; no reemplaza al ERP como entorno de control.
- El juicio humano sobre excepciones. El panel señala variaciones. No las resuelve. Una diferencia de $47.50 entre el precio unitario facturado y el de la OC podría ser un recargo legítimo que el equipo de compras negoció pero nunca comunicó a AP, o podría ser un error. La IA no puede saber cuál — y no se le debe pedir que decida. La señal activa la revisión humana. La revisión requiere contexto comercial que la IA no tiene.
- El proceso de recepción en sí. Si no se crean entradas de mercancía — si el muelle no registra lo que llega — el pipeline expone la brecha en la pestaña de recepción pero no puede fabricar los datos. La capa de recepción requiere disciplina de proceso: alguien debe confirmar y registrar lo entregado. El pipeline estructura esos datos. No los crea de la nada.
- El cumplimiento del proveedor con el requisito de número de OC en la factura. El pipeline hace visible la ausencia de un número de OC. No hace que los proveedores lo incluyan. Eso requiere una política de compras — y su aplicación — no una solución técnica.
Preguntas Frecuentes
¿Cuántas facturas puede procesar este pipeline al mes sin fallar?
El límite estructural no está en el motor de extracción — que maneja cargas por lotes de múltiples archivos en una sola sesión — sino en la capacidad de revisión manual del panel de conciliación. Un solo auxiliar de cuentas por pagar que revise y resuelva diferencias puede manejar cómodamente entre 300 y 500 facturas al mes con un panel bien estructurado, asumiendo una tasa de excepción del 22% (66 a 110 excepciones por investigar). Por encima de 1,000 facturas al mes, el volumen de excepciones requiere varios auxiliares o migrar a un ERP con reglas de conciliación automatizadas. El valor del pipeline en volúmenes altos cambia de "herramienta principal de conciliación" a "motor de ingesta de datos que alimenta el ERP" — las capas de extracción siguen funcionando; el panel se convierte en un paso de validación previo al ERP, no en el entorno final de conciliación.
¿Qué pasa si mis OC usan precios variables que cambian mensualmente? ¿El pipeline maneja precios variables?
Sí — pero requiere que el registro de OC se mantenga como un documento vivo, no como una extracción única. Para una OC abierta con ajustes mensuales indexados a una tasa de mercado, la fila del registro de OC para ese proveedor debe actualizarse cada mes con el precio vigente. El BUSCARV en el panel de conciliación reflejará el precio actualizado. La alternativa — y la que preserva una pista de auditoría — es agregar una columna "Fecha de Vigencia" al registro de OC y usar un BUSCARV con coincidencia por rango de fechas: tomar el precio de la OC vigente en la fecha de la factura, no el precio actual. Esto es más complejo de configurar, pero refleja con precisión el precio acordado al momento del envío — que es lo que la conciliación triple debe verificar.
¿La extracción funciona en albaranes y documentos de recepción manuscritos?
Sí — la IA lee texto manuscrito, incluyendo números y anotaciones típicas en albaranes firmados en el muelle. Sin embargo, la precisión en documentos manuscritos es menor que en impresos, y los documentos muy deteriorados (impresiones térmicas desvaídas, copias carbón con texto tenue, albaranes arrugados y reaplanchados) generarán más errores de extracción. Para datos de recepción, recomendamos: (a) si es posible, que el recepcionista ingrese los campos clave (N° OC, Artículo, Cantidad, Fecha) directamente en la hoja de Google en el muelle — el ingreso manual en el punto de recepción es más rápido y preciso que la extracción de un documento deteriorado después; (b) si la extracción del albarán es la única opción viable, verifique una muestra de filas contra el documento original, especialmente en envíos de alto valor; (c) use la foto del albarán como archivo adjunto junto a la fila de recepción — incluso si la extracción omite un dígito, el documento original está a un clic para su verificación.
¿Puedo usar este pipeline sin el complemento de Google Sheets, solo con la aplicación web?
Sí. El motor de extracción es el mismo, ya sea que accedas a través del complemento en la barra lateral de Sheets o mediante la aplicación web en ImageToTable.ai. La ventaja del complemento es que la extracción se escribe directamente en la hoja activa, sin necesidad de descargar y volver a subir. Con la aplicación web, subes documentos en el navegador, descargas el archivo Excel extraído y pegas o importas las filas en tu panel de conciliación. Las definiciones de columnas son las mismas. La calidad de extracción es idéntica. El complemento elimina un paso (descargar e importar); la aplicación web funciona con cualquier herramienta de hojas de cálculo, no solo Google Sheets. Elige según si ese paso es relevante para tu volumen.
¿Cuánto tiempo toma configurar el pipeline completo — registro de OC, recepción, facturas y panel de conciliación?
Para alguien familiarizado con BUSCARV y formato condicional en Google Sheets, construir el pipeline completo de cuatro pestañas toma aproximadamente dos horas: 30 minutos para diseñar y crear las cuatro pestañas con las estructuras de columna descritas, 45 minutos para escribir y probar las fórmulas BUSCARV y SI en el panel de conciliación, 30 minutos para configurar el formato condicional y las métricas resumen, y 15 minutos para definir los conjuntos de columnas de extracción en la barra lateral del complemento. Las definiciones de columnas se guardan en la hoja y persisten entre sesiones: las defines una vez y están disponibles cada vez que abres la barra lateral y seleccionas esa hoja. Después de la configuración inicial, el flujo mensual es: (1) extraer nuevas OC en el registro de OC, (2) ingresar o extraer datos de recepción, (3) extraer facturas de proveedores, (4) abrir el panel de conciliación y revisar las filas marcadas. El primer mes toma más tiempo por la configuración y carga de datos. El tercer mes ya es rutina.
¿Cómo manejar diferencias de moneda entre OC y facturas de proveedores?
El motor de extracción captura el valor numérico y el símbolo de moneda tal como aparecen en el documento. No realiza conversión de moneda. Si tu OC está en USD y un proveedor factura en EUR, el panel de conciliación mostrará una variación porque los montos numéricos no coincidirán, incluso si los valores convertidos son correctos. La solución es agregar una columna "Moneda" tanto al registro de OC como al de facturas, y una columna "Tasa de conversión" que haga referencia a un tipo de cambio mantenido manualmente o alimentado por fórmula. La comparación de precios en la conciliación utiliza entonces el monto convertido en lugar del monto extraído en bruto. La función del pipeline es la extracción. La conversión de moneda es una operación a nivel de hoja de cálculo.
En Resumen
El pipeline de conciliación a tres bandas descrito aquí no reemplaza a un ERP en organizaciones que lo necesitan. Es un sistema para equipos que ya gestionan compras con hojas de cálculo, porque la captura de facturas de su ERP requiere un mantenimiento de plantillas que no pueden sostener, porque su base de proveedores abarca formatos que su módulo de conciliación no puede manejar, o porque su volumen de transacciones se sitúa en el punto intermedio entre "demasiado complejo para la conciliación manual" y "lo suficientemente grande como para justificar una actualización del ERP". Para esos equipos, la pregunta no es "deberíamos automatizar la conciliación", sino "¿podemos obtener los tres documentos en el mismo formato estructurado lo suficientemente rápido como para que la conciliación se convierta en un ejercicio de fórmulas en lugar de una investigación entre tres departamentos?"
El pipeline responde a esa pregunta con tres capas de extracción y un panel. La capa de OC proporciona la línea base de referencia. La capa de recepción confirma lo que llegó. La capa de factura captura lo que se facturó. El panel de conciliación los compara —con BUSCARV, declaraciones SI y formato condicional— y marca cada fila que necesita atención humana. El motor de extracción, impulsado por IA que lee documentos por significado en lugar de posición, maneja la diversidad de formatos que hace insostenibles los enfoques basados en plantillas en una operación de compras con múltiples proveedores. El Enlace de Recogida elimina el bucle de descarga de archivos adjuntos de correo electrónico del proceso de ingesta de documentos.
La brecha estructural que nuestro análisis del problema identificó —tres departamentos, tres sistemas, ningún propietario único del pipeline de datos— no desaparece. Pero cuando los tres tipos de documento llegan en el mismo formato estructurado en la misma hoja de cálculo, con el mismo Número de OC como clave universal, el paso de conciliación ya no requiere investigación entre departamentos. La brecha organizativa permanece. Los datos ya no arrastran la deriva acumulada de tres canales de entrada diferentes. Eso es lo que convierte la conciliación en un ejercicio de hoja de cálculo en lugar de un problema de personal.
Comienza con la capa de extracción de OC. Sube una orden de compra en la demo a continuación. Comprueba si los campos que importan para tu flujo de conciliación —número de OC, proveedor, líneas de pedido, cantidades, precios— se devuelven estructurados en segundos en lugar de escritos en minutos. Si esa primera capa funciona, el resto del pipeline se construye sobre el mismo motor.