¿El OCR puede aplicar un pago automáticamente?

El OCR solo extrae campos del comprobante. La aplicación del pago requiere validar importe, moneda, cliente, referencia, estado del documento y permisos contra el sistema de cobranzas. Los casos dudosos deben quedar en cuarentena para revisión humana.

¿WhatsApp puede ser el registro oficial del cobro?

No debería serlo. El chat conserva la conversación y el archivo recibido, pero el ERP o sistema de cobranzas debe guardar el estado oficial, la asociación con la factura o pedido, la decisión, el responsable y la trazabilidad.

¿Cómo se mide un piloto de comprobantes de pago?

Tomá una línea base y medí tiempo hasta conciliación, porcentaje de excepciones, falsos positivos de matching y retrabajo. Separá los resultados por tipo de excepción y no publiques una tasa de OCR o ahorro hasta medirla con tus propios documentos.

Comprobantes de pago por WhatsApp: del chat a cobranzas sin perder control

En 60 segundos: Un comprobante recibido por WhatsApp puede iniciar el trabajo de cobranzas, pero no debe convertirse en el registro oficial. El flujo guarda el archivo y su contexto, extrae cliente, importe, fecha y referencia, busca pedidos o facturas candidatos y aplica reglas deterministas. Solo los casos que pasan todos los controles pueden quedar listos para registrar según la política de la empresa. Los ilegibles, duplicados, importes distintos y pedidos no encontrados van a una cuarentena con motivo, evidencia y responsable. El ERP o sistema de cobranzas conserva el estado final. Medí el piloto con tiempo hasta conciliación, tasa de excepción, falsos positivos y retrabajo usando documentos propios.

En un flujo habitual de cobranzas, el aviso de pago llega como una foto, un PDF o una captura de pantalla por WhatsApp. Una persona abre el archivo, busca el cliente, compara el importe con un pedido o una cuenta por cobrar y registra el resultado a mano. Si algo no coincide, la aclaración continúa en el mismo chat.

El canal resulta cómodo para el cliente, pero deja una tarea delicada entre una conversación y el sistema financiero. Diseñar bien el flujo requiere conservar esa comodidad mientras cada decisión vuelve al registro que usa cobranzas.

Mapeá el ciclo actual antes de automatizar

Seguí una muestra de comprobantes recientes desde la recepción hasta la conciliación. Incluí casos normales y casos que necesitaron una llamada, otro archivo o una corrección.

Etapa	Qué hace hoy una persona	Riesgo frecuente	Evidencia que conviene conservar
Recepción	Abre el mensaje y descarga la imagen o PDF	El archivo queda en un teléfono o chat personal	ID del mensaje, canal, hora, remitente autorizado y hash del archivo
Lectura	Transcribe importe, fecha, referencia y cuenta	Confunde un dígito, una moneda o la fecha de operación	Archivo original, campos extraídos y confianza por campo
Matching	Busca cliente, pedido, factura o saldo abierto	Elige un registro parecido o usa una referencia incompleta	Candidatos evaluados, reglas y diferencias encontradas
Registro	Marca el pago o prepara su aplicación	Duplica un cobro o cambia un saldo sin autorización	Payload propuesto, actor, aprobación y respuesta del sistema
Excepción	Pide una aclaración y espera respuesta	El caso desaparece dentro de la conversación	Motivo, responsable, plazo, estado y resolución

Este recorrido también muestra el coste de copiar datos entre sistemas. Cronometrá la búsqueda, la transcripción, las correcciones y la espera por aclaraciones por separado. Así podrás distinguir el trabajo que elimina una integración del trabajo de decisión que seguirá existiendo.

Extracción y decisión son dos pasos diferentes

El OCR convierte una imagen en texto y campos candidatos. Puede proponer que el importe es 1250,00, que la fecha es 2026-09-12 y que cierta cadena parece una referencia. Todavía no sabe si ese dinero llegó a la cuenta correcta, si corresponde a la factura elegida o si el comprobante ya fue procesado.

