A continuación mostramos los dos ejemplos más sencillos y comunes de facturas: simplificada y normal.
La factura simplificada es posible en determinados casos como por ejemplo cuando los importes son pequeños. Este tipo de factura conlleva unos requisitos de información menores a la factura normal, no siendo obligatorio por ejemplo incluir información fiscal sobre el destinatario. A ojos de la administración tributaria, los "tickets" por importes pequeños son facturas simplificadas.
Este tipo de factura se genera haciendo una llamada al endpoint /verifactu/create utilizando el campo tipo_factura igual a F2.
{ "serie": "Ejemplos", "numero": "1", "fecha_expedicion": "24-02-2025", "tipo_factura": "F2", "descripcion": "Descripcion de la operacion: factura simplificada", "lineas": [ { "base_imponible": "200", "tipo_impositivo": "21", "cuota_repercutida": "42" } ], "importe_total": "242" }
La factura normal conlleva obligaciones de información superiores a las de la factura simplificada, siendo obligatorio especificar datos fiscales del receptor de la misma. Este tipo de factura se genera utilizando el campo tipo_factura igual a F1.
Hay dos opciones para identificar al destinatario de la factura. Una es mediante los campos nif y nombre, lo cual requiere que dicho NIF se encuentre identificado en la AEAT. A continuación se muestra un ejemplo de dicha factura.
{ "serie": "Ejemplos", "numero": "2", "fecha_expedicion": "24-02-2025", "tipo_factura": "F1", "descripcion": "Descripcion de la operacion: factura normal", "nif": "A15022510", "nombre": "Empresa de prueba SL", "lineas": [ { "base_imponible": "200", "tipo_impositivo": "21", "cuota_repercutida": "42" } ], "importe_total": "242" }
En caso de querer emitir una factura normal a alguien que no dispone de un NIF identificado en la AEAT, se deben utilizar los campos id_otro y nombre en su lugar. El campo id_otro contiene información del país del destinatario, el tipo de documento identificador y el indentificador mismo. Los detalles sobre las diferentes opciones que ofrece el campo id_otro se pueden encontrar en la documentación de la API aquí.
Un ejemplo de factura normal emitida a un ciudadano alemán identificado mediante el número de pasaporte es:
{ "serie": "Ejemplos", "numero": "2", "fecha_expedicion": "24-02-2025", "tipo_factura": "F1", "descripcion": "Descripcion de la operacion: factura normal pasaporte", "id_otro": { "codigo_pais": "DE", "id_type": "03", "id": "F8624KW3J6" }, "nombre": "Empresa de prueba SL", "lineas": [ { "base_imponible": "200", "tipo_impositivo": "21", "cuota_repercutida": "42" } ], "importe_total": "242" }
Una operación frecuente consiste en transformar una factura simplificada en una factura normal, lo que se conoce como factura de canje.
Supongamos que hemos enviado un registro de facturación correspondiente a una factura simplificada, es decir, una con tipo_factura igual a F2 en la que no se identifica al destinatario.
{ "serie": "SIMPLE", "numero": "1", "fecha_expedicion": "10-03-2025", "tipo_factura": "F2", "descripcion": "Descripcion de la operacion", "lineas": [ { "base_imponible": "200", "tipo_impositivo": "21", "cuota_repercutida": "42" } ], "importe_total": "242" }
Si, una vez emitida esta factura, nos surge la necesidad de identificar al destinatario tenemos dos opciones dentro del sistema Verifactu, que mostramos a continuación.
La primera opción requiere el envío de dos registros de facturación adicionales, uno correspondiente a una factura de abono (importe total negativo) y otro para emitir la factura ordinaria.
{ "serie": "SIMPLE", "numero": "2", "fecha_expedicion": "11-03-2025", "tipo_factura": "F2", "descripcion": "Factura de abono", "lineas": [ { "base_imponible": "-200", "tipo_impositivo": "21", "cuota_repercutida": "-42" } ], "importe_total": "-242" }
A continuación se procede a emitir una factura ordinaria con tipo_factura igual a F1.
{ "serie": "EJEMPLO", "numero": "1", "fecha_expedicion": "11-03-2025", "tipo_factura": "F1", "descripcion": "Descripcion de la operacion: factura normal", "nif": "A15022510", "nombre": "Empresa de prueba SL", "lineas": [ { "base_imponible": "200", "tipo_impositivo": "21", "cuota_repercutida": "42" } ], "importe_total": "242" }
Aunque este procedimiento requiere el envío de dos registros de facturación adicionales, tiene la ventaja de ser muy fácil de trabajar con él ya que fácilmente se ve que la suma total de los tres registros de facturación suman a lo que debería.
Una manera alternativa de realizar la misma operación es hacerlo en un único paso creando un resgistro de facturación con tipo_factura igual a F3 (sustitutiva de factura simple). A continuación se muestra un ejemplo del JSON que se debería enviar.
Como se puede ver, la serie y el número de la factura sustitutiva son diferentes a la de la factura simplificada original. Usando el campo facturas_sustituidas se indican las facturas que se sustituyen. En general, este campo es de tipo array ya que se puede hacer referencia a varias facturas.
{ "serie": "SUSTITUTIVA", "numero": "1", "fecha_expedicion": "19-12-2024", "tipo_factura": "F3", "descripcion": "Descripcion de la operacion", "nif": "A15022510", "nombre": "Empresa de prueba SL", "lineas": [ { "base_imponible": "200", "tipo_impositivo": "21", "cuota_repercutida": "42" } ], "facturas_sustituidas": [ { "serie": "SIMPLE", "numero": "1", "fecha_expedicion": "19-12-2024" } ], "importe_total": "242" }
Las facturas rectificativas son documentos esenciales para corregir errores o modificar datos de facturas previas. En la API Verifactu de la Administración, la creación de una factura rectificativa requiere indicar el tipo de rectificación mediante el campo tipo_factura. Existen cinco opciones, cada una basada en artículos específicos de la Ley del IVA (Ley 37/1992) y sus regulaciones.
Supongamos que queremos rectificar la factura con serie A y número 1 que ha sido emitida con fecha 19-12-2024.
Debemos crear una factura nueva llamando al endpoint /verifactu/create indicando tipo_factura igual a R1 y tipo_rectificativa igual a S. Aunque no es obligatorio hacer referencia a la factura que se quiere rectificar, se puede hacer usando el campo factura_rectificada.
A continuación se muestra un ejemplo del body que podría incluirse.
{ "serie": "RECTIFICATIVA", "numero": "4", "fecha_expedicion": "25-02-2025", "tipo_factura": "R1", "descripcion": "Descripcion de la operacion: rectificacion por diferencia", "nif": "A15022510", "nombre": "Empresa de prueba SL", "lineas": [ { "base_imponible": "200", "tipo_impositivo": "21", "cuota_repercutida": "42" } ], "importe_total": "242", "tipo_rectificativa": "I", "facturas_rectificadas": [ { "serie": "SIMPLE", "numero": "1", "fecha_expedicion": "19-12-2024" } ] }
Si por el contrario quisieramos rectificar una factura por sustitución, debemos llamar al endpoint /verifactu/create indicando tipo_factura igual a R1 y tipo_rectificativa igual a S. Esto nos obliga a cumplimentar el campo importe_rectificativa con la información de la factura rectificativa. Por último, podemos hacer referencia a la factura (o facturas) que se quiere rectificar usando el campo facturas_sustituidas.
{ "serie": "RECTIFICATIVA", "numero": "4", "fecha_expedicion": "25-02-2025", "tipo_factura": "R1", "descripcion": "Descripcion de la operacion: rectificacion por sustitución", "nif": "A15022510", "nombre": "Empresa de prueba SL", "lineas": [ { "base_imponible": "200", "tipo_impositivo": "21", "cuota_repercutida": "42" } ], "importe_total": "242", "tipo_rectificativa": "S", "importe_rectificativa": { "base_rectificada": "400", "cuota_rectificada": "84", "cuota_recargo_rectificada": "0" }, "facturas_rectificadas": [ { "serie": "SIMPLE", "numero": "1", "fecha_expedicion": "19-12-2024" } ] }
La API de Verifacti contiene el endpoint /verifactu/modify que se corresponde con la operación que la administración llama "subsanación" de registro de facturación. Es importante entender que es muy poco frecuente verse en la situación de tener (o poder) realizar esta operación. A pesar de lo que el nombre pueda sugerir, esto no tiene nada que ver con las facturas rectificativas.
Este endpoint solo puede usarse para subsanar registros de facturación en aquellos casos en los que la subsanación no tiene ninguna repercusión fiscal, lo que limita mucho su uso.
A continuación incluimos los tres ejemplos en los que sí se puede usar este endpoint, controlados por el campo rechazo_previo, y que dejan claro que no es algo que se vaya a hacer de forma habitual.
Supongamos que enviamos el siguiente registro de facturación, al que llamaremos Registro A, que ha sido aceptado correctamente por la Agencia Tributaria:
{ "serie": "Ejemplos", "numero": "1", "fecha_expedicion": "24-02-2025", "tipo_factura": "F1", "nif": "A15022510", "nombre": "Empresa de prueba SL", "descripcion": "Descripcion inicial", "lineas": [ { "base_imponible": "200", "tipo_impositivo": "21", "cuota_repercutida": "42" } ], "importe_total": "242" }
{ "rechazo_previo": "N", "serie": "Ejemplos", "numero": "1", "fecha_expedicion": "24-02-2025", "tipo_factura": "F1", "nif": "A15022510", "nombre": "Empresa de prueba SL", "descripcion": "Descripcion modificada", "lineas": [ { "base_imponible": "200", "tipo_impositivo": "21", "cuota_repercutida": "42" } ], "importe_total": "242" }
Supongamos ahora que la factura inicial del párrafo anterior (Registro A) hubiera causado rechazo en la AEAT porque el certificado usado para enviarla no estaba vigente. En ese caso, el registro de facturación sería rechazado y habría que generar un nuevo registro de subsanación marchando el campo rechazo_previo=X.
{ "rechazo_previo": "X", "serie": "Ejemplos", "numero": "1", "fecha_expedicion": "24-02-2025", "tipo_factura": "F1", "nif": "A15022510", "nombre": "Empresa de prueba SL", "descripcion": "Descripcion inicial", "lineas": [ { "base_imponible": "200", "tipo_impositivo": "21", "cuota_repercutida": "42" } ], "importe_total": "242" }
Supongamos ahora que la factura inicial del párrafo anterior (Registro A) hubiera sido aceptada correctamente y, en cambio, hubiera sido rechazado el registro de subsanación siguiente (Registro B). En ese caso, deberíamos generar y enviar un nuevo registro de subsanación, marcando el campo rechazo_previo=S.
{ "rechazo_previo": "S", "serie": "Ejemplos", "numero": "1", "fecha_expedicion": "24-02-2025", "tipo_factura": "F1", "nif": "A15022510", "nombre": "Empresa de prueba SL", "descripcion": "Descripcion modificada", "lineas": [ { "base_imponible": "200", "tipo_impositivo": "21", "cuota_repercutida": "42" } ], "importe_total": "242" }
Como se puede ver, debido a la limitación de que las modificaciones no tengan impacto fiscal, el endpoint de subsanación /verifactu/modify tiene muy pocos casos de uso.