Cómo validar automáticamente que base + IVA − IRPF cuadra con el total al extraer una factura

Si solo vas a automatizar una comprobación después del OCR, que sea esta: base imponible + cuota de IVA − retención de IRPF = total de la factura, verificada al céntimo con una tolerancia explícita de un céntimo por bloque de tipo impositivo. Es la única regla que caza el error de extracción más caro: un importe *verosímil* pero equivocado. Un nombre de proveedor mal leído salta a la vista. Un total desviado 31,50 € no, y se queda en la contabilidad hasta que la conciliación bancaria falla tres semanas después.

Esos 31,50 € no son un ejemplo inventado: corresponden al error aritmético más frecuente de toda la factura. La retención se calcula siempre sobre la base imponible, nunca sobre el importe con IVA. En una factura profesional de 1.000 € con IVA 21% e IRPF 15%, el total correcto es 1.000 + 210 − 150 = 1.060,00 €. Si aplicas el 15% sobre los 1.210 € con IVA, obtienes 181,50 € de retención y un total de 1.028,50 €: una diferencia de 31,50 € que no cuadra contra nada y que además declararás mal en el modelo 111. Las calculadoras que posicionan para esta consulta te dan la fórmula; lo que sigue es cómo convertirla en una puerta automática que se ejecuta en cada documento extraído.

Por qué automatizarlo: el benchmark de IOFM de 2025 sitúa la tasa media de error en introducción manual de datos en torno al 3,6%, y las encuestas del sector cifran en unos 53 dólares el coste medio de resolver un error de factura. Con 400 facturas al mes, ese 3,6% son unos 14 errores; la comprobación no necesita cazarlos todos para pagarse sola.

La regla, escrita para que la ejecute una máquina

Para cada factura extraída:

`suma(base_i) + suma(base_i × tipo_iva_i) + suma(base_i × recargo_i) − retención − |total| ≤ tolerancia`

Y, por separado, en cada bloque de tipo:

`cuota_iva_i ≈ base_i × tipo_iva_i` (es en esencia la regla que aplica el SII al validar los envíos: la cuota declarada debe corresponderse con base × tipo, con solo unos céntimos de margen antes de que la factura se rechace o se acepte con errores)
`retención ≈ suma(base_i) × tipo_retención`, calculada sobre la base y con el IVA fuera

Tres cosas lo complican más de lo que parece, y son justo donde se rompen las implementaciones ingenuas.

1. No fijes el tipo a fuego

Deduce el tipo de los propios importes y contrástalo contra el conjunto de tipos legales. En España conviven IVA al 21 / 10 / 4% e IRPF profesional del 15%, con el 7% para nuevos autónomos durante los tres primeros años de actividad y para determinadas actividades. Un validador que dé por hecho «15%» disparará falsas alarmas en la mitad de tus proveedores. Deja que la extracción devuelva el tipo que el proveedor imprimió, recalcúlalo desde base e importe, y avisa solo cuando ambos no coincidan.

2. Varios bloques de tipo en una misma factura

Un proveedor que te factura mercancía al 21% y portes al 10% genera dos bloques. Comprueba cada uno por separado y luego suma. Ejemplo: 800 al 21% (=168,00) más 200 al 10% (=20,00), retención del 15% sobre la base total de 1.000 (=150,00), total 1.038,00 €. Si solo lees la línea de IVA más grande —el atajo típico de una extracción de campo único— obtienes 1.000 + 210 − 150 = 1.060,00 y un desfase fantasma de 22 €.

3. Líneas que están en el total pero no en la base

Hay importes que forman parte del total sin formar parte de la base imponible ni de la base de retención:

Suplidos pagados en nombre del cliente: fuera de la base, fuera del IVA y fuera de la retención.
Recargo de equivalencia en facturas a minoristas: 5,2% sobre el IVA del 21%, 1,4% sobre el 10% y 0,5% sobre el 4%. Suma al total y nunca toca la base.
Cuotas de colegios o mutualidades repercutidas: según el caso entran o no en la base de retención.

