FAQ

Encuentre respuestas a 58 preguntas frecuentes sobre SIGN ES, organizadas por tema.

Facturas (37)

Códigos de corrección en SIGN ES: ¿Cuándo usar CORRECTION_1, CORRECTION_2, CORRECTION_3 y CORRECTION_4?

Cuando se emite una **factura rectificativa **(CORRECTING) a través de SIGN ES, es obligatorio indicar un código de corrección que identifica el motivo legal de la rectificación. Estos códigos se corresponden con los artículos del Art. 80 de la Ley del IVA (LIVA – Ley 37/1992) y se traducen internamente a las claves R1–R4 en el XML fiscal (Verifactu, TicketBAI o SII).

Claves de la factura rectificativa

Código SIGN ES	Clave	Motivo	Base legal
`CORRECTION_1`	R1	Errores de importe o IVA, devoluciones, descuentos, rappels, o modificaciones de precio tras la operación	Art. 80.1, 80.2 y 80.6 LIVA
`CORRECTION_2`	R2	El destinatario ha sido declarado en concurso de acreedores (quiebra)	Art. 80.3 LIVA
`CORRECTION_3`	R3	El crédito es total o parcialmente incobrable	Art. 80.4 LIVA
`CORRECTION_4`	R4	Cualquier otro motivo no cubierto por los anteriores (errores en datos no económicos: NIF, dirección, descripción, etc.)	Resto de supuestos

Nota: En el caso de facturas simplificadas (SIMPLIFIED), SIGN ES asigna automáticamente el tipo R5, independientemente del código de corrección indicado.

Cuándo usar cada código de corrección

CORRECTION_1 (R1) – Rectificaciones económicas o fiscales

Se utiliza cuando la rectificación afecta a importes, cuotas o a elementos fiscalmente relevantes de la operación. Es el caso más habitual.

Ejemplos típicos:

El tipo de IVA aplicado era incorrecto.
Se devuelven mercancías o envases.
Se aplican descuentos o rappels concedidos después de la operación.
Se modifica el precio acordado tras la transacción.
El importe era provisional en el momento de la emisión y después se conoce el definitivo.

CORRECTION_2 (R2) – Concurso de acreedores

Se utiliza exclusivamente cuando el destinatario de la factura ha sido declarado en concurso de acreedores y la rectificación se realiza por este motivo legal.

CORRECTION_3 (R3) – Créditos incobrables

Se utiliza cuando la deuda derivada de la factura es total o parcialmente incobrable y se cumplen los requisitos legales para modificar la base imponible.

CORRECTION_4 (R4) – Resto de supuestos

Se utiliza cuando la rectificación no encaja en los casos anteriores, por ejemplo, para corregir datos no monetarios u otros aspectos no contemplados en R1, R2 o R3.

Ejemplos típicos:

El NIF del destinatario era incorrecto.
La dirección estaba equivocada.

La descripción de la operación contenía errores.

¿Cómo se informa la “Calificación de la operación” (S1, S2, N1, N2) en SIGN ES para Verifactu?

En el XML de Verifactu existe, a nivel de detalle de desglose de cada línea, el campo CalificacionOperacion, que identifica la naturaleza fiscal de la operación.

Entre los valores más comunes se encuentran:

S1 – Operación sujeta y no exenta, sin inversión del sujeto pasivo

S2 – Operación sujeta y no exenta, con inversión del sujeto pasivo

N1 – Operación no sujeta

N2 – Operación no sujeta por reglas de localización

¿Debo enviar S1, S2, N1 o N2 en el API?

No. En el API de SIGN ES no existe un campo explícito para enviar directamente S1, S2, N1 o N2.

En su lugar, debes informar por cada línea la categoría fiscal correspondiente mediante:

type

cause, cuando aplique

A partir de esa información, SIGN ES genera internamente el valor correspondiente de **CalificacionOperacion** en el XML de Verifactu.

Mapeo habitual utilizado por SIGN ES

S1 – Operación sujeta y no exenta, sin inversión del sujeto pasivo

"system": {
  "category": {
    "type": "VAT"
  }
}

S2 – Operación sujeta y no exenta, con inversión del sujeto pasivo

"system": {
  "category": {
    "type": "INVERSE_VAT"
  }
}

N1 – Operación no sujeta

"system": {
  "category": {
    "type": "NO_VAT",
    "cause": "NON_TAXABLE_1"
  }
}

N2 – Operación no sujeta por reglas de localización

"system": {
  "category": {
    "type": "NO_VAT",
    "cause": "NON_TAXABLE_2"
  }
}

Importante: El valor final de CalificacionOperacion depende del tratamiento fiscal global de la línea, no solo de una equivalencia directa. En la integración debe informarse la categoría fiscal adecuada de cada línea, y SIGN ES generará internamente e****l valor correspondiente en el XML de Verifactu.

Series y numeración de facturas

La numeración de facturas debe ser consecutiva dentro de cada serie. El nombre de la serie es flexible (por ejemplo, A, 2026, POS1), pero dentro de una misma serie no debe haber saltos.

Si existen dos TPVs que no pueden mantener una numeración correlativa entre ellos, se recomienda utilizar series distintas para evitar conflictos. Por ejemplo, el TPV 1 puede emitir en la serie POS1 (POS1-1, POS1-2, …) y el TPV 2 en la serie POS2 (POS2-1, POS2-2, …). De esta forma, cada serie mantiene su numeración consecutiva de manera independiente.

Las facturas SIMPLIFIED y COMPLETE pueden emitirse en la misma serie o en series separadas. Ambas opciones son válidas, siempre que la numeración sea consecutiva dentro de la serie elegida.

Una factura CORRECTING se emite para rectificar una factura ya emitida. Este tipo de factura **debe emitirse utilizando una serie específica, **distinta de la empleada para las facturas ordinarias. Dentro de esta serie, la numeración debe ser correlativa. Por ejemplo, si la factura original es A-15 y aún no existen facturas rectificativas, la primera rectificativa podría emitirse como R-1.

Una factura REMEDY no crea una nueva factura, sino que representa una corrección técnica manteniendo la identidad de la factura original. Por este motivo, una REMEDY debe reutilizar exactamente los mismos valores de series y number que la factura original. Por ejemplo, si la factura original es A-20, la REMEDY también deberá ser A-20. Si estos valores no coinciden, la factura será rechazada en el momento de su creación.

Una factura ENRICHMENT se utiliza para completar una factura SIMPLIFIED añadiendo información del destinatario. Una factura de tipo ENRICHMENT se emite como una nueva factura vinculada a la simplificada y, por tanto, debe llevar un número distinto. Puede emitirse en la misma serie o en una serie diferente, siempre que la numeración se mantenga consecutiva. Por ejemplo, si la factura simplificada original es A-20, la enrichment podría emitirse como A-21 (o como E-1 si se usa una serie separada). Desde un punto de vista práctico, la factura ENRICHMENT “sustituye” a la factura simplificada como versión final y completa del documento, por lo que no es necesario preocuparse por una posible “duplicación” de la factura original.

¿Cómo gestionar las propinas?

En España, las propinas que los clientes dejan de forma voluntaria y que no son obligatorias generalmente no forman parte de la base imponible del IVA y no están sujetas a IVA, ya que no se consideran parte del precio del producto o servicio.

Dado que Verifactu y TicketBAI solo requieren el envío de los datos fiscalmente relevantes de la factura (bases, cuotas de IVA, recargo de equivalencia, etc.), estas propinas voluntarias no tienen que incluirse en el XML que se envía a la AEAT o a las Haciendas Forales del País Vasco, siempre que no formen parte del importe facturado.

Sin embargo, si añades un “cargo por servicio” obligatorio u otro concepto similar al total de la factura (es decir, no es una propina voluntaria), entonces sí forma parte de la base imponible, está sujeto a IVA y debe incluirse en la factura y, por tanto, también en el fichero de Verifactu/TicketBAI.

¿Cómo mapea SIGN ES los tipos de factura a los códigos F1, F2, F3 y R1–R5 de la AEAT?

De acuerdo con la definición oficial del campo “Tipo de Factura” de la AEAT (códigos F1, F2, F3 para facturas y R1–R5 para rectificativas), en SIGN ES hacemos el siguiente mapeo automático:

Tipos de factura

**Factura simplificada **(SIMPLIFIED) → F2 (Factura simplificada o factura completa sin identificación del destinatario, según RD 1619/2012).
Factura completa (COMPLETE) → F1 (Factura completa y facturas simplificadas “cualificadas” en las que se identifica al destinatario).
Factura de canje / enriquecida (ENRICHMENT) → F3 Se utiliza cuando se emite una factura en sustitución de facturas simplificadas ya emitidas y declaradas. Esta factura “convertirá” la factura simplificada en una factura completa con los destinatarios añadidos.

Facturas rectificativas

Para las facturas rectificativas completas (COMPLETE CORRECTING), también debe indicarse un código de rectificación predefinido. Mapeamos el campo code de la siguiente forma:

