---
title: "Comprobantes de pago por Outlook y Teams: una cola de cobranzas con control"
description: "Cómo usar Power Automate para recibir comprobantes desde Microsoft 365, extraer campos, proponer un match y enviar excepciones a revisión sin convertir Copilot en una caja negra financiera."
author: "Carlos García"
published: 2026-09-13
updated: 2026-09-13
language: es
human_url: "https://kiia.cloud/es/blog/comprobantes-pago-outlook-teams-cobranzas/"
---

> **En 60 segundos:** Power Automate puede recibir un correo con adjuntos o detectar un archivo nuevo en la biblioteca de SharePoint que respalda un canal de Teams. El flujo crea un caso, conserva el original, extrae campos candidatos, consulta pedidos o cuentas por cobrar y aplica reglas visibles. Los comprobantes ilegibles, duplicados, con importe distinto o sin pedido entran en una cola con motivo y responsable. Copilot puede resumir el contexto permitido y redactar una aclaración, pero no confirma que el dinero llegó ni decide dónde aplicarlo. SharePoint u OneDrive sirven como staging; el ERP o sistema de cobranzas conserva el estado oficial. Medí tiempo hasta conciliación, excepciones y retrabajo antes de ampliar el alcance.

Un comprobante suele llegar a una casilla compartida de Outlook o a un canal de Teams. Alguien descarga el PDF o la imagen, busca al cliente, compara el importe con un pedido y copia el resultado al ERP. Cuando algo falla, la conversación sigue en correo o chat y la tarea deja de ser visible para el resto de cobranzas.

Microsoft 365 permite organizar ese recorrido sin presentar la lectura automática como una decisión financiera. La arquitectura útil separa recepción, extracción, matching, revisión y registro. Las capacidades y limitaciones citadas en esta guía se comprobaron en la documentación de Microsoft el 13 de septiembre de 2026; licencias, conectores y políticas deben volver a revisarse para cada tenant.

## Un mapa para Outlook y Teams

Los dos canales pueden alimentar la misma cola, aunque no guardan los archivos de la misma manera.

| Entrada | Disparador recomendado | Evidencia que entra al caso | Precaución |
| --- | --- | --- | --- |
| Casilla de cobranzas en Outlook | `When a new email arrives in a shared mailbox (V2)` | ID del mensaje, remitente, fecha, asunto y cada adjunto | La cuenta de conexión necesita acceso a la casilla; correos protegidos o adjuntos inválidos pueden omitirse |
| Canal de cobranzas en Teams | Archivo creado en la biblioteca de SharePoint asociada al canal | ID del sitio, biblioteca, archivo, autor y hora | Definir un canal y carpeta de ingreso; no depender de que alguien mencione al bot |
| Mensaje de Teams | Disparador para un chat o canal específico, solo si el texto aporta contexto necesario | ID del mensaje, conversación y enlace al archivo | El disparador de mensaje raíz no recibe respuestas; las ediciones tampoco vuelven a disparar algunas variantes |