Si tu comprobación se limita a sumar «todo lo que parezca un número», estas tres producirán falsos positivos constantes y el equipo acabará ignorando los avisos, que es peor que no tenerlos.

Cuánta diferencia es aceptable

Usa ±0,01 € por bloque de tipo, más ±0,01 € por la línea de retención. Una factura de tipo único tolera 0,02 €; una de dos tipos, 0,03 €. No es laxitud, es aritmética: los proveedores redondean legítimamente unos por línea y otros sobre el subtotal del bloque, y los dos métodos divergen uno o dos céntimos en facturas largas. Por encima de esa tolerancia ya no es redondeo: o es un dígito mal leído o es una factura genuinamente mal emitida.

Separa el resultado en tres estados, no en dos:

Verde — dentro de tolerancia. Contabilizar. Nada que revisar.
Ámbar — unos céntimos por encima. Casi siempre diferencia de política de redondeo o confusión entre coma y punto decimal en el OCR. A una cola de revisión de cinco segundos.
Rojo — desviación con patrón conocido. Retención calculada sobre el total con IVA, bloque de tipo perdido, dígito transpuesto (7↔1, 3↔8, 6↔5 son las confusiones clásicas del OCR en escaneos malos). Vuelta a extraer o entrada manual.

La diferencia *en sí misma* es diagnóstica. Si el desfase equivale exactamente a `retención × tipo_iva`, has encontrado el error número uno. Si equivale a un bloque entero, te falta un bloque. Si es una potencia de diez limpia, alguien perdió o añadió un dígito.

Dónde encaja esto en el flujo

La comprobación tiene que ejecutarse en el momento de la extracción, en el mismo segundo en que se producen los datos. Una validación que corre semanalmente dentro del programa de contabilidad es un informe; una que corre al extraer es una puerta. Con WhappScan el sitio natural es justo cuando llega el documento: el proveedor o un compañero manda la foto o el PDF al número de WhatsApp, los campos vuelven estructurados y la comprobación aritmética se ejecuta sobre esos campos antes de que nada llegue al Excel o al ERP. Si lo montas sobre una integración propia, los mismos campos salen por API y la validación puede vivir en tu lado: mira cómo enviar tus facturas a Excel o a tu ERP por API y, en el lado de la captura, cómo automatizar la extracción de facturas por WhatsApp.

Un detalle práctico: define la comprobación sobre una plantilla que ya declare base, tipo de IVA, cuota, tipo de retención, importe retenido y total como campos separados. Si la extracción te devuelve un bloque de texto, no hay nada que validar. Campos estructurados por bloque de tipo son el requisito previo, no un extra — por la misma razón por la que preparar bien las facturas de proveedor antes de pasárselas al asesor ahorra el ida y vuelta del cierre trimestral. Si trabajas desde una gestoría, ese flujo completo —captura, extracción, validación— es justo lo que cubre WhappScan para gestorías y contabilidad.

La siguiente comprobación que deberías añadir

Cuando la validación aritmética esté en verde de forma sistemática, la regla con mejor retorno es la detección de duplicados: mismo NIF de proveedor, mismo número de factura, mismo total. Cuesta casi nada calcularla sobre campos ya extraídos y caza la clase de error que la aritmética nunca verá: una factura perfectamente correcta contabilizada dos veces. Lo tienes en cómo detectar facturas duplicadas antes de contabilizarlas.

Y un apunte de calendario: Verifactu quedó aplazado a 2027 (1 de enero de 2027 para contribuyentes del Impuesto sobre Sociedades y 1 de julio de 2027 para autónomos) tras el Real Decreto-ley 15/2025. Regula las facturas que *emites*, no las que recibes, pero la disciplina es la misma: tener limpia la aritmética de las recibidas ahora significa menos que desenredar después.

Pruébalo con una factura real

Coge la factura más incómoda que tengas encima de la mesa —la de dos tipos de IVA y línea de retención— y extráela. Después haz tú la aritmética de tres líneas y comprueba si los números coinciden.

Extrae los datos de tu documento gratis, sin cuenta y sin instalar nada, en /es/free.