← Todos los articulos

¿Dónde y de qué tamaño va el QR de Verifactu en la factura?

10 de noviembre de 2026 · Toni Martir, arquitecto de software

Según el reglamento de Verifactu, las sociedades que facturan con un programa tienen que tenerlo adaptado antes del 1 de enero de 2027, y los autónomos y el resto de obligados, antes del 1 de julio. Cada factura que sale de ese programa lleva un código QR con el que quien la recibe puede cotejarla con la Agencia Tributaria. Quien mantiene la plantilla de la factura, el informe que la imprime, tiene que hacerle sitio.

Va arriba, preferiblemente centrado, mide de 30 a 40 milímetros y lleva encima el rótulo «QR tributario:», debajo «VERI*FACTU» si el programa envía los registros de sus facturas a la Agencia, y al menos 2 milímetros en blanco alrededor. En el diseñador hay además un ajuste que se escapa con facilidad: el nivel de corrección de errores, que tiene que ser el M.

Lo que fija la orden

La Orden HAC/1177/2024 desarrolla el artículo 6.5 del reglamento de facturación. Su artículo 21 fija el tamaño, entre 30 × 30 y 40 × 40 milímetros; la norma del código, la ISO/IEC 18004, y el nivel de corrección de errores, el M. Ese nivel es la información de reserva que permite recuperar los datos si el código se mancha o se estropea. Según la web del código QR de Denso Wave, hay cuatro niveles, el M es el más usado y subir de nivel agranda el código.

El QR lleva una URL con cuatro datos de la factura: el NIF de quien la emite, la serie y el número, la fecha y el importe total. La frase «VERI*FACTU», o la larga «Factura verificable en la sede electrónica de la AEAT», sólo la llevan las facturas de programas que envían todos sus registros a la Agencia. Y en una factura electrónica, de las que viajan como datos de un programa a otro, basta con la URL en un campo aparte.

Las fechas de 2027 son las del texto vigente en el BOE; cómo se fijan y quién puede moverlas lo conté en ¿Puede el Gobierno aplazar Verifactu en periodo electoral?

Dónde va y qué lo acompaña

La Agencia Tributaria detalla el resto en su documento técnico del QR. El código va al principio de la factura, antes de su contenido, y una sola vez, en la página 1, aunque la factura tenga varias. En una factura vertical, arriba y preferiblemente centrado; en una apaisada, a la izquierda. Encima va siempre el rótulo «QR tributario:» y debajo, cuando toca, la frase de VERI*FACTU, los dos con letra igual o mayor que la del resto de la factura. Alrededor tienen que quedar al menos 2 milímetros en blanco, y la Agencia recomienda 6. En sus ejemplos en A4, los datos del emisor, con el logotipo, y los del cliente pueden ir a los lados del código, como en la factura de la imagen.

La URL que lleva dentro

La URL apunta al servicio de cotejo de la Agencia, en www2.agenciatributaria.gob.es, y su ruta termina en ValidarQR si el programa es VERI*FACTU, o en ValidarQRNoVerifactu si no lo es. Lleva cuatro parámetros: nif; numserie, la serie y el número, hasta 60 caracteres; fecha, como día-mes-año con guiones, e importe, con punto decimal. Los valores van codificados como en cualquier dirección web: la Agencia pone de ejemplo un número de factura con un &, que tiene que escribirse %26.

Esa URL la genera el programa de facturación, que es el que sabe si emite como VERI*FACTU. Lo práctico es que la guarde con la factura y que el informe se limite a imprimirla.

En el diseñador: el componente de código de barras

Así está hecha la factura de la imagen en Report Manager. El código va en la cabecera del grupo de la factura, que se imprime una vez por factura, y no en la cabecera de página, que se repetiría en cada hoja. Los rótulos «QR tributario:» y «VERI*FACTU» son dos etiquetas centradas encima y debajo, en negrita y a 10 puntos, el mismo tamaño que los datos. El código es un componente de código de barras con estas propiedades:

Dos de esas propiedades tienen trampa. El nivel de corrección se elige en «Nivel ECC», que en las versiones anteriores del diseñador se llama «PDF417 ECC», y el valor que da el nivel M depende del motor que imprime el informe. Con el de Delphi y Lazarus, el que usan los diseñadores de Delphi y de Lazarus, printreptopdf y el servidor web de informes, es Level1; con el de .NET, el que usan el diseñador .NET, el diseñador web y Reportman Server, es Level3. Con Auto, el valor por defecto, los dos imprimen el QR con nivel L.

La otra es el tamaño. El componente reserva dentro de su cuadro un margen blanco de cuatro módulos, los cuadraditos de los que está hecho el código. En el PDF de la factura, hecho con el motor de Delphi y Lazarus, con un cuadro de 4 × 4 cm, el código mide 33,3 milímetros y el margen, casi 3 por lado, más de los 2 que pide la Agencia. Con un cuadro de 3 × 3 cm, el código se queda en 25,4 milímetros, por debajo de los 30. Con 4 cm cumple tanto si se mide el código solo como si se mide con su margen.

Comprobar que se lee

Antes de dar la plantilla por buena, hay que leer el código. Decodifiqué el QR de la vista previa y el del PDF, y los dos devuelven la URL exacta, con nivel M. Con la cámara del móvil basta: tiene que salir la URL con el NIF, el número, la fecha y el importe de esa factura. Para probar sin usar la dirección de producción, la Agencia tiene un entorno de pruebas, en prewww2.aeat.es, que es el que lleva la factura del ejemplo.

Entonces, ¿dónde y de qué tamaño?

Arriba, preferiblemente centrado, una sola vez, de 30 a 40 milímetros y con nivel M, entre «QR tributario:» y «VERI*FACTU», con al menos 2 milímetros en blanco. En el diseñador: tipo QR, la URL en la expresión, un cuadro de 4 × 4 cm y, en «Nivel ECC», Level1 con el motor de Delphi y Lazarus o Level3 con el de .NET. Registrar y enviar cada factura es cosa del programa de facturación: la plantilla sólo imprime el código.

Report Manager imprime códigos QR a partir de un campo o de una expresión (componente de código de barras, documentación en inglés), y la plantilla de la factura es el mismo archivo .rep para el diseñador, printreptopdf, el servidor web de informes y Reportman Server, aunque el nivel M se pide con un valor distinto en cada motor.

Fuentes