El [conector de Outlook para Power Automate](https://learn.microsoft.com/en-us/connectors/office365/) puede filtrar correos con adjuntos. Microsoft advierte que incluir todo el contenido de los adjuntos en el propio disparador puede causar esperas y timeouts cuando llegan muchos mensajes; su alternativa documentada es disparar sin el contenido y recuperar cada archivo con `Get Attachment (V2)`.

En Teams, el archivo no vive realmente en una carpeta propia de la interfaz. Microsoft documenta que los [archivos compartidos en un canal se guardan en el sitio de SharePoint del equipo](https://learn.microsoft.com/en-us/microsoft-365/enterprise/microsoft-365-isolation-in-microsoft-365#files), mientras los compartidos en un chat privado o de reunión quedan en el OneDrive de quien los envió. Para una bandeja operativa resulta más estable pedir el comprobante en un canal controlado y disparar desde su biblioteca de SharePoint. El [conector de Teams](https://learn.microsoft.com/en-us/connectors/teams/) puede recoger contexto del mensaje, pero sus disparadores tienen alcances distintos: algunos solo reaccionan al mensaje raíz y otros no reaccionan a ediciones.

El recorrido común queda así:

1. Outlook o SharePoint detecta el nuevo elemento.
2. Power Automate genera un `case_id`, comprueba formato y tamaño, calcula una huella del archivo y guarda el original en staging.
3. Un servicio de extracción autorizado devuelve campos candidatos sin alterar el documento.
4. El flujo normaliza los campos y consulta registros elegibles en el ERP o sistema de cuentas por cobrar.
5. Reglas deterministas comparan referencias, cliente, importe, moneda, fecha, estado y duplicados.
6. Un caso válido queda listo para el siguiente control definido por Finanzas; una diferencia entra en cuarentena.
7. Una persona resuelve la excepción y Power Automate registra la decisión y la respuesta del sistema de destino.

Este patrón complementa la ruta de [comprobantes recibidos por WhatsApp](/es/blog/comprobantes-pago-whatsapp-cobranzas/). Cambian el canal, la identidad y el almacenamiento, pero no cambia la obligación de explicar el match y conservar el ERP como fuente de verdad.

## Separá orquestación, lectura y decisión

Poner “IA” en un único bloque oculta quién hizo cada cosa. Conviene asignar una responsabilidad concreta a cada capa.

| Capa | Responsabilidad | Lo que no debe decidir |
| --- | --- | --- |
| Power Automate | Disparar, mover el archivo, invocar servicios, consultar candidatos, enrutar estados, reintentar y registrar resultados | Si una diferencia financiera es aceptable por intuición |
| OCR o extracción documental | Proponer texto y campos con el valor original y, si está disponible, señal de confianza por campo | Si el comprobante prueba la llegada de fondos o a qué saldo aplicarlos |
| Copilot | Resumir un hilo permitido, explicar el contexto al revisor y redactar una solicitud de aclaración | Aprobar su propio match, cambiar un saldo o autorizar un pago |
| Reglas de negocio | Validar formatos, estados, referencias, tolerancias autorizadas y duplicados | Resolver una excepción no contemplada |
| Persona responsable | Confirmar o corregir casos excepcionales dentro de su rol | Saltarse la segregación de funciones porque el flujo lo hace cómodo |
| ERP o sistema de cobranzas | Mantener pedidos, CxC, aplicación del pago, actor, estado e historial oficial | Usar una carpeta o un resumen como sustituto del asiento |

Copilot aporta contexto, no certeza bancaria. En Outlook puede [resumir hilos y, en clientes compatibles, archivos PDF, Word o PowerPoint](https://support.microsoft.com/en-us/outlook/copilot-pages/summarize-an-email-thread-with-copilot-in-outlook). En Teams puede resumir conversaciones, pero Microsoft indica que [no resume imágenes ni archivos compartidos dentro del hilo](https://support.microsoft.com/en-us/teams/copilot/how-to-use-microsoft-365-copilot-in-teams-chats-and-channels). Un comprobante en imagen necesita un método de extracción elegido y probado para ese formato; no conviene diseñar el proceso alrededor de una capacidad que el producto no declara.

Después de la extracción, Copilot puede preparar un texto como “Necesitamos un comprobante más legible” o resumir por qué el caso tiene dos facturas candidatas. El mensaje debe permanecer como borrador hasta que una regla o persona autorizada decida enviarlo. La comparación de [Power Automate, conectores y desarrollo a medida](/es/blog/copilot-power-automate-vs-desarrollo-medida/) ayuda a elegir el mecanismo cuando el ERP no tiene un conector estándar o el flujo acumula estado complejo.

## El esquema mínimo del caso

La cola necesita datos estructurados además del archivo. Conservá siempre el valor recibido y el normalizado para poder explicar una corrección.

| Campo | Ejemplo de tratamiento | Uso |
| --- | --- | --- |
| `case_id` | UUID generado una vez | Correlacionar correo, archivo, ejecución, revisión y escritura |
| `source_channel` y `source_id` | `outlook` + ID del mensaje, o `teams_sharepoint` + ID del archivo | Volver a la evidencia sin depender del nombre visible |
| `received_at` y remitente | Hora UTC, dirección o ID interno autorizado | Antigüedad, trazabilidad y controles de origen |
| `file_name`, tipo, tamaño y hash | Metadatos sin sobrescribir el original | Formato permitido y detección de duplicados |
| `amount_original`, `amount` y `currency` | Texto leído, decimal normalizado y código de moneda | Comparar sin perder el dato que llegó |
| `operation_date` y `payment_reference` | Fecha distinguida de la recepción; referencia original y normalizada | Buscar y detectar reutilización |
| `customer_candidate` | ID interno y regla que lo propuso | Evitar que un nombre parecido se convierta en identidad |
| `receivable_candidates` | IDs, estado, saldo y diferencias | Mostrar alternativas explicables al revisor |
| `status`, `exception_reason` y `owner` | Estado cerrado, motivo enumerado y responsable | Operar la cola y medirla |
| `decision` y `system_result` | Actor, hora, regla o aprobación, ID de transacción y respuesta | Demostrar qué se intentó y qué aceptó el ERP |

No reduzcas la calidad a una sola cifra. Un importe puede estar bien leído y pertenecer al cliente equivocado. Si el extractor expone confianza, guardala por campo y usala para priorizar revisión; no la conviertas en permiso para escribir.

## Matching por capas, no por parecido general

El matching debe devolver evidencias y diferencias, no una respuesta libre. Un orden práctico es:

1. Rechazar formatos no admitidos y separar documentos sin los campos mínimos.
2. Detener un archivo o referencia ya procesados mediante hash, referencia e historial del ERP.
3. Resolver el cliente con identificadores acordados; correo, nombre y conversación solo aportan contexto.
4. Consultar pedidos, facturas o partidas abiertas que estén en un estado elegible.
5. Comparar moneda antes que importe; nunca compensar monedas sin una regla explícita.
6. Comparar referencia, importe, fecha, cliente y estado y conservar el resultado de cada regla.
7. Enviar a revisión cero, varios o un único candidato con diferencias fuera de política.
8. Revalidar saldo, estado y duplicados justo antes de preparar o ejecutar cualquier escritura autorizada.

La propuesta debe mostrar el registro candidato, los campos coincidentes, las diferencias, la hora de consulta y la acción permitida. La guía de [niveles de control para agentes de IA](/es/blog/copiloto-o-piloto-automatico-agentes-ia/) encaja paso a paso: extraer es lectura; sugerir un documento es recomendación; preparar una aplicación es borrador. Aplicar el pago afecta caja y saldos, por lo que no debe saltarse los controles financieros ni la revisión de excepciones.

## Cuatro excepciones que el piloto debe resolver

La cuarentena es una lista de trabajo, no una carpeta llamada “Revisar”. Cada entrada necesita un motivo enumerado, evidencia, responsable y plazo.

| Motivo | Qué muestra la tarjeta de revisión | Resolución permitida |
| --- | --- | --- |
| Ilegible | Original, campos ausentes o dudosos y canal de origen | Pedir otro archivo o transcribir con el control requerido |
| Posible duplicado | Hash, referencia, importe, fecha y caso o pago anterior | Confirmar duplicado o justificar que es otra operación |
| Importe distinto | Saldo, importe recibido, moneda y diferencia | Mantener pendiente, asociar según política o pedir aclaración |
| Sin pedido o CxC | Identidad propuesta, criterios de búsqueda y candidatos descartados | Corregir identidad, asociar manualmente o devolver al remitente |

Agregá `varios_candidatos`, `moneda_incompatible`, `archivo_no_admitido` y `fallo_del_destino` si aparecen en la muestra. No conviertas una corrección humana en una regla nueva de manera automática. Primero analizá su frecuencia, documentá la política y probá el cambio.

Teams puede mostrar la excepción con un enlace al caso y los datos mínimos para decidir. Evitá copiar todo el comprobante en cada notificación: amplía accesos y crea más copias sujetas a retención. Si la decisión ocurre en una tarjeta o mensaje, su resultado debe volver al caso y al sistema de registro; no debe quedar como un “aprobado” aislado en el chat.

## SharePoint es staging; el ERP conserva la verdad

Una biblioteca controlada de SharePoint puede guardar el archivo original, el `case_id`, el estado de procesamiento y una fecha de retención. OneDrive puede ser útil para trabajo individual, pero depender del espacio personal de quien compartió un archivo debilita continuidad, permisos y salida de empleados.

Ninguna de esas carpetas debe definir que un cobro está aplicado. La fuente de verdad se reparte de esta forma:

- Exchange o Teams conserva la comunicación original según la política de la empresa.
- SharePoint conserva temporalmente el archivo y los metadatos de procesamiento.
- La cola conserva responsable, motivo, estado y resolución de la excepción.
- El ERP o sistema de CxC conserva el saldo, la asociación, la aplicación, la reversión y el identificador oficial.
- El banco o la pasarela conserva la evidencia de que el movimiento ocurrió cuando existe una integración autorizada.

El comprobante que envía un cliente es evidencia para revisar, no confirmación bancaria. Una escritura exitosa de Power Automate tampoco basta: guardá la respuesta del ERP y ejecutá una conciliación posterior entre casos recibidos, decisiones y transacciones creadas. Así se reduce el [coste de volver a capturar datos entre sistemas](/es/blog/coste-copiar-datos-entre-sistemas/) sin perder trazabilidad.

## Permisos, retención y modelos

Usá una cuenta de conexión administrada, con acceso solo a la casilla, canal, biblioteca y operaciones necesarias. Separá quién edita el flujo, quién revisa excepciones y quién puede aplicar o revertir pagos. Evitá usar la cuenta personal del dueño del proceso y registrá cambios de conexiones, reglas y versiones.

Antes del piloto, acordá:

- quién puede ver el original y qué campos puede copiar fuera de la cola;
- cuánto tiempo permanecen correo, chat, archivo de staging, datos extraídos, prompts y logs;
- qué etiqueta de sensibilidad o retención corresponde a cada ubicación;
- qué conectores pueden compartir datos dentro del entorno;
- si está permitido enviar nombres, cuentas, referencias bancarias o adjuntos a un modelo concreto;
- cómo se atienden solicitudes de acceso, corrección, borrado o conservación legal aplicables.

Microsoft indica que los prompts, respuestas y datos de Graph usados por Microsoft Copilot [no se utilizan para entrenar los modelos fundacionales](https://learn.microsoft.com/en-us/microsoft-365/copilot/microsoft-365-copilot-privacy), y que la experiencia respeta identidad, permisos y políticas del tenant. Eso no reemplaza una base legal, una clasificación ni una decisión interna sobre finalidad y minimización. Tampoco autoriza a pegar un comprobante en una cuenta de consumo, activar búsqueda web o enviarlo a un conector externo.

Power Platform permite aplicar [políticas DLP a los conectores](https://learn.microsoft.com/en-us/power-automate/prevent-data-loss), y Microsoft Purview ofrece [políticas y etiquetas de retención](https://learn.microsoft.com/en-us/purview/retention) para ubicaciones compatibles. Revisá la licencia y configuración reales: la existencia de una función en la documentación no demuestra que esté habilitada en tu tenant.

## Un piloto pequeño y medible

Empezá con una casilla compartida o un canal, una entidad, una moneda y un tipo de comprobante. Durante la primera etapa, ejecutá el proceso en modo sombra: extrae, busca y propone, mientras el equipo mantiene el procedimiento actual. Compará resultados antes de permitir que el flujo prepare una escritura.

| Métrica | Definición | Qué ayuda a decidir |
| --- | --- | --- |
| Tiempo hasta conciliación | Desde la recepción hasta la asociación correcta en CxC | Si el flujo reduce espera total y no solo transcripción |
| Tasa de excepción | Casos enviados a cuarentena ÷ casos recibidos | Cuánto del alcance elegido sigue necesitando decisión |
| Retrabajo | Casos corregidos, reabiertos o recapturados | Si la automatización elimina o desplaza trabajo |
| Antigüedad de la cola | Tiempo abierto por motivo y responsable | Si la revisión humana tiene capacidad y SLA real |
| Falsos positivos | Matches propuestos o aceptados que la validación determina incorrectos | Riesgo financiero y calidad de las reglas |

Segmentá por Outlook o Teams, PDF o imagen, cliente, extractor y motivo. No publiques una tasa de OCR, ahorro o autonomía basada en una demo. Usá documentos sintéticos para desarrollar y una muestra propia, autorizada y minimizada para validar; nunca copies PII ni comprobantes reales al artículo o a entornos sin control.

El piloto puede avanzar cuando el equipo explica cada match, resuelve la cola dentro del plazo, detecta duplicados y reconcilia el resultado contra el ERP. Kiia diseña esta ruta con Power Automate como orquestador, Copilot como apoyo acotado y Finanzas como dueño de las reglas y excepciones.

## Preguntas frecuentes

### ¿Copilot puede conciliar un comprobante de pago automáticamente?

No debería tomar esa decisión. Copilot puede resumir contexto permitido o preparar una solicitud de aclaración, pero el importe, la moneda, el duplicado y la asociación con el pedido o la cuenta por cobrar necesitan reglas verificables y revisión humana cuando exista una excepción.

### ¿Dónde conviene guardar los comprobantes recibidos por Teams?

Para un proceso compartido, conviene usar un canal controlado cuya biblioteca de SharePoint funcione como staging. Los archivos enviados en chats privados quedan en el OneDrive del remitente, una dependencia débil para una cola operativa. El estado oficial del cobro debe vivir en el ERP o sistema de cobranzas.

### ¿Cómo se mide el piloto?

Tomá una línea base y medí tiempo hasta conciliación, tasa de excepción y retrabajo. Agregá antigüedad de la cola y falsos positivos de matching. Separá los resultados por canal, formato y motivo, sin publicar una tasa de extracción hasta medirla con documentos propios.