"code": "CORRECTION_1" → R1
"code": "CORRECTION_2" → R2
"code": "CORRECTION_3" → R3
"code": "CORRECTION_4" → R4

Cuando lo que se está rectificando es una **factura simplificada **(SIMPLIFIED CORRECTING), asignamos automáticamente el código R5, tal y como prevé la AEAT para rectificativas de facturas simplificadas.

¿Cómo indicar el recargo de equivalencia en SIGN ES?

La estructura para informar el recargo de equivalencia dependerá de si quien está en este régimen es tu cliente (emisor) o el destinatario de la factura.

Si es tu cliente quien está en régimen de recargo de equivalencia, debes usar el régimen "EQUIVALENCE_SURCHARGE" en system.type. Por ejemplo:

{
  "text": "Producto A",
  "quantity": "2.00",
  "unit_amount": "100.00",
  "full_amount": "193.60",
  "discount": "20.00",
  "system": {
    "type": "EQUIVALENCE_SURCHARGE",
    "category": {
      "type": "VAT",
      "rate": "21.00"
    }
  }
}

Si, en cambio, es el cliente final (destinatario de la factura) quien está en régimen de recargo de equivalencia, entonces no debes usar "EQUIVALENCE_SURCHARGE" en system.type, sino utilizar el campo additional_vat dentro de category.

{
  "text": "Producto A",
  "quantity": "2.00",
  "unit_amount": "100.000",
  "full_amount": "201.92",
  "discount": "20.00",
  "system": {
    "type": "REGULAR",
    "category": {
      "rate": "21.00",
      "type": "VAT",
      "additional_vat": {
        "rate": "5.20",
        "amount": "8.32"
      }
    }
  }
}

En este segundo ejemplo, los cálculos serían:

Base imponible del artículo: (unit_amount - discount) * quantity (100 - 20) * 2 = 160
Recargo 5,2 %: 160 * 0.052 = 8.32
IVA 21 %: 160 * 0.21 = 33.60
full_amount: 160 + 8.32 + 33.60 = 201.92

¿Puedo emitir facturas como tercero?

Según el artículo 5 del Real Decreto 1619/2012, las facturas deben identificar siempre al profesional o contribuyente responsable de la operación. No obstante, la preparación y emisión de facturas pueden delegarse en un tercero —por ejemplo, un contable o representante fiscal— si se cumplen determinados requisitos legales y técnicos. Debe existir un acuerdo previo por escrito entre ambas partes.

La API de SIGN ES permite la emisión de facturas por un tercero mediante una configuración opcional de third_party en el contribuyente. Esta funcionalidad solo está disponible para territorios Verifactu.

Para habilitar que un usuario de SIGN ES API emita facturas como tercero (en nombre de sus clientes), la información debe proporcionarse al crear el contribuyente del siguiente modo:

Taxpayer > issuer > legal_name, tax_number, address: corresponde al comerciante responsable de emitir la factura o de realizar la operación.
Taxpayer > third_party > legal_name, tax_number, address: corresponde al tercero que emite facturas en nombre del contribuyente.

Cuando se informa esta configuración, todas las facturas** se tratarán como** emitidas por ese tercero.

Al emitir facturas como tercero, ten en cuenta que debe firmarse un acuerdo de colaboración social específico entre fiskaly y dicho tercero, quien además debe estar registrado como colaborador social de la AEAT. Para más información, contacta con equipo@fiskaly.com

¿Puedo emitir una factura sin identificar al destinatario?

Sí. Según la normativa española de facturación, puedes emitir una factura sin identificar al destinatario cuando la operación no requiere legalmente el NIF del destinatario.

Al crear una factura mediante la API de SIGN ES, puedes emitirla sin identificación del destinatario en los casos previstos en el **artículo 6.1.d) del Reglamento de Facturación **(RD 1619/2012).

Esto se hace estableciendo el campo exception_unidentified en true al crear una factura de tipo SIMPLIFIED.

Esta opción solo está disponible en territorios Verifactu.

¿Cómo puedo generar una factura proforma?

Puedes emitir una factura proforma (borrador) a través de la API de SIGN ES creando un documento no fiscal marcado como borrador. Esto aplica tanto a facturas simplificadas (SIMPLIFIED) como completas (COMPLETE).

Este tipo de documento no se transmite a las autoridades tributarias (Verifactu o TicketBAI) y tiene fines informativos únicamente —por ejemplo, para ofrecer un presupuesto o estimación antes de cerrar la venta.

Para crear una factura proforma con la API de SIGN ES:

Envía una petición al endpoint Crear factura.
Indica el tipo de factura DRAFT.
Proporciona la misma estructura de payload que para una factura simplificada (SIMPLIFIED) o completa (COMPLETE).

Por motivos de trazabilidad, recomendamos vincular las facturas (simplificadas/completas) con la proforma previa (si existe). Esto puede hacerse mediante el campo draft_id, donde se indica el UUID de la proforma ya generada en la API de SIGN ES.

TicketBAI: cómo declarar suplidos

Los suplidos se declaran como operaciones no sujetas a IVA. En la API se informan con system.type = NO_VAT y cause = NON_TAXABLE_4.

Caso típico: recarga de tarjetas de transporte (p. ej., MUGI)

Ejemplo:

{
               "text": "Recarga tarjeta MUGI",
               "quantity": "1",
               "unit_amount": "20.00",
               "full_amount": "20.00",
               "system": {
                   "type": "REGULAR",
                   "category": {
                       "type": "NO_VAT",
                       "cause": "NON_TAXABLE_4"
                   }
               }
           }

Diferencias en el esquema de destinatarios: nacionales vs. internacionales

En las facturas de tipo COMPLETE y ENRICHMENT, la estructura del campo recipients cambia según si el destinatario es nacional (español) o internacional (no español).

Para destinatarios españoles, se utiliza la estructura del objeto NationalIdentification

Para destinatarios no españoles, se utiliza la estructura del objeto InternationalIdentification

Además, cuando el destinatario de una factura COMPLETE no es español, cada ítem de la factura debe incluir el campo concept.

Nota: Si el cliente extranjero dispone de un NIF o NIE español válido, aunque su domicilio fiscal se encuentre en el extranjero, debe utilizarse el esquema de NationalIdentification.

El endpoint Validar el NIF permite verificar los números fiscales de destinatarios españoles y de destinatarios en otros países de la UE antes de emitir facturas: ¿Cómo funciona el endpoint de validar el NIF?

Flujos permitidos para cada tipo de factura

Este artículo describe los flujos permitidos en SIGN ES por tipo de factura; consulta a continuación los diagramas para las facturas simplificadas (SIMPLIFIED) y completas (COMPLETE):

Cancelación: solo se permite en circunstancias excepcionales; por ejemplo, cuando la operación no se llevó a cabo y el cliente final no recibió la factura en ningún formato (papel o electrónico).

Una vez enviados los datos de la factura, recomendamos emitir una factura CORRECTING (rectificativa) en lugar de cancelar.

La factura se cancela utilizando el endpoint Actualizar factura.

**REMEDY: **cuando una factura no pasa las validaciones de la AEAT (estado REQUIRES_CORRECTION o REQUIRES_INSPECTION) y no se requiere una corrección legal conforme al Reglamento de Facturación, se debe emitir una factura REMEDY.

Una factura puede remediarse varias veces, hasta que sea aceptada por la AEAT.

CORRECTING: si una factura no pasa las validaciones de la AEAT (estado REQUIRES_CORRECTION o REQUIRES_INSPECTION) y se requiere una corrección legal conforme al Reglamento de Facturación, se debe emitir una factura CORRECTING (rectificativa).

**ENRICHMENT: **añadir un destinatario a una factura simplificada ( SIMPLIFIED) existente (factura de canje).

Para más información, incluimos un vídeo: Los tipos de factura en SIGN ES

¿Cuándo debe usarse el campo annotations?

El campo annotations varía según el contexto:

El tipo INDIVIDUAL aplica en Vizcaya. Además, es obligatorio incluir el campo activity_code.

Para más información: Compliance TBAI > Envío de ficheros XML

El tipo INCIDENT se utiliza en Verifactu en modo OFFLINE. También es obligatorio incluir el campo reason.

Para más información: Compliance Verifactu > Pérdida de conexión

¿Cómo calcular el full_amount de un ítem?

El campo full_amount de cada línea (ítem) debe calcularse de la siguiente manera:

full_amount = (unit_amount * quantity) + IVA

Ejemplo:

full_amount = (16.52 * 3) + 10% IVA = 54.52

{
               "text": "Sombrero",
               "quantity": "3",
               "unit_amount": "16.52",
               "full_amount": "54.52",
               "system": {
                   "type": "REGULAR",
                   "category": {
                       "type": "VAT",
                       "rate": "10.0"
                   }
               }
           }

**¿Cómo se reflejan los descuentos por línea (ítem) en el cálculo del full_amount? **

Si se aplican descuentos a nivel de línea (ítem), el cálculo se realiza de la siguiente forma:

