--- title: "OCR de Odoo: proceso nativo o flujo de excepciones" canonical: https://wavect.io/es/blog/odoo-invoice-ocr-ai-exception-workflow/ language: es description: "Compara el OCR nativo de Odoo con un flujo de excepciones. Revisa cotejo, importes y reglas de liberación con una factura de ejemplo y casos de aceptación." image: "https://wavect.io/img/blog/headers/header_odoo-invoice-ocr-ai-exception-workflow.png" author: ["Kevin Riedl"] published: "2026-11-05" updated: "2026-11-05" reviewed: "2026-11-05" --- # OCR de facturas en Odoo: ¿cuándo necesitas un flujo de excepciones? [**Volver**](/es/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/es/team/kevin-riedl/) [Kevin Riedl](/es/team/kevin-riedl/) https://linkedin.com/in/wsdt 12 minutos de lectura · 5 nov 2026 Última revisión 5 de noviembre de 2026 [**Siguiente**](/es/blog/odoo-bmd-export-reconciliation/) Resumen Demuestra la digitalización, el cotejo y la configuración de contabilización nativos antes de personalizar. Una extracción correcta no resuelve diferencias de recepción, autoridad de precios ni permisos de liberación. Conserva valores de origen y esperados, asigna un responsable a cada excepción y comprueba la transición real. El CSV contiene doce casos ficticios en NOT_RUN. No se midió el rendimiento del OCR ni de un modelo. La factura indica diez unidades. El pedido también. El almacén ha recibido ocho. Leer correctamente cada carácter todavía deja una decisión pendiente para las personas responsables de la diferencia. **Utiliza el OCR y el cotejo de compras nativos de Odoo cuando la configuración instalada cumpla tu proceso.** Añade un flujo de excepciones para una carencia demostrada en validación, evidencias o autoridad de liberación. Conserva los valores de origen junto a los esperados, asigna un responsable a cada diferencia y comprueba el efecto antes de activar la contabilización automática. **Investigación revisada: 5 de noviembre de 2026.** Los datos del producto proceden de la documentación oficial de Odoo 20.0. La factura, los importes y los casos son ficticios. No se ejecutó un servicio OCR, modelo, conector ni proceso contable. El componente fiscal del ejemplo sirve para calcular, no para recomendar un tratamiento tributario. ## ¿Qué permite ya el procesamiento nativo de facturas de Odoo? Demuestra la digitalización, el cotejo de compras y la configuración de contabilización antes de especificar un flujo personalizado. Registra la versión, las aplicaciones y los ajustes relevantes. La cuestión es si esa configuración realiza las comprobaciones necesarias y conserva sus evidencias, también en las excepciones. El nombre de una función no acredita una política de liberación. La [documentación de digitalización de Odoo 20](https://github.com/odoo/documentation/blob/20.0/content/applications/finance/accounting/vendor_bills/invoice_digitization.rst) describe la lectura de facturas y la búsqueda de un pedido, seguida del cotejo manual con líneas de pedido abiertas. Esto es más preciso que afirmar que el OCR nunca participa en el cotejo. Tampoco promete que toda factura se asocie correctamente sin intervención. Pide al responsable de implementación que demuestre la vía real con los documentos y la estructura de pedidos que necesitas admitir. La [documentación de facturas de proveedor](https://github.com/odoo/documentation/blob/20.0/content/applications/finance/accounting/vendor_bills.rst) también recoge opciones de contabilización automática por proveedor. Revisar todas las facturas es una elección de política y configuración, no una descripción incondicional del comportamiento nativo. Durante la aceptación propuesta aquí, mantén la liberación bajo la política de revisión acordada. Anota qué automatismos están activos antes de interpretar los resultados. Una demostración que empieza con una configuración y activa otra sin registrarlo deja de acreditar el mismo comportamiento. ## ¿Una excepción de cotejo impone tu regla de aprobación? Una excepción visible y una regla de aprobación aplicada necesitan evidencias distintas. Un estado puede avisar de una diferencia y dejar disponibles acciones posteriores. Si tu proceso exige retener la factura, demuestra que la identidad correspondiente no puede eludirlo por las rutas de aplicación e integración previstas. Inspecciona el estado final del negocio. La [documentación de control de facturas](https://github.com/odoo/documentation/blob/20.0/content/applications/inventory_and_mrp/purchase/manage_deals/control_bills.rst) distingue cantidades pedidas y recibidas. También describe borradores modificados con `Should Be Paid: Exception` sin bloquear esas modificaciones. Convierte esa distinción en un requisito de aceptación. En la política del ejemplo, una factura con una diferencia de recepción pendiente no puede superar el paso protegido de liberación. Quien resuelva la diferencia debe dejar motivo y evidencia. Aplicar la regla mediante configuración, módulo o control personalizado sigue siendo una decisión de implementación. Separa preparación, contabilización y pago en el alcance. Una comprobación aritmética satisfactoria no autoriza las tres acciones. Define qué identidad puede realizar cada una, qué aprobación debe citar y qué ocurre si cambia un importe o una evidencia después de la revisión. No deduzcas un bloqueo universal de contabilización o pago a partir del nombre de un campo. Tampoco supongas que una instalación concreta carece de controles: la configuración y los módulos pueden cambiar el comportamiento. Comprueba la ruta desplegada que vas a operar. ## ¿Cuándo se justifica un flujo personalizado de excepciones? Se justifica cuando un requisito acordado sigue sin cumplirse después de demostrar la vía nativa. Identifica la regla, fuente de evidencia o responsabilidad ausente y limita la ampliación a esa carencia. Si el problema es una recepción mal registrada o una política sin acordar, añadir otro modelo de extracción no lo resolverá. | Necesidad observada | Primera opción que evaluar | Evidencia antes de personalizar | | --- | --- | --- | | Facturas admitidas y evidencias de cotejo ya disponibles en Odoo. | Digitalización, cotejo y configuración de revisión nativos. | Facturas y excepciones representativas alcanzan los estados acordados con evidencias conservadas. | | Falta un responsable, una aprobación o una regla de importes. | Demostrar si la configuración o un módulo mantenido pueden imponerla. | La condición exacta ausente y un caso que actualmente la elude. | | La evidencia de aceptación está en otro sistema operativo. | Integración acotada que recupere y conserve la evidencia necesaria. | Identidad de origen, vigencia, autorización y comportamiento si la fuente falla. | | La extracción nativa falla en una clase documentada de entradas. | Evaluar otra vía de extracción con esos documentos. | Fallos observados y esfuerzo de revisión posterior. | Mantén disponible el documento original del proveedor aunque el revisor elija valores esperados del pedido. El registro de excepción debe mostrar la diferencia. Sustituir el importe propuesto por el esperado sin conservar el origen dificultaría entender qué se estaba discutiendo. La [guía de extracción de facturas y revisión humana](/es/blog/reducto-german-invoices-human-review/) cubre la evaluación del reconocimiento. Úsala cuando esa calidad sea el problema demostrado. Aquí se decide qué ocurre después de disponer de valores para revisar. ## ¿Por qué una factura bien leída puede seguir necesitando revisión? Una lectura correcta puede incumplir una comprobación comercial porque reconocer y aceptar responden a preguntas distintas. Verifica primero la aritmética del documento. Después compara cantidad y precio con el pedido aprobado y la política de recepción. Mantén separadas las diferencias para que el revisor sepa qué decisión sigue pendiente. El ejemplo ficticio usa el proveedor V01, la factura INV-082 y la empresa A. La factura contiene diez unidades a 25 € cada una, un componente fiscal ilustrativo de 50 € y ningún otro cargo. El pedido contiene diez unidades; el registro de recepción, ocho. | Comprobación | Valor de origen o esperado | Cálculo | Decisión según la política del ejemplo | | --- | --- | --- | --- | | Neto de la línea | 10 unidades a 25 €. | 10 × 25 € = 250 €. | La aritmética coincide. | | Importe bruto | 250 € netos más 50 € de componente fiscal. | 250 € + 50 € = 300 €. | La aritmética coincide; el tratamiento fiscal sigue la política aprobada. | | Cantidad pedida | 10 pedidas y 10 facturadas. | 10 − 10 = 0 unidades. | No hay diferencia de cantidad frente al pedido. | | Cantidad recibida | 8 recibidas y 10 facturadas. | 10 − 8 = 2 unidades. | Retener para revisar la recepción según la regla acordada. | El OCR podría reproducir fielmente todo el documento. La diferencia de dos unidades seguiría necesitando una explicación. Un error al registrar la recepción, una entrega parcial y una excepción comercial aprobada requieren evidencias distintas. El sistema debe mostrar la diferencia sin inventar cuál es la causa. Cambia ahora solo el bruto extraído a 310 €, manteniendo el neto y el componente fiscal en 250 € y 50 €. La diferencia sin explicar es 310 € − (250 € + 50 €) = **10 €**. Un revisor debe determinar si hubo una lectura errónea, se omitió un cargo o el documento requiere aclaración. Forzar silenciosamente el total a 300 € ocultaría esa investigación. «Lista para revisión financiera» significa, en la plantilla, que las comprobaciones enumeradas no tienen problemas pendientes según las reglas del ejemplo. No significa contabilizada, autorizada para pago ni pagada. El responsable financiero autorizado decide el tratamiento real y las condiciones de liberación. ## ¿Qué debe conservar el registro de excepción? Conserva los valores discutidos, sus fuentes, un motivo específico y la persona que puede resolverlo. Incluye empresa y moneda para evitar asociar un importe plausible al contexto equivocado. Vincula la liberación con las evidencias y la versión del registro que se aprobaron, para poder revisar después la decisión. | Elemento | Contenido requerido | Finalidad | | --- | --- | --- | | Identidad | Empresa, proveedor, referencia documental e identificadores de registros candidatos. | Revisar la factura y el contexto correctos. | | Valores observados | Ubicación en el original y cantidades o importes extraídos. | Conservar lo que declara el documento del proveedor. | | Valores esperados | Pedido, recepción u otra evidencia aprobada con su versión. | Mostrar por qué se espera un resultado diferente. | | Motivo y responsable | Diferencia identificada de recepción, precio, identidad o aritmética. | Dirigir la pregunta a quien puede decidir. | | Evidencia de liberación | Decisión, actor responsable, versión actual y referencia de respaldo. | Establecer qué se aprobó antes de la acción protegida. | Una referencia repetida debe iniciar una investigación de duplicados, no borrar automáticamente una factura. Odoo señala que [las facturas parciales pueden compartir Bill Reference](https://github.com/odoo/documentation/blob/20.0/content/applications/finance/accounting/vendor_bills.rst). Compara los documentos y las identidades relevantes antes de concluir que representan la misma obligación. Asigna una siguiente acción útil a cada motivo. Compras puede resolver un precio del pedido. Recepción puede corregir o explicar una cantidad registrada. Finanzas define las reglas de importes y la liberación contable. Un cambio de datos maestros del proveedor necesita su verificación aprobada aparte; el texto de una factura no debe reescribir datos bancarios silenciosamente. Reevalúa la aprobación si cambia un valor material o una evidencia de respaldo. Conserva la decisión anterior y el motivo por el que dejó de ser válida. De otro modo, una cola bien diseñada podría liberar una factura modificada con pruebas de una versión anterior. ## ¿Cómo aceptas el flujo antes de habilitar la automatización? Comprueba el estado final de la factura y las evidencias tanto para casos permitidos como para transiciones prohibidas. Utiliza la configuración real en un entorno protegido. Verifica que cada excepción llega a un responsable y permanece retenida cuando lo exige la política. Una advertencia visible o una tarea terminada solo aportan parte de la evidencia. Descarga la [matriz de aceptación con doce excepciones de factura](/downloads/odoo-invoice-ocr-ai-exception-workflow/invoice-exception-acceptance.csv). Incluye diferencias de recepción y precio, aritmética, empresa, proveedor, moneda, posibles duplicados, cambios de datos maestros, tolerancias sin definir y aprobaciones desactualizadas. Todos los estados de ejecución son `NOT_RUN`. 1. **Aprueba primero la política.** Finanzas y operaciones definen qué debe retener una factura y quién puede liberarla. 2. **Registra la configuración inicial.** Incluye versión, módulos, controles, contabilización automática y permisos técnicos. 3. **Prueba un caso conforme y su excepción cercana.** Mantén los importes y cambia, por ejemplo, la cantidad recibida de diez a ocho. 4. **Inspecciona todas las rutas relevantes.** Demuestra una transición permitida y un intento de elusión con la identidad real. Conserva el estado resultante. 5. **Cambia las evidencias.** Modifica una entrada material después de revisarla y verifica que la aprobación anterior no autoriza otro estado de factura. 6. **Prueba recuperación y responsabilidad.** Mantén visible el trabajo pendiente cuando una fuente externa o un revisor no estén disponibles. La [guía de aceptación de agentes de Odoo por estado del negocio](/es/blog/odoo-ai-agent-business-state-tests/) desarrolla el patrón general. El resultado específico debe demostrar que avanzó el registro correcto por el motivo correcto, mientras un caso retenido no eludió su condición. Si una IA explica una diferencia o propone una asociación, conserva la sugerencia separada de la decisión. Evalúa el modelo después de una ejecución real con entradas representativas permitidas. Esta matriz propuesta no acredita la precisión del OCR nativo ni el rendimiento de un modelo personalizado. ## ¿Qué implementaríamos primero? Demostraríamos la vía nativa con un conjunto pequeño de facturas acordadas. Después implementaríamos una regla ausente cuyo responsable y evidencia estén claros. Mantén la liberación automática dentro del alcance aceptado. Amplía tras observar qué diferencias siguen pendientes y cuánto esfuerzo requiere la revisión. El [coste por flujo aceptado en Odoo](/es/blog/odoo-ai-cost-per-accepted-workflow/) incluye revisión y trabajo fallido. La [guía de software a medida frente a soluciones estándar](/es/software-development-guide/custom-software-vs-off-the-shelf/) ayuda a comparar configuración, módulos e integración mantenida. Para la [integración de API de Wavect](/es/services/api-integration/), prepara una factura que el proceso actual gestione y una excepción cuya regla todavía no consiga imponer. ## Preguntas sobre OCR y excepciones de factura en Odoo ### ¿La confianza del OCR autoriza la contabilización? No. La puntuación de reconocimiento se refiere al contenido extraído, no a la autoridad para contabilizar ni a la corrección de su tratamiento comercial. Define las comprobaciones y aprobaciones que rigen la transición real. Una lectura muy segura de una factura de otra empresa o de una cantidad no recibida puede requerir retención según la política acordada. ### ¿Puede ser legítima una factura de proveedor sin pedido? Los responsables de finanzas y compras deben definir qué clases de factura requieren pedido y qué evidencias necesitan las demás. La ausencia de pedido es una condición de tratamiento que resolver, no una prueba automática de invalidez. No crees un pedido retrospectivo solo para hacer desaparecer la excepción sin la autorización comercial necesaria. ### ¿Una referencia repetida demuestra que hay un duplicado? No. Revisa las identidades documentales y el contexto comercial, incluida la posibilidad de una factura parcial legítima. Conserva los candidatos y el motivo de la decisión. El flujo propuesto deriva la sospecha a revisión; no permite borrar, fusionar ni contabilizar de nuevo automáticamente basándose solo en una cadena de referencia coincidente. ### ¿Debe la factura actualizar los datos bancarios del proveedor? Mantén los cambios de datos maestros fuera de la autoridad de extracción, salvo que un proceso de verificación aprobado aparte los permita. El flujo puede señalar una diferencia y conservar el documento para el responsable autorizado. Una cuenta impresa no debe convertirse silenciosamente en permiso para sustituir el registro aprobado o iniciar un pago. ### ¿Quién define tolerancias de redondeo y tratamiento fiscal? El responsable financiero autorizado establece la política con el asesoramiento profesional correspondiente. Registra moneda, reglas de cálculo, tolerancias y autoridad para excepciones. Los importes de este artículo son entradas aritméticas ficticias. No recomiendan un tipo impositivo, una diferencia aceptable ni el tratamiento de una factura real de proveedor. ### ¿El CSV compara el OCR nativo con un modelo personalizado? No. Especifica doce casos propuestos de aceptación del negocio, todos en NOT_RUN. Una comparación requiere ejecución real, documentos representativos, resultados esperados aprobados independientemente y salidas registradas. Evalúa extracción y liberación posterior por separado, para que una buena lectura no oculte un problema pendiente de recepción, identidad o aprobación. Arquitectura y plataformas ## Qué leer después Decisiones de frameworks, plataformas y sistemas con impacto a largo plazo. [Empieza aquí**Arquitectura Smart City: MQTT, LoRaWAN, Kubernetes y Terraform**](/es/blog/smart-city-architecture-best-practices-2026/) - [Odoo y n8n: crear pedidos sin duplicarlos al reintentar](/es/blog/odoo-n8n-idempotency-recovery/) - [HubSpot y Odoo: ¿quién puede modificar los datos del cliente?](/es/blog/hubspot-odoo-customer-data-ownership/) - [Presupuestos de Odoo desde correo y PDF: revisa productos y precios](/es/blog/odoo-email-pdf-quotation-review/) - [Entregas de proveedores en Odoo: ¿reglas, n8n o un agente de IA?](/es/blog/odoo-native-automation-n8n-ai-agent/) - [Odoo Online a Odoo.sh: ¿la integración exige migrar?](/es/blog/odoo-online-to-sh-integration-decision/) [Artículo anterior**Entregas de proveedores en Odoo: ¿reglas, n8n o un agente de IA?**](/es/blog/odoo-native-automation-n8n-ai-agent/) [Artículo siguiente**Odoo Online a Odoo.sh: ¿la integración exige migrar?**](/es/blog/odoo-online-to-sh-integration-decision/) [**Volver**](/es/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/es/team/kevin-riedl/) [Kevin Riedl](/es/team/kevin-riedl/) https://linkedin.com/in/wsdt 12 minutos de lectura · 5 nov 2026 Última revisión 5 de noviembre de 2026 [**Siguiente**](/es/blog/odoo-bmd-export-reconciliation/)