New Omni documentation is now available — policy-driven document verification and API reference. Explore Omni → · Custom Theme for KYC liveform: Learn more →
New Omni documentation is now available — policy-driven document verification and API reference. Explore Omni → · Custom Theme for KYC liveform: Learn more →
Transforme sus procesos manuales de revisión documental en workflows automatizados de Omni.
Si su equipo dedica tiempo a revisar documentos manualmente — comprobando campos, validando datos, haciendo screening de nombres — Omni puede automatizar gran parte de ese trabajo. Esta guía le ayuda a pensar cómo convertir sus Procedimientos Operativos Estándar (SOPs) existentes en workflows de Omni.
Verificación de facturas — Comprobar montos, fechas, detalles del proveedor, totales de partidas
Onboarding de proveedores — Validar documentos de registro empresarial y hacer screening contra listas AML
Revisión de formularios de compliance — Verificar que los campos requeridos estén presentes y sean válidos
Validación de registros empresariales — Extraer y cruzar datos de la empresa
Revisión de contratos — Verificar términos clave, fechas e información de las partes
Verificación de documentos de empleados — Validar certificaciones, licencias o documentos de identidad presentados
Omni funciona mejor con procesos que tienen reglas claras y documentables. Si su proceso de revisión depende mucho de juicio subjetivo o conocimiento institucional que no puede documentarse, puede que convenga automatizarlo de forma parcial en lugar de total.
Esto se convierte en su línea base. Traducirá cada punto a la configuración de Omni.
2
Identifique los documentos de entrada
Liste cada tipo de documento que se envía para revisión. Sea específico:
Es un PDF de factura? Un certificado de registro empresarial escaneado? Una hoja de cálculo?
Hay múltiples documentos por caso, o solo uno?
Los documentos necesitan cruzarse entre sí?
Omni admite JPG, PNG, PDF, TXT, DOC, DOCX, XLS, XLSX, BMP, TIFF, WEBP, CSV, HTML y MD. Hasta 5 items por folder. Si un caso involucra más de 5 documentos, agrupe documentos relacionados en múltiples folders dentro del mismo profile.
3
Defina criterios de pass/fail
Para cada verificación que realiza su equipo, anote los criterios exactos:
Qué hace que un documento sea aceptable? (p. ej., “Todos los campos requeridos están presentes y el total coincide con las partidas”)
Qué hace que un documento sea rechazado? (p. ej., “La fecha de la factura está en el futuro” o “El registro empresarial está vencido”)
Qué desencadena la escalación a un revisor senior? (p. ej., “El screening AML devuelve una coincidencia” o “Campos clave son ilegibles”)
Estos criterios se convierten en la lógica de decisión de su policy de Omni.
4
Escríbalo como una policy en lenguaje natural
Combine las verificaciones y criterios de los pasos anteriores en una declaración de policy estructurada. Use pasos numerados y lenguaje explícito.Plantilla:
Review the submitted [document type] by performing the following checks:1. Extract [list of fields] from the document2. Verify that [specific condition]3. Check that [another condition]4. [Additional verification steps]Decision criteria:- APPROVE if all checks pass and all required fields are present- REJECT if [specific failure conditions]- FLAG for manual review if [ambiguous conditions]
Un miembro del equipo de finanzas abre cada PDF de factura y verifica manualmente:
Que el nombre del proveedor y el número de factura estén presentes
Que la fecha de factura sea razonable (no en el futuro, no mayor a 90 días)
Que los montos de las partidas sumen el total indicado
Que los cálculos de impuestos sean correctos
Que no haya números de factura duplicados en el sistema
Tiempo por factura: 5-10 minutos. Tasa de error: ~3% (errores de cálculo no detectados, duplicados pasados por alto).
Después: workflow de Omni
Policy:
Verify the submitted invoice document by:1. Extracting vendor name, invoice number, invoice date, line items, subtotal, tax, and total amount2. Verifying all required fields are present and non-empty3. Validating that the invoice date is not in the future and not older than 90 days4. Checking that the sum of line item amounts equals the stated subtotal5. Verifying that tax is calculated correctly based on the subtotal6. Approve if all checks pass; reject if amounts do not match or required fields are missing; flag for manual review if date is borderline
Engines: Text Verifier - Glove (extraer y validar todos los campos)Output schema:
Cuando se incorpora un nuevo proveedor, un oficial de compliance:
Revisa el certificado de registro empresarial buscando nombre de la empresa, número de registro y fecha de constitución
Verifica el documento de identidad del representante
Busca manualmente el nombre del representante en bases de datos AML/sanciones
Cruza los datos de la empresa entre documentos
Registra los resultados en una hoja de cálculo
Tiempo por proveedor: 20-30 minutos. Cuello de botella: la búsqueda AML es lenta y la consulta manual es propensa a errores.
Después: workflow de Omni
Policy:
Verify vendor onboarding documents by:1. Extracting company name, registration number, incorporation date, and representative name from the business registration certificate2. Screening the representative's name against AML/sanctions watchlists3. Cross-validating the representative name between the business registration and any submitted identity documents4. Checking that the business registration is not expired5. Approve if no AML matches found, all fields are consistent, and registration is valid; reject if AML screening returns a high-risk match; flag for manual review if AML returns a partial match or fields are inconsistent
Engines: Text Verifier - Glove + AML Search - PersonOutput schema:
Resultado: El screening AML es automático e instantáneo. Los casos limpios se aprueban automáticamente. El oficial de compliance se enfoca solo en los proveedores marcados.
Ejemplo 3: Verificación de documentos de compliance
Antes: proceso manual
Un equipo de compliance revisa documentos regulatorios presentados:
Verifica que todas las secciones requeridas estén presentes (encabezado, firma, fechas, números de licencia)
Comprueba que las fechas de vencimiento estén en el futuro
Confirma que el documento está dirigido a la entidad correcta
Valida que los números de referencia coincidan con los registros internos
Tiempo por documento: 10-15 minutos. Riesgo: documentos vencidos ocasionalmente se filtran durante períodos de alto volumen.
Después: workflow de Omni
Policy:
Review the submitted compliance document by:1. Extracting the document type, issuing authority, issue date, expiration date, license number, and entity name2. Verifying that all required sections are present: header, body, signature block, and dates3. Checking that the expiration date is in the future4. Validating that the entity name matches the expected entity5. Approve if all sections are present, the document is not expired, and entity names match; reject if the document is expired or missing required sections; flag for manual review if the entity name is a partial match
Engines: Text Verifier - Glove (validar completitud y corrección de campos)Output schema:
Resultado: Los documentos vencidos se detectan automáticamente. Los revisores solo manejan casos límite donde los nombres coinciden parcialmente o las secciones son ambiguas.
Su output schema determina qué datos estructurados obtiene de cada análisis. Diséñelo pensando en sus sistemas downstream.Todo output schema debería incluir estos tres bloques:
Bloque
Propósito
Campos de ejemplo
Datos extraídos
Valores en bruto obtenidos de los documentos
vendorName, invoiceNumber, registrationDate
Resultados de validación
Pass/fail por verificación con razones
amountsMatch, dateValid, fieldsConsistent
Decisión
Veredicto final y estado de routing
result, verificationStatus, reasons
Si omite el bloque de decisión, tendrá que escribir su propia lógica de decisión basada en los resultados de validación en bruto. Incluir un bloque de decisión permite que el agente de IA tome la decisión final basándose en los criterios de su policy.
Cada análisis expone verificationStatus: approved, pending_review o rejected. Ramifique sus integraciones basándose en ese enum.
verificationStatus
Acción recomendada
approved
Aceptar automáticamente y registrar en sus sistemas
pending_review
Enviar a una cola humana con los hallazgos de IA y datos extraídos
rejected
Denegar o cerrar el caso según su policy
Este enfoque significa que Omni no reemplaza completamente a su equipo de revisión. Aprueba automáticamente los casos directos y envía los ambiguos o fallidos a la cola correcta con contexto.
Monitoree la frecuencia con que aparece cada estado y compare con los resultados manuales. Ajuste el lenguaje de la policy o su output schema cuando las tasas de pending_review o rejected se desvíen de las expectativas.
if verificationStatus == "approved": → auto-accept, record in systemelif verificationStatus == "pending_review": → send to reviewer queue with AI findings highlightedelse: # rejected → denial flow or manual escalation per policy
Integre esta lógica en su backend después de recuperar los resultados del análisis de la Omni API.
Elija su proceso de revisión de mayor volumen y más basado en reglas. Cree un workflow de Omni para él y ejecútelo en paralelo con su proceso manual durante 1-2 semanas.
2
Compare resultados
Verifique las decisiones de Omni contra las decisiones manuales de su equipo. Busque discrepancias e investigue si Omni o el revisor humano tenía razón.
3
Refine la policy
Basándose en la comparación, ajuste el lenguaje de su policy, output schema o umbrales de puntuación. Pequeños cambios suelen producir mejoras significativas.
4
Expanda gradualmente
Una vez validada la precisión, deje que Omni maneje el proceso de punta a punta. Luego pase a automatizar procesos de revisión adicionales.