full_amount = ((unit_amount - discount) * quantity) + IVA

El descuento se aplica por unidad, excluyendo el IVA.

Ejemplo:

full_amount = ((16.52 - 4.00) * 3) + 21% IVA = 45.45

Para más detalles, consulta el artículo: ¿Cómo aplicar un descuento a nivel de ítem y de forma global?

{
               "text": "Sombrero",
               "quantity": "3",
               "unit_amount": "16.52",
               "full_amount": "45.45",
               "discount":"4.00",
               "system": {
                   "type": "REGULAR",
                   "category": {
                       "type": "VAT"
                   }
               }
           }

¿Cómo aplicar un descuento a nivel de ítem y de forma global?

Un descuento puede aplicarse a nivel de ítem o de forma global. A continuación, se muestra un ejemplo para cada caso:

Descuento por ítem

Los descuentos por línea se aplican directamente a cada ítem. Cuando existe un descuento, el campo full_amount se calcula de la siguiente manera: full_amount = ((unit_amount - discount) * quantity) + VAT El descuento se aplica por unidad, excluyendo el IVA.

{
   "content": {
       "type": "SIMPLIFIED",
       "number": "E-3",
       "text": "Factura de venta de prendas de vestir",
       "full_amount": "50.45",
       "items": [
           {
               "text": "Sombrero",
               "quantity": "3",
               "unit_amount": "16.52",
               "full_amount": "45.45",
               "discount":"4.00",
               "system": {
                   "type": "REGULAR",
                   "category": {
                       "type": "VAT"
                   }
               }
           },
           {
               "text": "Bufanda",
               "quantity": "1",
               "unit_amount": "4.13",
               "full_amount": "5",
               "system": {
                   "type": "REGULAR",
                   "category": {
                       "type": "VAT"
                   }
               }
           }
       ]
   },
   "metadata": {
       "metadata1": "metadata1",
       "metadata2": "metadata2"
   }
}

Descuento global

Los descuentos globales deben incluirse como una línea adicional en la factura, con un importe negativo.

{
    "content": {
        "type": "SIMPLIFIED",
        "number": "E-1",
        "text": "Factura de venta de prendas de vestir",
        "full_amount": "980.10",
        "items": [
            {
                "text": "Zapatos",
                "quantity": "1",
                "unit_amount": "300.00",
                "discount": "90.00",
                "full_amount": "254.10",
                "system": {
                    "type": "REGULAR",
                    "category": {
                        "type": "VAT"
                    }
                }
            },
            {
                "text": "Chaqueta",
                "quantity": "1",
                "unit_amount": "800.0",
                "full_amount": "968.0",
                "system": {
                    "type": "REGULAR",
                    "category": {
                        "type": "VAT"
                    }
                }
            },
            {
                "text": "Descuento",
                "quantity": "1",
                "unit_amount": "-200.0",
                "full_amount": "-242.0",
                "system": {
                    "type": "REGULAR",
                    "category": {
                        "type": "VAT"
                    }
                }
            }
        ]
    },
    "metadata": {
        "metadata1": "metadata1",
        "metadata2": "metadata2"
    }
}

¿Cómo debe representarse un descuento global cuando se aplican varios tipos de IVA?

Debe crearse una línea de descuento global independiente para cada tipo de IVA. Si no se indica un tipo de IVA, se aplicará por defecto un tipo del 21%.

{
   "text": "Descuento",
   "quantity": "1",
   "unit_amount": "-200.0",
   "full_amount": "-242.0",
   "system": {
       "type": "REGULAR",
       "category": {
           "type": "VAT"
       }
   }
},
{
   "text": "Descuento",
   "quantity": "1",
   "unit_amount": "-100.0",
   "full_amount": "-100.0",
   "system": {
       "type": "REGULAR",
       "category": {
           "type": "NO_VAT",
           "cause": "TAXABLE_EXEMPT_1"
       }
   }
}

¿Cómo emitir una factura rappel?

Una factura de rappel se emite cuando, tras un periodo determinado, el cliente cumple los requisitos para un descuento por volumen. Al final de ese periodo, se emite una nueva factura que aplica el descuento sobre el total de las operaciones previamente facturadas, ajustando así la base imponible y el IVA. Las facturas de rappel son un tipo de factura rectificativa conforme al artículo 15.6 del Reglamento de Facturación.

¿Cómo emitirla con SIGN ES?

Con la API de SIGN ES, emite una factura rectificativa (subtipo COMPLETE) y utiliza el campo summarized_invoices para listar los UUID de las facturas SIMPLIFIED o COMPLETE previamente emitidas que serán corregidas. Esto no modifica los XML originales; siempre se genera un nuevo XML.

Límites por territorio (¿cuántas facturas puedo referenciar?)

TicketBAI: hasta 100 facturas referenciadas

Verifactu: hasta 1.000 facturas referenciadas

¿Cómo emitir una factura recapitulativa?

Una factura recapitulativa se emite al mismo destinatario para recapitular varias operaciones realizadas dentro de un mismo mes. Al final del mes, esta factura recapitulativa sustituye (a efectos de IVA) a las facturas originales. Este tipo de factura está regulado por el artículo 13 del Reglamento de Facturación.

¿Cómo emitirla con SIGN ES?

Con la API de SIGN ES, puedes crear una factura completa (COMPLETE) recapitulativa que sustituye varias facturas simplificadas (SIMPLIFIED). Al crear la nueva factura completa, utiliza el campo summarized_invoices para listar los UUID de las facturas simplificadas previamente emitidas que se informarán a las autoridades como “sustituidas”. Esto no modifica los XML originales; siempre se genera un nuevo XML.

Límites por territorio (¿cuántas facturas puedo referenciar?)

TicketBAI: hasta 100 facturas referenciadas

Verifactu: hasta 1.000 facturas referenciadas

Verifactu: ¿Se incluyen los suplidos y las retenciones en el total de la factura?

No. Verifactu solo transmite datos relevantes a efectos de IVA, por lo que los suplidos y las retenciones del IRPF no se envían a la AEAT.

En Verifactu, el campo vat_withholding está inactivo.

Al escanear el código QR, el total mostrado puede diferir del importe efectivamente pagado:

Los suplidos incrementan el importe pagado, pero no se incluyen en el total de Verifactu.
Las retenciones de IRPF reducen el importe pagado, pero no se incluyen en el total de Verifactu.

Por ello, se recomienda incluir de forma clara en la factura —ya sea impresa o electrónica— una leyenda explicativa como la siguiente:

“El importe total remitido a la AEAT (visible al escanear el QR) no incluye suplidos ni retenciones. El importe total a pagar se indica en esta factura.”

La Agencia Tributaria también muestra un mensaje aclaratorio al escanear el código QR para evitar confusiones.

¿Qué hacer si el número de identificación fiscal (NIF) del destinatario no está registrado?

SIGN ES incluye el campo registered para la identificación de los destinatarios de facturas, que indica si el NIF está oficialmente registrado (“censado”) en la Agencia Tributaria Española (AEAT).

En los territorios de Verifactu, es posible emitir una factura con el tipo “07 - No censado” cuando se sabe que el NIF es correcto, pero aún no ha sido registrado o procesado por la AEAT.

En este caso, el envío de una factura con registered = false en el destinatario nacional resultará en un estado de aceptado con errores en la validación de la AEAT, indicando que el NIF no ha sido identificado en su sistema.

**¿Qué hacer después? **

Una vez completado el proceso de registro (aproximadamente 48 horas), la factura debe reenviarse como una factura de tipo REMEDY, esta vez indicando registered = true.

Si el NIF se registró correctamente, la REMEDY dará lugar a una transmisión exitosa, sin errores.
Si hay un problema con el NIF (por ejemplo, si se proporcionó un número incorrecto), el problema no puede solucionarse mediante una REMEDY. En este caso, será necesario emitir una factura rectificativa (tipo CORRECTING) para resolver la incidencia.

¿Cómo funciona la facturación por el destinatario?

La facturación por el destinatario está permitida en España a través de la API de SIGN ES, pero solo para transacciones que estén dentro del sistema VERI*FACTU.

Esta funcionalidad no está disponible en las regiones cubiertas por el sistema TicketBAI, que incluye las provincias vascas de Álava, Bizkaia y Gipuzkoa.

Al crear una factura de tipo COMPLETE, o al enviar cualquier corrección relacionada, debes incluir el bloque issued_by.

Este bloque consta de dos elementos:

type (obligatorio): Debe establecerse como RECIPIENT. Al seleccionarlo, se genera el XML de Verifactu conforme a los requisitos legales y técnicos para facturas emitidas por el destinatario.

invoicing_agreement(opcional): Si existe un acuerdo formal entre el proveedor y el destinatario, puedes incluir en este campo el número de registro del acuerdo.

Importante: En este caso, el recipient indicado en la factura es el contribuyente legalmente obligado a emitirla. Esto significa que el cliente es responsable de la factura, no el proveedor.

Cómo usar el campo tax_base para regímenes especiales de IVA

