Skip to main content

Receipt Layout - VERI*FACTU

Introduction and Purpose​

These specifications are mandated by Spanish regulations (Articles 20 and 21 of Order, Royal Decree 1007/2023, and Article 6.5 of Royal Decree 1619/2012) and aim to standardise invoicing processes, particularly for businesses and professionals, and combat fiscal fraud.

QR Code Specifications and Presentation​

The QR code on the invoice must adhere to specific technical, physical, location, and presentation conditions.

Key requirements

  • High Contrast
    The colour contrast between the QR code and its background must be sufficient to ensure readability.

  • Quiet Zone
    A minimum of 2mm of empty (white) space is required around all four sides of the QR code. A 6mm space is recommended.

  • Prominent Location
    The QR code should generally be placed at the beginning of the invoice, before the main content generated by the invoicing system. If this is not possible due to justified obstacles, it must still be clearly visible, separated, and distinguished from other content and any other QR codes on the invoice, occupying a prominent position.

  • First QR Code
    If a multi-page invoice contains other QR codes, the tax QR code should be the first one to appear. It should only appear once on the first page of the invoice.

  • Orientation-Specific Placement
    For vertically oriented invoices, the QR code should be at the top, near the upper margin, preferably centred horizontally or towards the top-left.

  • For horizontally oriented invoices
    the QR code should be on the left, preferably near the upper-left margin or centred vertically.

  • Accompanying Text
    There must be text preceding the QR code. For VERIFACTU systems, a specific phrase must also be included. This text must be in a legible font size equal to or larger than other invoice data. Examples of accompanying text are provided in the annex, including "QR tributario:" and phrases like "Factura verificable en la sede electrónica de la AEAT" (long phrase) or "VERIFACTU" (short phrase).

URL of the QR Code and Information Service​

The QR code contains a URL that directs to an AEAT electronic service for verifying or submitting invoice information. The format of this URL depends on whether the invoicing system is VERI*FACTU certified (emitting "verifiable" invoices) or not, and the environment (test or production).

  • URL Structure
    The URL includes mandatory parameters. An example of the base URL for a verifiable invoice system in the production environment can be found here.

  • Mandatory Parameters
    The URL must contain exactly four mandatory parameters:

    • nif: The NIF (tax identification number) of the invoice issuer (9 characters).
    • numserie: The invoice series and number (maximum 60 ASCII characters from 32-126). Special characters need URL encoding.
    • fecha: The invoice date in DD-MM-AAAA format (10 characters).
    • importe: The total invoice amount with decimals, using "." as the decimal separator (maximum 12 digits before and 2 digits after the decimal point).

  • URL Encoding
    Parameter values, especially numserie which can contain special characters, must be URL encoded. An example using Java code is provided to illustrate this process.

  • Optional Parameter
    An optional fifth parameter, formato, with the value "json", can be appended to the URL (but not in the QR code itself) to receive the response from the AEAT service in JSON format. This facilitates automated processing by third-party applications.

Response Examples and Error Codes​

The document provides examples of both successful ("OK") and unsuccessful ("KO") responses from the AEAT service.

Successful Responses (OK)

  • Verifiable Invoices
    • Responses indicate whether the invoice is found (received by AEAT) or not found (including annulled invoices). Responses can be in HTML (for direct URL access) or JSON (when the formato=json parameter is used).
  • Non-Verifiable Invoices
    • Responses confirm that the invoice was issued by a non-verifiable system, stating that it cannot be verified automatically but can assist AEAT with tax control and fraud prevention. Responses are also available in HTML and JSON.

Incorrect Responses (KO)

  • These occur due to validation errors, such as missing or incorrectly formatted parameters (e.g., NIF, date, or amount). Error messages are provided in both HTML and JSON formats, along with specific error codes.
Example Response
{
    "TraC": {
        "SQ": 5,
        "Result": {
            "RC": "OK"
        },
        "ESR": {
            "D": "2025-05-12T13:55:09",
            "T": "8.38",
            "TN": "492",
            "FN": "2025.1-001-1-492",
            "TaxA": [
                {
                    "_": "Tax",
                    "TaxG": "A",
                    "Prc": "21",
                    "Net": "4.53",
                    "TAmt": "0.95",
                    "Amt": "5.48"
                },
                {
                    "_": "Tax",
                    "TaxG": "B",
                    "Prc": "10",
                    "Net": "2.64",
                    "TAmt": "0.26",
                    "Amt": "2.90"
                }
            ]
        },
        "Fis": {
            "Tag": [
                {
                    "Label": "",
                    "Value": "*** TEST MODE ***",
                    "Name": "Testmode"
                },
                {
                    "Label": "Factura",
                    "Value": "2025.1-001-1-492",
                    "Name": "FN"
                },
                {
                    "Label": "Código Seguro de Verificación",
                    "Value": "A-U9GLYR7JY792GA",
                    "Name": "CSV"
                }
            ],
            "Code": "https://prewww2.aeat.es/wlpl/TIKE-CONT/ValidarQR?nif=123456789&numserie=2025.1-001-1-492&fecha=12-05-2025&importe=8.38"
        }
    }
}

Error Codes

  • A list of validation error codes and their descriptions is provided (ranging from 1001 to 3002), covering issues like missing parameters, incorrect formats, invalid NIF/NIE, exceeding character limits, and technical errors or access blocks on AEAT systems.

Ticket Layout Examples​

The following examples are taken from the technical specifications for the VERI*FACTU QR code. The images provided are for informational purposes only and do not represent valid dimensions or content. Please consult the efsta validation checklist to ensure compliance.

Receipt-Example1 Receipt-Example2

Legal Framework

The technical specifications outlined on this page are based on legal provisions which you can find as PDF at agenciatributaria.es.