• Real Decreto 1007/2023, de 5 de diciembre, reglamento de los sistemas informáticos de facturación, texto consolidado (última actualización publicada el 3 de diciembre de 2025): disposición final cuarta, «los obligados tributarios a que se refiere el artículo 3.1.a) deberán tener adaptados los sistemas informáticos a las características y requisitos establecidos en este reglamento y en su normativa de desarrollo antes del 1 de enero de 2027. El resto de obligados tributarios mencionados en el artículo 3.1 deberán tener operativos los citados sistemas informáticos antes del 1 de julio de 2027»; y artículo 3.1, «a) Los contribuyentes del Impuesto sobre Sociedades», «b) Los contribuyentes del Impuesto sobre la Renta de las Personas Físicas que desarrollen actividades económicas», entre otros.
• Real Decreto 1619/2012, reglamento de facturación, artículo 6.5: «a) La representación gráfica del contenido parcial de la factura mediante un código “QR”» y «b) Estas facturas, sean electrónicas o no, incorporarán además la frase “Factura verificable en la sede electrónica de la AEAT” o “VERI*FACTU” únicamente en aquellos casos en los que el sistema informático realice la remisión de todos los registros de facturación a la Agencia Estatal de Administración Tributaria».
• Orden HAC/1177/2024, de 17 de octubre: artículo 20.2, en una factura electrónica «se deberá incluir como un campo independiente la “URL” contenida en el código “QR”, no siendo necesario incluir el propio código “QR”»; y artículo 21, «El código “QR” deberá tener un tamaño entre 30x30 y 40x40 milímetros y seguir las especificaciones de la norma ISO/IEC 18004. Para la generación del código “QR” se empleará el nivel M (medio) de corrección de errores», su contenido (NIF del obligado a expedir la factura, número de serie y número, fecha de expedición e importe total) y «dependiendo de si el sistema informático que expide la factura y genera su correspondiente código “QR” es o no un sistema informático “VERI*FACTU”».
• Agencia Tributaria, Detalle de las especificaciones técnicas del código «QR» de la factura, versión 0.5.0 de 10 de diciembre de 2025, enlazado desde la sede electrónica. Apartado 3: «se deben mantener como mínimo 2 milímetros de espacio vacío (en blanco) alrededor de los cuatro lados del código “QR”, recomendándose que sean 6 milímetros», «se situará al principio de la factura, antes de que empiece el contenido de ésta», «Si la factura ocupara varias páginas, el código “QR” aparecería una única vez, en la primera página», en vertical «arriba de esta, próximo al margen superior, preferiblemente centrado», en apaisado «a la izquierda de esta», «un texto que siempre deberá ir precediéndolo: “QR tributario:”», la frase de VERI*FACTU «justo debajo del código “QR”» y los dos textos con letra «siempre iguales o superiores a los del resto de datos de la factura». Apartado 4: los parámetros «deberán ser codificados de forma adecuada siguiendo los estándares generales de las aplicaciones en entorno web (“URL encoding”) y utilizando la codificación UTF-8», con el ejemplo del número «12345678&G33» escrito «12345678%26G33». Apartado 5.1: las URL de producción, en www2.agenciatributaria.gob.es, y del entorno de pruebas, en prewww2.aeat.es, las dos con la ruta /wlpl/TIKE-CONT/ValidarQR; apartado 5.2, la misma terminada en ValidarQRNoVerifactu. Apartado 6: nif de 9 caracteres, numserie de «Máximo 60 caracteres», fecha «DD-MM-AAAA» e importe con «el “.” (punto) para separar la parte entera de la decimal». Anexo, ejemplo i): en A4 vertical, los espacios a los lados del QR para «datos referidos al emisor (incluido el logotipo) o al destinatario, se considera compatible con el código “QR” al principio de la factura».
• Denso Wave, Error correction feature: «QR Code has error correction capability to restore data if the code is dirty or damaged. Four error correction levels are available for users to choose according to the operating environment. Raising this level improves error correction capability but also increases the amount of data QR Code size.» y «Typically, Level M (15%) is most frequently selected.»
• Report Manager: características, «barcodes (including QR)» y «The barcode is read from a expression or database field»; componente de código de barras, tipo «QR 2D barcode, see ECC Level», «The value of the barcode is obtained evaluating this expression», y en «ECC Level», «Error correction level of the 2D barcodes, PDF417 and QR»: con el motor «Delphi and Lazarus engine (VCL and LCL designers, printreptopdf, repweb, ActiveX)», Level 1 es M; con el «.NET engine (.NET designer, web designer, Reportman Server)», Level 3 es M; en los dos, Auto es L; y «So a report printed by both engines gets the same QR only with L (Auto, Level 0, or Level 6 to 8); for M, Q or H choose the value of the engine that prints it.»; y Reportman Server, «Los informes son los mismos ficheros .rep que leen el diseñador Delphi, printreptopdf y el Servidor Web de informes».
• Prueba propia, 10 de noviembre de 2026: la factura de la imagen, con datos inventados en una base SQLite, en la vista previa del diseñador de Report Manager 4.0.16 para Linux y en PDF con printreptopdf 4.0.16. Con el cuadro de 4 × 4 cm, el QR del PDF tiene 45 × 45 módulos de 0,741 mm (33,34 mm) y un margen de 4 módulos (2,96 mm) por lado; con 3 × 3 cm, 25,40 mm. Leído con un decodificador propio, los dos con el motor de Delphi y Lazarus: con la corrección de errores, que en esa versión se llama «PDF417 ECC», en Level1, nivel M; en Auto, nivel L. El nombre «Nivel ECC» es el de la traducción al castellano del diseñador. El QR de la vista previa y el del PDF contienen la URL del entorno de pruebas con nif=89890001K, numserie=FA2026%2F0125, fecha=10-11-2026 e importe=285.44, sin errores en sus bloques de corrección. El NIF 89890001K es el de los ejemplos de la Agencia.

Toni Martir, arquitecto de software · 10 de noviembre de 2026 · fuentes comprobadas el 10 de noviembre de 2026