En algunos regímenes especiales de IVA —como el de Antigüedades (REBU)— el IVA se aplica únicamente sobre el margen de beneficio, y no sobre el precio total de venta. Cuando esto ocurre, la fórmula habitual de unit_amount × quantity no coincide con la base imponible, por lo que es necesario especificar dicha base explícitamente mediante el campo tax_base.

Ejemplo práctico:


Precio de compra	400€	Lo que has pagado por el artículo
Precio de venta	600€	Lo que paga el cliente
Margen de beneficio	200€	600 - 400 = 200
Tipo de IVA	21%	Tipo de IVA aplicable
IVA devengado	42€	21% of 200 = 42
`tax_base` a declarar	200€	Margen sujeto a IVA

¿Cómo se representa esto en la API de SIGN ES?

full_amount = (unit_amount × quantity) + VAT Aquí, el IVA es el 21 % del margen (€200), y no del precio total de venta.

Ejemplo de payload:

"content": {
        "type": "SIMPLIFIED",
        "number": "12",
        "series": "E",
        "text": "example invoice",
        "full_amount": "642.00",
        "items": [
            {
                "text": "Mueble",
                "quantity": "1",
                "unit_amount": "600",
                "full_amount": "642.00",
                "system": {
                    "type": "ANTIQUES",
                    "tax_base": "200.00",
                    "category": {
                        "type": "VAT"
                    }
                }
            }
        ]
    }

¿En qué casos debe usarse el campo “coupon”?

El campo booleano "coupon" es opcional y solo debe usarse en facturas rectificativas de los siguientes tipos:

Facturas COMPLETAS RECTIFICATIVAS con "code": "CORRECTION_1"
Facturas SIMPLIFICADAS RECTIFICATIVAS

Este campo se establece como true cuando el comerciante aplica un descuento al cliente, pero el descuento no es asumido por el propio comerciante, sino que posteriormente es reembolsado por el fabricante.

Por ejemplo: un cliente devuelve un producto defectuoso. El comerciante aplica un descuento de 121 € (100 + 21 % de IVA), y luego recibe un reembolso de 100 € netos por parte del fabricante. En este caso, la factura rectificativa incluiría "coupon": "true".

Esto indica que el descuento fue financiado por un tercero (el fabricante), y no se trata de un descuento comercial otorgado directamente por el vendedor.

¿Cómo generar el código QR offline para Verifactu?

Para una explicación completa sobre cómo generar el código QR en escenarios offline, por favor consulta nuestra guía. A continuación, encontrarás algunos ejemplos que te ayudarán a comparar tu implementación con lo que genera fiskaly al enviar los datos.

EJEMPLO 1:

url = https://prewww2.aeat.es/wlpl/TIKE-CONT/ValidarQR tax_number = B43752210 number = E-12345 series = issued_at = 2025/04/23 14:55 full_amount = 123.45

resultado = https://prewww2.aeat.es/wlpl/TIKE-CONT/ValidarQR?nif=B43752210&numserie=E-12345&fecha=23-04-2025&importe=123.45

EJEMPLO 2:

url = https://www2.agenciatributaria.gob.es/wlpl/TIKE-CONT/ValidarQR tax_number = B88752210 number = A-321 series = 1/25 issued_at = 2025/01/05 08:35 full_amount = 567

resultado = https://www2.agenciatributaria.gob.es/wlpl/TIKE-CONT/ValidarQR?nif=B88752210&numserie=1%2F25A-321 &fecha=05-01-2025&importe=567.00

¿Cuándo usar una factura de tipo REMEDY o una factura rectificativa (CORRECTING)?

Las facturas con el estado REQUIRES_INSPECTION o REQUIRES_CORRECTION pueden dar lugar a una factura de tipo REMEDYo CORRECTING, dependiendo de la naturaleza del problema.

La factura de tipo REMEDY se utiliza para corregir datos de la factura que no requieren una corrección legal. Normalmente, se trata de errores que no afectan al cliente final – por ejemplo, un mapeo incorrecto de campos, diferencias en redondeos u otros problemas derivados de errores de integración. En estos casos, la factura entregada al cliente ya es correcta, y la corrección se realiza únicamente entre el contribuyente y la Agencia Tributaria.

Por otro lado, las facturas de tipo CORRECTING (facturas rectificativas) deben emitirse en situaciones como devoluciones de artículos, datos incorrectos del destinatario o cualquier otro error que sí afecta al cliente, ya que la factura que recibió contiene información incorrecta.

Para más información, incluimos un vídeo: Las facturas rectificativas y cómo cancelar facturas

¿Qué información de la respuesta de la API debe imprimirse en la factura?

En este artículo, describimos los elementos clave que deben incluirse en las facturas emitidas para cumplir con las normativas de Verifactu y TicketBAI.

Verifactu

Las facturas emitidas bajo Verifactu deben incluir:

Un código QR que contenga la URL de validación. Esto debe ir acompañado de la etiqueta “QR tributario”, indicando claramente su finalidad como código QR fiscal.
Un texto conforme que indique que la factura fue emitida en Modo Verifactu. Se debe utilizar uno de los siguientes textos: “VERIFACTU”*, o “Factura verificable en la sede electrónica de la AEAT”

Las directrices adicionales sobre el texto conforme, la URL de validación y el código QR —incluyendo sus dimensiones requeridas y su colocación dentro de la factura— se detallan en la sección Cumplimiento de Facturación Verifactu de la guía SIGN ES.

TicketBAI

Las facturas emitidas bajo TicketBAI deben incluir:

Un código QR que contenga la URL de validación.
Un código TBAI, que identifica de forma única la factura para el seguimiento del cumplimiento normativo. Este código se muestra en el campo tbai de la respuesta de la API al crear la factura.

Más detalles sobre la URL de validación, el código QR y el código identificativo —incluyendo sus dimensiones requeridas y la ubicación dentro de la factura— pueden encontrarse en la sección Conformidad de facturas TicketBAI de la guía SIGN ES.

Escenarios sin conexión

Si la transmisión de la factura falla debido a problemas de conectividad y no es posible imprimir el código QR o el código identificativo, se recomienda a las empresas incluir un mensaje como:

“Código QR no generado debido a problemas de conectividad.”

Este mensaje permite al cliente final conocer la razón por la cual faltan los elementos fiscales y garantiza la transparencia del proceso.

Al cumplir con estos requisitos, las empresas pueden asegurarse de que sus facturas cumplan con las normativas legales y fiscales correspondientes.

¿Cómo identificar problemas en facturas con estado REQUIRES_INSPECTION o REQUIRES_CORRECTION?

El primer paso para identificar los problemas con una factura en estado REQUIRES_INSPECTION o REQUIRES_CORRECTION es acceder al endpoint retrieveInvoice.

Este endpoint te permite recuperar la información detallada de la factura, incluidas las validaciones que se han aplicado durante el proceso de envío.

Estas validaciones proporcionarán detalles específicos sobre qué aspectos de la factura han provocado el error.

Algunos errores comunes pueden ser: números de identificación fiscal (NIF) inválidos, cálculos incorrectos en las líneas de factura o errores de redondeo en los importes indicados.

Para más información, incluimos un vídeo: ¿Cómo verificar el estado de la factura en SIGN ES?

¿Qué debo hacer si el estado final de registro de la factura sigue en PENDING?

Si el estado de registro permanece en PENDING después de obtener la factura mediante el endpoint retrieveInvoice, significa que se ha perdido la conexión con el servidor de la Agencia Tributaria.

No necesitas hacer nada. SIGN ES realiza una verificación de disponibilidad del servicio TicketBAI, y la transmisión de los archivos TicketBAI se reanudará automáticamente una vez que la conexión al servicio sea restablecida.

¿Cómo puedo verificar el estado final de registro de la factura?

Cuando utilices el endpoint createInvoice, el estado de registro en la respuesta siempre será PENDING.

Para confirmar si la factura fue registrada con éxito, es necesario obtenerla nuevamente a través del endpoint retrieveInvoice.

Idealmente, el estado de registro será REGISTERED, lo que indicaría que se ha enviado y registrado correctamente en la Agencia Tributaria sin errores.

Cuánto tiempo esperar antes de recuperar la factura

Para Verifactu, recomendamos esperar aproximadamente 70 segundos antes de llamar al endpoint retrieveInvoice. Para TicketBAI, suele ser suficiente un retraso de 1–2 segundos.

Para más información, incluimos un vídeo: ¿Cómo verificar el estado de la factura en SIGN ES?

Factura rectificativa - ¿Cuál es la diferencia entre los métodos por SUSTITUCIÓN y por DIFERENCIAS?

Con el método de DIFFERENCES, los importes pueden ser positivos o negativos: negativos para devoluciones y positivos cuando se añaden conceptos a la misma factura. En este caso, la factura rectificativa resta o suma al importe de la factura original, por lo que ambas —la original y la rectificativa— siguen siendo válidas. Con el método de SUBSTITUTION, la factura rectificativa sustituye a la original y la Agencia Tributaria considera válida únicamente la factura rectificativa.

