En este artículo
OCR de facturas en Odoo: ¿cuándo necesitas un flujo de excepciones?
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 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 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 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 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. 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. 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.
- Aprueba primero la política. Finanzas y operaciones definen qué debe retener una factura y quién puede liberarla.
- Registra la configuración inicial. Incluye versión, módulos, controles, contabilización automática y permisos técnicos.
- Prueba un caso conforme y su excepción cercana. Mantén los importes y cambia, por ejemplo, la cantidad recibida de diez a ocho.
- Inspecciona todas las rutas relevantes. Demuestra una transición permitida y un intento de elusión con la identidad real. Conserva el estado resultante.
- Cambia las evidencias. Modifica una entrada material después de revisarla y verifica que la aprobación anterior no autoriza otro estado de factura.
- 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 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 incluye revisión y trabajo fallido. La guía de software a medida frente a soluciones estándar ayuda a comparar configuración, módulos e integración mantenida. Para la integración de API de Wavect, prepara una factura que el proceso actual gestione y una excepción cuya regla todavía no consiga imponer.