--- title: "Comprobantes de pago por WhatsApp: del chat a cobranzas sin perder control" description: "Cómo recibir comprobantes por chat, extraer sus datos, asociarlos con pedidos o facturas y revisar excepciones sin convertir WhatsApp en el registro de cobranzas." author: "Carlos García" published: 2026-09-12 updated: 2026-09-12 language: es human_url: "https://kiia.cloud/es/blog/comprobantes-pago-whatsapp-cobranzas/" --- > **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](/es/blog/coste-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: 1. Normaliza fecha, separadores decimales, moneda y referencia sin descartar el valor original. 2. Comprueba que los campos obligatorios estén presentes y tengan un formato válido. 3. Busca clientes mediante identificadores acordados; el nombre visible en el chat sirve como contexto, pero puede repetirse. 4. Recupera pedidos, facturas o partidas abiertas elegibles desde el sistema de registro. 5. Compara importe, moneda, referencia, fecha y estado, y devuelve cero, uno o varios candidatos. 6. 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](/es/blog/copiloto-o-piloto-automatico-agentes-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](/es/blog/limpiar-excel-a-gestionar-excepciones-ia/) 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](/es/blog/whatsapp-a-despacho-automatizar-pedidos/) 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. ## Preguntas frecuentes ### ¿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.