Ejemplo: la factura final debe incluir 2 coca colas y 2 pastas

INV 2024-001 CORR 2024-001 (método por sustitución)

1 coca cola 2 coca cola 1 pasta 2 pasta 20€ base imponible 40€ base imponible 4,2€ IVA (21%) 8,4€ IVA (21%) 24,2€ Total 48,2€ Total

INV 2024-002 CORR 2024-002 (método por diferencias)

3 coca cola -1 coca cola 3 pasta -1 pasta 60€ base imponible 20€ base imponible 12,6€ IVA (21%) -4,2€ IVA (21%) 72,6€ Total -24,2€ Total

Ambos métodos son válidos y puedes encontrar ejemplos de cada uno en nuestra colección de Postman.

Ejemplo: Reembolso total Factura original

"full_amount": "24.20",
"items": [
            {
                "text": "T-shirt",
                "quantity": "1",
                "unit_amount": "20",
                "full_amount": "24.20",
                "system": {
                    "type": "REGULAR",
                    "category": {
                        "type": "VAT"
                    }
                }
            }
        ]

Factura rectificativa (método SUBSTITUTION)

"full_amount": "0",
"items": [
            {
                "text": "T-shirt",
                "quantity": "0",
                "unit_amount": "20",
                "full_amount": "0",
                "system": {
                    "type": "REGULAR",
                    "category": {
                        "type": "VAT"
                    }
                }
            }
        ]

Factura rectificativa (método DIFFERENCES)

"full_amount": "-24.20"
"items": [
            {
                "text": "T-shirt",
                "quantity": "-1",
                "unit_amount": "20",
                "full_amount": "-24.20",
                "system": {
                    "type": "REGULAR",
                    "category": {
                        "type": "VAT"
                    }
                }
            }
        ]

¿Cómo corregir una factura que ya ha sido corregida?

Cuando se necesita corregir una factura que ya ha pasado por una rectificación previa, estos son los pasos a seguir:

Creación de la factura inicial (S1): Primero, se genera una factura, a la que llamaremos S1. Durante la revisión, se detecta un error en esta factura que requiere la emisión de una factura rectificativa de acuerdo al reglamento de facturación.

Primera factura rectificativa (R1): Para corregir el error, se emite una factura rectificativa, denominada R1. En el campo id de R1, debe incluirse el identificador de la factura original S1.

Si más adelante se detecta otro error en R1, que nuevamente requiere la emisión de una factura rectificativa, el siguiente paso es emitir una nueva rectificación.

Segunda factura rectificativa (R2): En este caso, se emite otra factura rectificativa, llamada R2. En el campo id de R2, debe añadirse el identificador de la primera factura rectificativa R1.

Este proceso asegura que cada corrección esté vinculada a la factura anterior.

Para más información, incluimos un vídeo: Las facturas rectificativas y cómo cancelar facturas

¿Cómo calcular el Importe Ingreso IRPF de una factura? (Bizkaia - Personas físicas)

Para personas físicas en Bizkaia, el envío del subcapítulo 1.1 del LROE (Modelo 140) “Ingresos con facturas emitidas con software garante” incluye el campo adicional y opcional de income_tax_amount (ImporteIngresoIRPF)

Este campo solo debe completarse cuando la factura emitida tiene retención de IRPF, siendo la base imponible del IVA diferente del ingreso del IRPF.

¿Como cálcularlo?

Para calcular la retención de IRPF, es necesario saber el porcentaje aplicable. El cálculo implica multiplicar este porcentaje por la base imponible y dividir entre 100, restando luego el resultado a la base imponible.

Por ejemplo, en una factura de 1.000 € (antes de impuestos), se añadiría un 21% de IVA (210 €) y se restaría una retención del 15% de IRPF (150 €), resultando en un total a cobrar de 1.060 €.

En este caso, la factura registrada por TicketBAI indicará en SIGN ES:

unit_amount: 1.000€
full_amount: 1.210€
income_tax_amount: 1000€ (sin IVA o retención)
vat_withholding: 150€

Para saber cómo hay que reflejar el income_tax_amount en las facturas rectificativas, puedes referirte a la pregunta 228 del listado de FAQs de Bizkaia.

¿Cómo proceder con las facturas con estado REQUIRES_INSPECTION en Vizcaya?

Cuando una factura expedida mediante el sistema TicketBAI es rechazada en el subcapítulo 1.1, SIGN ES mostrará el estado REQUIRES_INSPECTION. En este caso, los archivos deben ser reenviados a la Hacienda Foral de Vizcaya, siempre que no sea necesario emitir una factura rectificativa acorde al reglamento de facturación. Según el caso, esto se realiza a través del subcapítulo 1.1, dedicado a facturas emitidas con software garante, o el subcapítulo 1.2, dedicado a facturas emitidas sin software garante.

SIGN ES habilita el reenvío de facturas en el estado de registro REGISTERED, REQUIRES_CORRECTION y REQUIRES_INSPECTION a través de facturas de tipo REMEDY (subsanación) mediante los subcapitulos 1.1. y 1.2. El reenvío de facturas en los estados de registro PENDING y STORED no está permitido. Estas facturas se encuentran pendientes de envío por parte de SIGN ES o almacenadas debido a que no requieren transmisión a la autoridad tributaria.

El reenvío a través del subcapítulo 1.1 es posible si:

el error se debe a datos incorrectos introducidos en los campos del bloque annotations
el certificado del dispositivo no fue registrado o fue registrado incorrectamente por el contribuyente al momento de enviar la factura

¿Cuándo se debe volver a enviar una factura a través del subcapítulo 1.2?

el subcapítulo 1.1 fue rechazado, y no es posible re-enviar a través del 1.1
las facturas se emitieron en un escenario sin conexión
el dispositivo emisor está averiado y no se puede recuperar la información

¿Cómo se cargan las facturas en la plataforma de BATUZ?

Para acceder la plataforma debes visitar al siguiente enlace: https://www.batuz.eus/es/ inicio

Elegir el modelo correspondiente 140 o 240:

Después de iniciar sesión, selecciona ‘Facturas emitidas’ y a continuación, añade una nueva factura a emitir sin software garante (subcapítulo 1.2) y carga la información de la factura corregida.

¿Los albaranes deben expedirse a través del sistema TicketBAI/Verifactu?

No.

Aunque los albaranes son documentos comerciales que actúan como comprobantes de la entrega de un bien o servicio, no eximen de la obligación de emitir factura. Será la factura de la operación y no el albarán la que se deberá generar y enviar cumpliendo con los requisitos que establece TicketBAI.

¿Cómo gestionar las notas de crédito?

Las notas de crédito deben tratarse como facturas rectificativas (tipo CORRECTING). Éstas deben tener su propio sistema de referencia (serie) distinto del sistema de facturación normal. Al crear una factura rectificativa, es necesario hacer referencia a la factura original a la que está referida.

¿Cuál es el proceso de reembolso?

El proceso de reembolso se gestiona a través de la factura rectificativa en SIGN ES, utilizando el método de corrección SUSTITUCIÓN (SUBSTITUTION) o DIFERENCIAS (DIFFERENCES). Por defecto, SIGN ES utiliza el método de SUBSTITUCIÓN para las correcciones.

En el contexto de transacciones minoristas, el procedimiento típico implica la emisión de una factura rectificativa para asegurar que la transacción financiera se ajuste de manera precisa.

En todas las facturas rectificativas se debe indicar claramente la causa de la rectificación. Es esencial utilizar un código (code) predefinido, en función de la normativa española (Ley del IVA). Para facturas rectificativas simplificadas, SIGN ES asigna por defecto el código de corrección.

Para más información, incluimos un vídeo: Las facturas rectificativas y cómo cancelar facturas

¿Qué debo hacer si la transacción no se ha llevado a cabo?

Para una transacción que ya estaba registrada en SIGN ES pero que no se llevó a cabo y la factura no se entregó al cliente, se debe aplicar una cancelación a través de la funcionalidad updateInvoice, acorde a lo estipulado por las obligaciones de facturación en España (Real Decreto 1619/2012, de 30 de noviembre)

Al realizar una cancelación, el estado de una factura se modifica y se inicia una nueva sincronización con la autoridad tributaria para anular la factura ya registrada. Una vez anulada una factura, no se puede volver a utilizar el mismo número y serie.

¿Cómo corregir una factura simplificada con una factura completa?

Una factura rectificativa (CORRECTNG) tiene la estructura de una factura simplificada (SIMPLIFIED) o completa (COMPLETE), dependiendo de la factura rectificativa que deseas emitir. Cuando la factura rectificativa es completa, entonces contiene la estructura de la factura simplificada más la información del destinatario, y se requiere información de corrección adicional.

Sigue los siguientes pasos para rectificar una factura simplificada con una completa:

