¿Qué datos deben incluirse en la factura se entrega al cliente?
La factura debe ser entregada al receptor (ya sea en versión impresa o digital) con un QR de cotejo que le permita verificar que la factura ha sido correctamente remitida a la AEAT.
Junto al QR deberá aparecer la frase «Factura verificable en la sede electrónica de la AEAT» o «VERI*FACTU», que deberá tener un tipo de letra y tamaño bien visibles, similares a los del resto de datos de la factura. El código QR deberá tener un tamaño entre 30x30 y 40x40 milímetros.
¿Qué debo hacer si cuando Veri*Factu “rechaza” una de mis facturas?
En estos casos hay que emitir una subsanación CON registro previo rechazado.
Para subsanar un registro que ha sido rechazado anteriormente por Veri*Factu debemos enviar el campo correction_key con el valor S y el campo previous_rejection_key con el valor X. También deberán modificarse los campos que deban ser corregidos.
Caso de ejemplo
Dado la secuencia de facturas F4 → F5 → F6, donde cada factura se genera encadenada a la anterior. El resultado del envío es:
- F4: Aceptada, encadenada a la factura del emisor anteriormente procesada por el SIF. Probablemente la F3.
- F5: Recibida, pero rechazada (no queda registrada en la AEAT). Encadenada a F4.
- F6: Aceptada. Encadenada a F5.
F6 apunta a F5, aunque F5 no exista en la AEAT como registro válido, al haber sido rechazado. Esto es válido y está contemplado por el sistema, ya que la AEAT entiende que F5 existió pero fue rechazada y que se ha subsanado o se va a subsanar como indicamos a continuación.
En este punto hay que generar un registro de subsanación por rechazo previo de F5 con:
previous_rejection_key = Xcorrection_key = S
El registro de subsanación de F5 se encadena al último registro válido del emisor, existente en el SIF en ese momento. En este ejemplo sería F6.
¿Qué debo hacer cuando Veri*Factu “acepta con errores” una de mis facturas?
En estos casos hay que emitir una subsanación ordinaria, es decir, una subsanación SIN registro previo rechazado.
Para subsanar un registro que ha sido aceptado con errores por Veri*Factu debemos enviar el campo correction_key con el valor S y hay que obviar el campo previous_rejection_key. También deberán modificarse los campos que deban ser corregidos.
Caso de ejemplo
Dado la secuencia de facturas F4 → F5 → F6, donde cada factura se genera encadenada a la anterior. El resultado del envío es:
- F4: Aceptada, encadenada a la factura del emisor anteriormente procesada por el SIF. Probablemente la F3.
- F5: Aceptada con errores (queda registrada en la AEAT). Encadenada a F4.
- F6: Aceptada. Encadenada a F5.
En este punto hay que generar un registro de subsanación de F5 con:
El registro de subsanación de F5 es un registro independiente del de alta y se encadena al último registro válido del emisor, existente en el SIF en ese momento. En este ejemplo sería F6.
¿Qué debo hacer si no puedo enviar un registro porque VeriFactu tiene problemas técnicos de conexión o no ha superado las validaciones básicas de VeriFactu?
Si el envío falla por un problema técnico de conexión con el servidor de Veri*Factu (timeout, error del servidor o falta de respuesta) o por no haber superado las validaciones básicas de Veri*Factu, no debes modificar la registro ni generar un nuevo registro de alta de la misma factura o anulación.
Los fallos de conexión o de validaciones básicas de Veri*factu se identifican porque la respuesta de nuestra API incluye el campo "vf_post_status": "failure".
Un error de validación básica de VeriFactu ocurre, por ejemplo, cuando los datos del emisor de la factura no son válidos (CIF incorrecto, razón social desconocida, etc.). En estos casos los registros quedan marcados con el campo "vf_post_status": "failure".
Hay un límite de 12 líneas (conceptos) para las facturas. ¿Qué debo hacer si un cliente emite facturas con más de 12 líneas?
La lista de los conceptos facturados deben agruparse por condición fiscal completa. En ese sentido, el número máximo de líneas es de 12.
Esta agrupación responde a la condición fiscal de la operación, y no puede realizarse únicamente por tipo impositivo.
CONDICIÓN FISCAL COMPLETA =
tax_rate +
vat_tax_regime_key o igic_tax_regime_key +
equalization_tax_rate (si aplica)
Caso 1: Factura con todas las líneas al 21%
Si las líneas al 21% se acogen a regímenes diferentes, deben generarse múltiples agrupaciones en el desglose, cada una con su combinación única de tax_rate + vat_tax_regime_key o igic_tax_regime_key + equalization_tax_rate (si aplica).
Ejemplo válido:
- Línea 1: 21%, régimen general
- Línea 2: 21%, régimen criterio de caja
El desglose debe contener dos entradas distintas, ambas con tipo 21%, pero con claves de régimen diferentes.
Caso 2: Factura con líneas al 21% y al 10%
Se pueden informar más de una clave de régimen por cada tipo impositivo, siempre que existan líneas que lo justifiquen.
Ejemplo válido:
- Línea 1: 21%, régimen general
- Línea 2: 21%, régimen especial agencias
- Línea 3: 10%, régimen general
El desglose incluirá tres agrupaciones:
- 21% + régimen general
- 21% + régimen especial agencias
- 10% + régimen general
¿Cómo se debe aplicar una retención por IRPF a una factura entre profesionales?
En las facturas, a menudo se incluyen menciones, detracciones, adiciones o cantidades que no forman parte de la información fiscalmente obligatoria de una factura. A título de ejemplo, podemos mencionar: el recargo financiero (al igual que ocurre con los importes suplidos), la retención por garantía decenal, los suplidos o, en este caso, la retención de IRPF.
Todos estos importes, aunque se incluyen en la factura por su evidente importancia, no son importes “propios” de la factura, razón por la que no afectan a la base ni a la cuota de IVA, ni al “Importe Total” . Se trata de cantidades que alteran el “total a pagar” añadiendo o restando cantidades, pero no el “importe total factura”. Por ello cuando sea preciso incluirlos en la factura, esa parte NO integrará el registro de facturación.
A este respecto, a modo de consejo o recomendación, para facilitar la comprensión de este matiz al cliente que reciba la factura, se podrían incluir ambos importes en la factura: “Importe total factura” (que es el que aparece en el QR tributario) y “Total a pagar”, debidamente diferenciados.