Después de extraer, el flujo necesita reglas sobre datos autorizados:

Normaliza fecha, separadores decimales, moneda y referencia sin descartar el valor original.
Comprueba que los campos obligatorios estén presentes y tengan un formato válido.
Busca clientes mediante identificadores acordados; el nombre visible en el chat sirve como contexto, pero puede repetirse.
Recupera pedidos, facturas o partidas abiertas elegibles desde el sistema de registro.
Compara importe, moneda, referencia, fecha y estado, y devuelve cero, uno o varios candidatos.
Ejecuta una comprobación de duplicados antes de proponer cualquier escritura.

La salida debe nombrar la decisión pendiente: listo_para_revision, pedir_aclaracion, rechazar_documento o posible_duplicado, por ejemplo. La acción aplicar_pago pertenece a una política posterior, con permisos y controles propios. Un modelo puede ayudar a interpretar texto deteriorado o explicar diferencias, pero no debe ocultar esas decisiones dentro de una respuesta libre.

Un esquema mínimo para cada comprobante

Conservá el archivo original y una estructura validada. Como mínimo, cada caso necesita:

Campo	Fuente posible	Regla de tratamiento
Cliente	Identidad del canal, referencia, nombre extraído o selección humana	Resolver contra un ID interno; nunca asumir que el nombre del chat es único
Importe y moneda	Comprobante	Guardar valor original y normalizado; impedir comparaciones entre monedas sin una regla explícita
Fecha de operación	Comprobante	Distinguir fecha del pago, fecha de emisión y fecha de recepción
Referencia	Número de operación o texto bancario	Normalizar para búsqueda, conservar el texto original y comprobar duplicados
Pedido o factura asociada	Candidato del ERP o sistema de cobranzas	Guardar ID estable, estado y razón del match
Confianza	Resultado de extracción o matching	Registrar por campo y por candidato; no reducir todo el caso a un único porcentaje

Añadí identificadores de mensaje, archivo, cliente y ejecución para relacionar cada paso. La confianza orienta la revisión; no reemplaza las reglas de negocio. Un importe leído con claridad todavía puede pertenecer a otra factura.

Diseñá el matching para que pueda explicarse

Conviene evaluar candidatos por capas. Una referencia exacta y todavía no utilizada puede filtrar mejor que un nombre parecido. Después se comparan cliente, moneda, importe, fecha y estado del documento. Si varias facturas suman el importe, el sistema debe mostrar esa posibilidad como propuesta, no construir una distribución silenciosa.

Cada resultado debería incluir:

el registro candidato y un enlace para abrirlo en el sistema de origen;
las coincidencias y diferencias por campo;
las reglas que pasaron o fallaron;
la evidencia utilizada y su hora de consulta;
la acción permitida según el nivel de control del caso.

La guía sobre niveles de control para agentes de IA ayuda a separar lectura, recomendación, borrador y ejecución aprobada. Para este flujo, extraer campos es lectura; proponer una factura es recomendación; preparar el asiento es borrador. Aplicar el pago afecta caja y saldos, así que debe conservar los controles financieros definidos por la empresa.

La cuarentena es parte del proceso

Una cola de excepciones no es un buzón genérico. Cada caso entra con una razón que determina qué debe revisar la persona y qué respuesta puede enviar al cliente.

Motivo	Qué debe mostrar la revisión	Salida posible
Ilegible	Original, campos dudosos y zonas que no pudieron leerse	Pedir otro archivo o transcribir con doble comprobación
Posible duplicado	Referencia, importe, fecha y registro procesado anteriormente	Confirmar duplicado o documentar por qué es otra operación
Importe distinto	Factura, saldo, importe recibido y diferencia	Aplicar según política, solicitar aclaración o mantener pendiente
Pedido o factura no encontrado	Identidad del cliente, criterios usados y candidatos descartados	Corregir identificador, asociar manualmente o devolver al remitente
Varios candidatos	Lista acotada con diferencias visibles	Elegir uno con justificación o solicitar información adicional