Para corregir una factura SIMPLIFIED en una COMPLETE hay que indicar el tipo CORRECTING. A continuación, tendrás que hacer referencia a la factura SIMPLIFIEDya creada indicando su id. Los datos de la factura rectificativa serán de tipo COMPLETE, en cuyo caso deberás añadir la información del destinatario (recipient) y el código (code) de corrección.

General (10)

¿Dónde se pueden encontrar ejemplos de los cuerpos de solicitud?

Los ejemplos de cuerpos de solicitud están disponibles en la colección de Postman, que incluye payloads de ejemplo para todos los tipos de factura soportados.

Los ejemplos para emitir facturas simplificadas (tickets) se encuentran en regular path → issuing invoices.
Los ejemplos de facturas rectificativas se pueden encontrar en correcting invoices.
Los ejemplos de facturas completas están disponibles en la sección correcting invoices.
Los ejemplos para los flujos de enrichment y remedy se encuentran en additional invoicing use cases.

Estos ejemplos están pensados como guía y, por lo tanto, no cubren todos los posibles escenarios de negocio o casos particulares.

Para una visión completa de todos los campos disponibles (obligatorios y opcionales), incluidas sus descripciones, se debe consultar la documentación de la API. Al desplegar las flechas en la documentación, se puede visualizar la estructura completa del cuerpo de la solicitud.

Verifactu vs. TicketBAI: diferencias clave en la implementación

En SIGN ES, el flujo de integración es esencialmente el mismo tanto para Verifactu como para TicketBAI.

Las diferencias provienen de normas específicas por territorio relacionadas con: (1) cómo gestionar los escenarios offline/pérdida de conexión, (2) la ubicación del QR y los textos obligatorios en la factura, y (3) el certificado utilizado para la firma.

Escenarios offline / pérdida de conexión: Verifactu: https://developer.fiskaly.com/e s /s ign-es/co n n e c tion loss _ve r ifa c tu TicketBAI: https://developer.fiskaly.com/e s /s ign-es/connectionloss

Posicionamiento del QR y textos obligatorios: Verifactu: https://developer.fiskaly.com/e s /s ign-es/invoicecompliance_verifactu TicketBAI: https://developer.fiskaly.com/e s /s ign-es/invoicecompliance

Firmante / certificado: TicketBAI requiere un certificado de dispositivo: https://developer.fiskaly.com/e s /s ign-es/device_certificate Verifactu utiliza el certificado electrónico de fiskaly: https://developer.fiskaly.com/e s /s ign-es/electronic_certificate

¿Cómo funciona el endpoint de Validar el NIF?

El endpoint de Validar el NIF en SIGN ES permite a los usuarios verificar un NIF frente a la base de datos de la AEAT o un número de IVA frente al servicio VIES.

Recomendamos utilizar este endpoint para:

Confirmar que el destinatario de una factura es correcto, ayudando a prevenir errores en la emisión y transmisión de la factura a la Agencia Tributaria.
Validar los datos antes de crear un Contribuyente, asegurando que los detalles del emisor sean correctos antes de generar recursos relacionados.

Validación de NIF (Servicio AEAT)

El endpoint de Validar el NIF solo funciona en Producción (LIVE), ya que la AEAT no ofrece un entorno de pruebas.
Al llamar a este endpoint en TEST, la respuesta será siempre: INVALID
Para las pruebas de integración, se pueden usar números fiscales predefinidos en TEST. Cada número simula un resultado distinto:

** T00000001** → INVALID_SIMILAR

** T00000002** → VALID

** T00000003** → VALID_REMOVED

** T00000004** → VALID_REVOKED

Validación de Números de IVA (Servicio VIES)

El endpoint de validación de números de IVA (para cualquier país de la UE distinto de España) funciona tanto en TEST como en Producción (LIVE).

¿Qué regímenes fiscales están contemplados?

En España, los contribuyentes pueden estar registrados en uno o más regímenes fiscales, dependiendo de las actividades que realicen.

La API de SIGN ES es compatible con los principales regímenes fiscales españoles requeridos para la facturación conforme a las normativas de TicketBAI y Verifactu. Al crear una factura, se debe especificar el régimen fiscal dentro del objeto system de cada ítem de la factura en el cuerpo de la solicitud.

Consideraciones

La abstracción del system en SIGN ES tiene en cuenta los siguientes aspectos:

Cada normativa (TicketBAI y Verifactu) tiene su propia codificación para los regímenes especiales de IVA.

Cada territorio tiene su propia codificación para los regímenes especiales de IVA.

Los regímenes de IVA permitidos varían según el tipo de impuesto (vat_type) aplicable en la factura.

Ejemplo: cuando vat_type = IPSI en un territorio Verifactu, no se requiere un sistema de IVA en la estructura XML; por lo tanto, SIGN ES permite cualquier sistema de IVA, aunque se recomienda utilizar el sistema REGULAR.

Los valores aceptados para system.type incluyen:

REGULAR

SIMPLIFIED_REGIME

EQUIVALENCE_SURCHARGE

EXPORT

AGRICULTURE
ANTIQUES
TRAVEL_AGENCIES
TRAVEL_AGENCY_MEDIATOR
OTHER_TAX_IVA
OTHER_TAX_IGIC
OTHER_TAXC_IPSI
RENT_PREMISES
CASH_CRITERIA
INVESTMENT_GOLD
SUCCESSIVE_TRANSACTIONS_PENDING_VAT
RETAIL_TRADERS
SMALL_PROFESSIONALS
INTERNAL_IGIC_EXEMPT
OSS_IOSS

A continuación, se presenta una breve descripción de cada régimen, junto con recursos oficiales de la Agencia Tributaria Española para más información.

Régimen general (Regular)

Es el régimen estándar de IVA para la mayoría de las actividades empresariales, y generalmente se aplica a la mayoría de los contribuyentes y transacciones.

Más información: Régimen general

Régimen simplificado (Simplified regime)

Diseñado para pequeñas empresas y profesionales autónomos, este régimen simplifica la declaración del IVA mediante cuotas fijas.

Más información: Régimen simplificado

Recargo de equivalencia (Equivalence surcharge)

Es un régimen especial de IVA en el cual los proveedores aplican un recargo sobre los artículos facturados a los comerciantes minoristas, por lo que estos últimos quedan exentos de presentar declaraciones de IVA.

Más información: Régimen especial del recargo de equivalencia

Exportaciones (Exports)

Se aplica a operaciones que implican la exportación de bienes y servicios. Estas actividades pueden estar exentas de IVA, dependiendo del destino y de las condiciones legales.

Más información: Exportación

Agricultura (REAGYP)

Aplica a titulares de explotaciones agrícolas, ganaderas, forestales o pesqueras que no hayan renunciado ni estén excluidos del mismo..

Más información: Agricultura, ganadería y pesca (REAGYP)

Antigüedades (REBU)

Régimen especial de los bienes usados, objetos de arte, antigüedades y objetos de colección

Más información: Bienes usados y antigüedades (REBU)

Agencias de Viajes

Régimen especial de las agencias de viaje.

Más información: Agencias de Viajes

Agencias de Viajes como Mediadoras y por Cuenta Ajena

Régimen especial para la facturación de las prestaciones de servicios de agencias de viaje que actúan como mediadoras en nombre y por cuenta ajena. Aplicable a agencias de viajes que actúan exclusivamente como intermediarios, es decir, que venden servicios en nombre de otros proveedores. Los servicios subyacentes son facturados directamente por el proveedor al cliente.

Más información: Agencias de viajes como mediadoras

Operaciones sujetas al impuesto de otro territorio

Para operaciones exentas del impuesto territorial que apliquen el tipo impositivo de un territorio español distinto.

La API de SIGN ES admite OTHER_TAX_IGIC, OTHER_TAX_IPSI y OTHER_TAX_IVA. Se utilizan cuando el tipo impositivo habitualmente aplicable al contribuyente no sea el que corresponde al ítem. Por ejemplo, un contribuyente registrado en Madrid que venda un producto sujeto a IPSI puede marcar ese ítem como OTHER_TAX_IPSI, siempre que el contribuyente esté registrado en dicho régimen.

Arrendamiento de local de negocio

Aplicable a los alquileres de locales de negocio en los que debe aplicarse IVA (habitualmente, 21 %). El contribuyente debe estar dado de alta en esta actividad de IVA.

Más información: Arrendamiento de local de negocio

Régimen especial del criterio de caja

Permite diferir el devengo y la declaración del IVA hasta que se reciba el pago del cliente y, de forma simétrica, retrasa el derecho a deducir el IVA soportado hasta que se pague al proveedor. Aplica tanto a proveedores como a clientes bajo doble criterio de caja.

Más información: Régimen especial del criterio de caja

Régimen especial del oro de inversión

Régimen obligatorio para operaciones con oro de inversión, en general exentas de IVA, con restricciones en la deducción del IVA soportado.

Más información: Régimen especial del oro de inversión

Operaciones de tracto sucesivo pendientes de devengo

Se usa cuando las operaciones (p. ej., suministros o arrendamientos) se realizan a lo largo del tiempo y el IVA aún no ha devengado—normalmente cuando el pago o la ejecución se difiere. La fecha de la operación debe reflejar la fecha de devengo del IVA.

Régimen especial de comerciante minorista

Aplica a comerciantes en Canarias que venden habitualmente bienes muebles sin transformación y cuyo al menos 70 % de ventas son a consumidores finales.

Este régimen solo es aplicable cuando vat_type = IGIC.

Régimen especial del pequeño empresario o profesional

Diseñado para pequeños empresarios o profesionales bajo IGIC, exentos de repercutir IGIC en sus facturas. Las facturas deben incluir una causa de exención.

Este régimen solo es aplicable cuando vat_type = IGIC.

Operaciones interiores exentas (artículo 25 Ley 19/1994)

Cubre operaciones exentas de IGIC conforme al artículo 25 de la Ley 19/1994 en Canarias (p. ej., ciertos suministros locales de bienes y servicios).

Regímenes del capítulo XI del título IX OSS e IOSS

Los sistemas OSS (ventanilla única) e IOSS (ventanilla única de importación) simplifican el cumplimiento del IVA en operaciones B2C transfronterizas dentro de la UE.

**OSS **permite a empresas de la UE declarar y pagar el IVA de ventas a consumidores de otros países de la UE mediante un único registro.

IOSS aplica a ventas a distancia de bienes importados desde fuera de la UE por hasta 150 €.

Más información: Guía de la Comisión Europea sobre OSS/IOSS

¿Cuáles son los tiempos de respuesta típicos al crear una factura?

Al utilizar el endpoint createInvoice, puedes esperar los siguientes tiempos de respuesta:

Tiempo de respuesta mínimo: 120ms

Tiempo de respuesta promedio: 250ms

Tiempo de respuesta máximo: 600ms

Estos tiempos representan el rendimiento habitual.

Si notas que los tiempos de respuesta se encuentran constantemente fuera de este rango, te recomendamos contactar a nuestro equipo de soporte.

¿Cómo registrar el certificado de dispositivo en el País Vasco?

Para el cumplimiento de la normativa TicketBAI, se asigna automáticamente un certificado de dispositivo durante la creación de un Firmante, a menos que quieras proporcionar tu propio certificado de dispositivo externo. La información del certificado puede obtenerse a través de la respuesta a la llamada de la API.

El proceso para registrar certificados varía entre provincias:

En Gipuzkoa, una vez que el dispositivo está emitiendo archivos en nombre del contribuyente, el certificado de dispositivo estará disponible para su aceptación dentro del portal. El contribuyente deberá realizar esta aceptación en un **plazo máximo de un mes **mediante Tramiteak Online.

En Araba, es necesario registrar el certificado de dispositivo antes de que el dispositivo empiece a emitir facturas del contribuyente, lo cual debe realizarse en el siguiente sitio web: Registro de certificados de dispositivo.

De manera similar, en Bizkaia, el certificado de dispositivo necesita ser registrado antes de que el dispositivo comience a emitir facturas: https://ataria.ebizkaia.eus/es/catalogo-de-tramites-y-servicios?procID=1740.

¿Cómo es el flujo general de trabajo?

Paso 1: Registro Empieza por registrarte en el Dashboard. La creación de una cuenta es el primer paso, tras el cual puedes proceder a configurar la estructura organizativa de tu empresa dentro de nuestro sistema.

Paso 2: Crear la organización principal Continúa con la creación de tu organización principal utilizando el Dashboard. Esta organización representa al proveedor de TPV o al minorista con su propio sistema de TPV. Es necesario incluir la dirección de facturación en esta fase. Esta dirección se utilizará únicamente a efectos de facturación de fiskaly.

Paso 3: Organizaciones gestionadas Después de establecer tu organización principal, podrás proceder a crear organizaciones gestionadas. Cada organización gestionada representa a un cliente, lo que te permite administrarlos individualmente.

Paso 4: Crear claves API El siguiente paso es generar una clave API para cada organización gestionada. Esto se puede hacer a través del Dashboard o del endpoint createApiKey de la Management API. Esta clave API y el secreto son necesarios para generar un token de acceso, que se utiliza para todas las llamadas posteriores a la API.

Ten en cuenta que las claves API generadas en el entorno TEST crearán recursos TEST, mientras que las del entorno LIVE (PRODUCCIÓN) crearán recursos LIVE. Para más información, consulta nuestro artículo sobre el entorno Test y LIVE.

Paso 5: Información del contribuyente Es necesario añadir la información del contribuyente al sistema a través del endpoint createTaxpayer de la API de SIGN ES. Este es un paso obligatorio para garantizar que todas las facturas generadas cumplan con la normativa fiscal e incluyan todos los datos necesarios del contribuyente.

Paso 6: Crear un Firmante A continuación, debes crear un Firmante a través del endpoint createSigner para cada organización gestionada. El firmante es responsable de la firma digital de las facturas. Cada dispositivo de firma requiere un certificado.

Para el cumplimiento de la normativa TicketBAI, se asigna automáticamente un certificado de dispositivo durante la creación de un Firmante, a menos que quieras proporcionar tu propio certificado de dispositivo externo. El certificado puede obtenerse a través de la respuesta a la llamada de la API.

Para cumplir con Verifactu, nuestro certificado electrónico está asociado al contribuyente.

Paso 7: Crear Clientes El flujo de trabajo incluye la creación de Clientes a través del endpoint createClient. Debes crear un Cliente para cada dispositivo POS u otros dispositivos de facturación utilizados en tu organización.

Paso 8: Crear facturas Una vez completados todos los pasos anteriores, estás listo para crear facturas. Este es el paso final en el que se generan y firman las facturas. SIGN ES asegura que todas las facturas cumplen con TicketBAI en el País Vasco, y Verifactu en el resto del territorio español. Consulta la normativa de facturación en España para obtener información adicional sobre la creación de facturas.

Para más información, incluimos un vídeo: SIGN ES & la Estructura de Organizaciones para Veri*factu

¿Tenemos que certificar nuestro software o hacer algún otro trámite en los territorios vascos?

Tenemos todos los certificados que necesitas para fiscalizar acorde a la ley. SIGN ES está inscrito en el Registro de sofware garante TicketBAI de Álava, Guipúzcoa y Vizcaya, es 100% conforme con la ley y genera firmas digitales para las transacciones en tu sistema TPV o de facturación.

Todos los archivos XML TicketBAI se enviarán indicando la información de registro de fiskaly. Esta es la información que necesitas mostrar en el TPV en caso de auditoría (disponible a través de endpoint software de SIGN ES API)

El único paso necesario que debe realizar el contribuyente es asociar su Número de Identificación Fiscal (NIF) al certificado de dispositivo utilizado. Para esto, se indica el número de serie del certificado en la respuesta al crear/obtener un firmante. Si el contribuyente no comunica el número del certificado de dispositivo a la Agencia Tributaria, el envío obligatorio de los ficheros TicketBAI será rechazado.

¿Cumple SIGN ES con TicketBAI y Verifactu?

La API fiskaly SIGN ES garantiza el cumplimiento de la normativa TicketBAI en el País Vasco y de Verifactu en el resto de España.

¿Dónde puedo encontrar la documentación de la API SIGN ES?

La documentación de la API fiskaly SIGN ES está disponible en el sitio web del desarrollador.

Para más información, incluimos un vídeo: SIGN ES - Primeros pasos

Clientes (2)

Cómo desactivar un recurso Cliente

Un Cliente solo puede desactivarse a través de la API utilizando el endpoint updateClient. Para desactivar el Cliente, se debe enviar el siguiente cuerpo de la solicitud:

{
    "content": {
        "state": "DISABLED"
    }
}

Importante: La desactivación es irreversible. Una vez que un Cliente se establece como DISABLED, no puede volver a activarse. Si fuera necesario en el futuro, deberá crearse un nuevo recurso Cliente.

¿Puedo crear clientes en el dashboard de fiskaly y vincularlos a los firmantes?

No ofrecemos esta funcionalidad.

Nuestro dashboard es principalmente para fines de visualización. Puedes gestionar usuarios, crear Claves API y ver información del sistema como firmantes y clientes, entre otras cosas.

Para más información, incluimos un vídeo: ¿Qué es un Cliente en SIGN ES?

Firmantes (4)

¿Cómo se asigna un certificado de fiskaly al crear el Signer?

Para que se asigne automáticamente un certificado de fiskaly a un Signer, sigue estos pasos:

Crea la organización gestionada (managed organization) y el contribuyente (taxpayer) de tu cliente.
Genera un UUID en tu sistema para el Firmante (Signer) (este será el signer_id).
Llama al endpoint createSigner con:

El UUID en la URL de la petición.

Un objeto JSON vacío {} como cuerpo de la petición (no proporciones ningún certificado externo).

Ejemplo:

PUT /api/v1//signers/d6625823-41a0-449a-b2e2-9e3ef5cf1c18 HTTP/1.1
Host: test.es.sign.fiskaly.com
Content-Type: application/json
Accept: application/json
Authorization: ••••••
Content-Length: 2