Definí responsable, prioridad, antigüedad y plazo de revisión. Guardá la resolución con el mismo identificador del caso para que el sistema aprenda de categorías reales sin convertir correcciones humanas en reglas automáticas de forma accidental. El próximo artículo sobre pasar de limpiar Excel a gestionar excepciones desarrolla este cambio de trabajo administrativo.

El chat conserva la conversación; cobranzas conserva el estado

WhatsApp u otro canal puede recibir el comprobante, pedir un dato faltante y comunicar que el caso está en revisión. El flujo de WhatsApp a despacho usa el mismo principio: el canal conversa y los sistemas operativos mantienen pedidos, pagos, inventario y envíos.

Estos datos nunca deberían vivir solo en el chat:

el estado oficial del cobro y su relación con pedido, factura o cuenta por cobrar;
la decisión de aplicar, rechazar, dividir o devolver un pago;
el actor que aprobó el cambio y las reglas que validó;
las referencias del comprobante y de la transacción creada;
el historial de excepciones, correcciones y reversión.

Una confirmación enviada al cliente tampoco demuestra por sí misma que el ERP aceptó la escritura. El flujo debe esperar la respuesta del sistema, guardar su identificador y conciliar después los casos recibidos, propuestos y registrados. Las claves idempotentes evitan repetir la misma operación cuando llega dos veces el mensaje o se reintenta una llamada.

Qué necesita ver la revisión humana

La pantalla de revisión debe permitir decidir sin volver a empezar la búsqueda. Mostrá el comprobante original junto al cliente, los documentos candidatos, las diferencias y el cambio exacto que se propone. La persona tiene que poder corregir campos, cambiar la asociación, pedir una aclaración o rechazar el caso dejando un motivo.

Limitá los permisos a la acción necesaria. Quien clasifica un comprobante puede no tener autorización para aplicar el pago. Si la empresa separa registro, aprobación y conciliación, el flujo debe conservar esa separación en lugar de concentrarla en la cuenta técnica de la automatización.

Un piloto con métricas propias

Elegí un canal controlado, una entidad, una moneda y un tipo de documento. Empezá en modo sombra: el sistema extrae y propone, mientras el equipo sigue el procedimiento actual. Compará ambos resultados antes de permitir que se prepare una escritura.

Métrica	Inicio y final	Qué revela
Tiempo hasta conciliación	Mensaje recibido hasta pago correctamente asociado	Espera total, además del tiempo de lectura
Tasa de excepción	Casos en cuarentena dividido por casos recibidos	Capacidad real del alcance elegido
Falsos positivos	Matches aceptados por el flujo que una revisión determina incorrectos	Riesgo de aplicar un pago al registro equivocado
Retrabajo	Casos reabiertos, corregidos o recapturados	Trabajo que la automatización desplaza o crea

Separá las métricas por formato, origen y tipo de excepción. Medí también la antigüedad de la cola y los duplicados detenidos. Un promedio general puede esconder que los PDF funcionan bien mientras las fotos recortadas concentran casi toda la revisión.

Antes de publicar una tasa de OCR, una reducción de tiempo o un retorno, verificá el resultado con la muestra propia y documentá el periodo. También deben validarse el día del diseño: formatos e idiomas admitidos por el OCR elegido, límites y políticas vigentes del canal, campos e historial disponibles en el ERP, retención de archivos, permisos y requisitos de protección de datos. Si alguno cambia, cambia el diseño.

El piloto está listo para avanzar cuando el equipo puede explicar cada asociación, resolver la cola dentro del plazo acordado y reconciliar los registros sin depender del historial del chat. Kiia diseña estos flujos alrededor del sistema existente, con extracción, reglas y revisión proporcionadas al riesgo de cada acción.