{}

En este caso, SIGN ES asignará automáticamente:

un certificado de dispositivo para los territorios TicketBAI, o
un certificado electrónico gestionado por fiskaly para Verifactu,

dependiendo del territorio fiscal del contribuyente.

A continuación, puedes recuperar el Signer para ver los datos del certificado (por ejemplo, el número de serie), especialmente si lo necesitas para el registro del certificado en TicketBAI.

¿Cuántos Firmantes necesito crear?

En la mayoría de los casos, crear un solo Firmante por organización gestionada es suficiente.

En promedio, un Firmante funciona con una latencia de unos 250 milisegundos por solicitud, lo que equivale a procesar aproximadamente 4–5 facturas por segundo, o alrededor de 240–300 facturas por minuto. Esta capacidad suele ser más que suficiente para las necesidades habituales de facturación.

Los rangos de rendimiento observados son los siguientes: la latencia mínima es de unos 120 ms, la latencia media es de unos 250 ms y la latencia máxima puede alcanzar aproximadamente 600 ms.

¿Cuándo conviene crear más Firmantes?

Si el volumen de facturación supera regularmente la capacidad de un único Firmante, se recomienda crear Firmantes adicionales.

Para más información, incluimos un vídeo: Firmantes en SIGN ES: TicketBAI & Veri*factu

¿Dónde puedo encontrar el número de serie del certificado del dispositivo? (TicketBAI)

Para localizar el número de serie del certificado del dispositivo, tienes dos opciones:

1.** Respuesta del endpoint** createSigner: El número de serie serial_number está incluido en la respuesta cuando se utiliza el endpoint createSigner.

fiskaly Dashboard: El número de serie también se encuentra en el fiskaly Dashboard. Navega hasta la sección de España y selecciona Firmantes. El número de serie aparecerá junto al dispositivo Firmante correspondiente.

Para más información, incluimos un vídeo: Firmantes en SIGN ES: TicketBAI & Veri*factu

¿Puedo crear firmantes en el dashboard de fiskaly?

No ofrecemos esta funcionalidad.

Nuestro dashboard es principalmente para fines de visualización. Puedes gestionar usuarios, crear Claves API y ver información del sistema como firmantes y clientes, entre otras cosas.

Contribuyentes (3)

¿Cómo utilizar los endpoints para el acuerdo de colaboración social?

Proporcionamos todos los endpoints que necesitas para una solución conforme a la normativa. La API de SIGN ES requerirá toda la información necesaria para completar el anexo de colaboración social, siguiendo el modelo proporcionado por las autoridades en la Resolución del 18 de diciembre de 2024.

El Anexo 1 es el modelo de representación entre los contribuyentes y los proveedores de software, mediante el cual el contribuyente autoriza a fiskaly a transmitir los registros de facturación Verifactu a la Agencia Tributaria. La información requerida varía dependiendo de si el contribuyente es una EMPRESA (COMPANY) o una PERSONA FÍSICA (INDIVIDUAL).

Paso a paso con la API de SIGN ES

Asegúrate de haber proporcionado toda la información en el endpoint Crear contribuyente:

Nombre legal del contribuyente (legal_name)

NIF del contribuyente (tax_number)
Dirección legal del contribuyente (address). Si falta la dirección, puedes usar el endpoint Actualizar contribuyente para añadirla.
Usa el endpoint Generar acuerdo para generar el documento. Si falta información, lo verás reflejado en la respuesta de la API.

Para contribuyentes del tipo** PERSONA FÍSICA**, no se requiere información adicional.

Para contribuyentes del tipo EMPRESA, se necesita la información del representante legal:

Nombre del representante (full_name)

NIF del representante (tax_number)
Dirección del representante (address)
Obtén el PDF completado del acuerdo en la respuesta exitosa del endpoint Generar acuerdo.
El contribuyente debe firmar electrónicamente el PDF (por ejemplo, a través de la plataforma online VALIDe o con la aplicación de escritorio AutoFirma).
Sube el acuerdo firmado electrónicamente usando el endpoint Subir acuerdo firmado.

Si se modifica la información del contribuyente y/o del representante legal, será necesario subir un nuevo acuerdo.

La API de SIGN ES siempre devolverá el acuerdo válido más reciente a través del endpoint Obtener acuerdo.

¿Qué información valida fiskaly en un acuerdo subido?

Cuando se envía un PDF a través del endpoint Subir acuerdo firmado, fiskaly verifica lo siguiente:

Coincidencia de los datos del contribuyente El acuerdo debe contener el mismo nombre y número de identificación fiscal que el Contribuyente que lo presenta.

Presencia de la firma de fiskaly El PDF debe incluir la firma electrónica de fiskaly, tal como se proporcionó en el acuerdo generado originalmente.

Presencia de la segunda firma El documento también debe contener una segunda firma electrónica, asociada con el NIF de la persona que firma el acuerdo.

Si alguna de estas condiciones no se cumple, la carga fallará y se devolverá un error:

cannot be recognized as a valid agreement

El archivo subido no es un PDF (por ejemplo, una imagen o vídeo), o
El archivo sí es un PDF, pero no es el generado por fiskaly.

too few signatures

Como se requieren al menos 2 firmas en el acuerdo, este error aparece si:

El archivo se subió sin firmar, o
La firma electrónica de fiskaly fue eliminada, dejando solo tu firma.

missing fiskaly seal

La primera firma del documento no corresponde a fiskaly.

signature does not match representative NIF

La firma no perteneciente a fiskaly no coincide con el NIF del representante indicado en el acuerdo.

cannot parse document

El documento no es un PDF válido.

signature {n} is invalid

La firma en la posición n del documento no superó la validación del servicio DSS.

¿Cuándo y cómo debo deshabilitar a un contribuyente?

El recurso del contribuyente no puede eliminarse, pero puede deshabilitarse. Esto puede ser útil en casos donde se haya creado un contribuyente por error en el entorno LIVE, o como parte del proceso de offboarding cuando la organización gestionada ya no esté en uso.

Cuando se deshabilita un contribuyente, no se pueden crear nuevos clientes ni firmantes bajo él. Sin embargo, la metainformación (metadata) existente permanece accesible si es necesario.

Antes de deshabilitar el contribuyente, todos los firmantes y clientes asociados también deben ser deshabilitados; de lo contrario, la solicitud no será aceptada. Una vez hecho esto, se puede llamar al endpoint PATCH /taxpayer con "state": "DISABLED" en el cuerpo de la solicitud.

Una vez que se deshabilita un contribuyente, no se puede volver a habilitar.

¿Qué ocurre si hay que modificar los datos del contribuyente?

La información del contribuyente sólo se puede modificar enviando una llamada PUT cuando no hay recursos (clientes, firmantes) habilitados. Una vez los recursos estén creados esta información no se puede modificar.

Esto se debe al envío en tiempo real con las haciendas forales. Al validar los ficheros, la autoridad tributaria comprueba, si los datos del contribuyente son correctos y está registrado en la provincia correspondiente. El nombre, NIF y territorio no se deben modificar una vez iniciado este proceso.

Para evitar problemas, como el envío de ficheros con información de contribuyente incorrecta, se recomienda que el integrador de SIGN ES API incluya un mecanismo de comprobación, para confirmar que la información proporcionada sea correcta.

Si, en el futuro, hay un cambio en la información del contribuyente, se debe crear una nueva organización gestionada (managed_organisation) con nuevos recursos.

Para más información, incluimos un vídeo: ¿Qué es un contribuyente y cómo modificar los datos?

Autenticación (1)

¿Cómo es el proceso de autenticación?

La autenticación se realiza inicialmente a través de la clave API y el secreto API creados en la organización gestionada.

Recibirás un access_token válido durante 24 horas y un refresh_token válido durante 48 horas. Puedes utilizarlo para volver a autenticarte de forma continua.

Si recibes una respuesta 401, simplemente vuelve a autenticarte mediante la clave API y el secreto API.

La reautenticación no debería producirse en cada solicitud, ya que retrasaría innecesariamente el proceso.

Para las solicitudes en los endpoints de autenticación recomendamos un tiempo de espera de 3-4 segundos.

Errores y códigos de estado (1)

¿Qué debo hacer si pierdo conexión a internet?

Pérdida de conexión con el servidor de la autoridad tributaria

Mientras tengas conexión con SIGN ES, no debes preocuparte. En el caso que se pierda la conexión al servidor de las autoridades fiscales, SIGN ES implementa una comprobación de la disponibilidad del servicio. En cuanto se reestablece la conexión, continuará automáticamente la transmisión ordenada de ficheros TicketBAI/Verifactu.

Si pierdes conexión con fiskaly

Para el caso de problemas de conectividad del sistema TPV, cada Hacienda Foral ha establecido una serie de indicaciones a seguir. Estas indicaciones varían según la provincia en el País Vasco.

Para Verifactu, puedes consultar los requisitos específicos en nuestro artículo sobre pérdida de conexión.

Was this page helpful?