Norma EPC & SEPA-QR – Estructura técnica explicada

La estructura técnica del payload EPC

El contenido (payload) de un GiroCode es un bloque de texto estructurado en líneas, donde cada línea tiene un significado específico y debe respetar un orden fijo. A continuación se describe cada línea con su contenido, restricciones y un ejemplo práctico:

BCD
002
1
SCT
SSKMDEMMXXX
Max Mustermann GmbH
DE89370400440532013000
EUR199.99

Factura FA-2024-015

Línea 1: BCD (Service Tag)

Contenido fijo: BCD
El Service Tag identifica este código QR como un GiroCode/SEPA Credit Transfer. Siempre debe ser exactamente BCD. Ningún otro valor es válido. Las apps bancarias reconocen este identificador para saber que están ante un código de pago SEPA y no ante un código QR genérico.

Línea 2: Versión

Valores posibles: 001 o 002
Indica la versión del estándar EPC utilizada. La versión 001 fue la original y requería el BIC obligatoriamente. La versión 002 hace el BIC opcional. En la práctica, hoy se recomienda usar siempre 002.

Línea 3: Codificación de caracteres

Valores posibles: 1 (UTF-8), 2(ISO 8859-1), 3 (ISO 8859-2), etc.
El valor 1 indica UTF-8, que es la codificación recomendada y la más compatible con caracteres especiales de todos los idiomas europeos (tildes, diéresis, caracteres especiales…). Es importante ser consistente: la codificación indicada aquí debe coincidir con la codificación real del texto del payload.

Línea 4: Identificación de la función

Contenido fijo: SCT
SCT significa «SEPA Credit Transfer» (Transferencia de Crédito SEPA). Es el único valor definido actualmente por el estándar EPC para GiroCodes. Identifica el tipo de operación de pago que se va a iniciar.

Línea 5: BIC del banco beneficiario

Formato: 8 u 11 caracteres alfanuméricos, o vacío en versión 002
Ejemplo: SSKMDEMMXXX
En la versión 002 del estándar, el BIC es opcional. Si no se incluye, esta línea debe estar vacía (línea en blanco). Desde la migración SEPA de 2016, los bancos de la zona SEPA pueden derivar el BIC a partir del IBAN, por lo que ya no es estrictamente necesario para la mayoría de los pagos nacionales e internacionales dentro de SEPA. Sin embargo, algunos implementadores todavía lo requieren para mayor compatibilidad.

Línea 6: Nombre del beneficiario

Longitud máxima: 70 caracteres
Ejemplo: Max Mustermann GmbH
El nombre del beneficiario tal como aparece en la cuenta bancaria. Este campo es obligatorio y no puede estar vacío. Se recomienda usar el nombre exacto que figura en el contrato bancario para evitar rechazos en la validación de la transferencia por parte del banco destinatario.

Línea 7: IBAN del beneficiario

Formato: IBAN estándar (hasta 34 caracteres alfanuméricos)
Ejemplo: DE89370400440532013000
El IBAN identifica de forma única la cuenta bancaria del beneficiario dentro de la zona SEPA. Debe ser un IBAN válido según el algoritmo Mod-97. Cambiar un solo dígito puede hacer que el pago sea rechazado o vaya a una cuenta incorrecta.

Línea 8: Importe

Formato: EUR seguido del importe con punto decimal, o vacío
Ejemplo: EUR199.99
El importe es opcional. Si se incluye, debe seguir el formato exacto: el código ISO de la moneda (solo EUR está definido en el estándar EPC) seguido directamente del importe sin espacios, usando punto como separador decimal. El importe máximo definido por el estándar es de EUR999999999.99(aproximadamente 999 millones de euros). Si el campo se deja vacío, el pagador deberá introducir el importe manualmente en su app bancaria.

Línea 9: Tipo de objeto (Purpose)

Generalmente vacío
Este campo permite indicar el propósito de la transferencia según los códigos ISO 20022 (por ejemplo SALA para salarios, CHAR para donaciones benéficas). En la práctica comercial habitual este campo se deja vacío y no afecta al procesamiento de la transferencia.

Línea 10: Referencia estructurada (Structured Creditor Reference)

Generalmente vacío
Permite incluir una referencia estructurada como el código de referencia belga (VCS/OGM) o la referencia ISO 11649. En la mayoría de los casos, especialmente en España y Alemania, este campo se deja vacío y se usa la línea 11 para el concepto de pago libre.

Línea 11: Referencia de pago (Remittance Information)

Longitud máxima: 140 caracteres
Ejemplo: Factura FA-2024-015
El concepto de pago o referencia libre. Este es el campo que el pagador ve reflejado en su extracto bancario y que el emisor de la factura utiliza para identificar el pago en su contabilidad. Se recomienda incluir siempre el número de factura y, si procede, el nombre del cliente.

Versiones EPC comparadas

La versión 001 se considera obsoleta y ya no debe usarse en nuevas implementaciones. Todos los generadores modernos de GiroCode, incluido el nuestro, generan códigos versión 002 por defecto.

Corrección de errores y calidad del código QR

Los códigos QR pueden tolerar cierto nivel de daño o suciedad gracias a los algoritmos de corrección de errores Reed-Solomon. Existen cuatro niveles de corrección de errores definidos en el estándar QR:

• Nivel L (Low): recupera hasta el 7 % del dato dañado.
• Nivel M (Medium): recupera hasta el 15 %.
• Nivel Q (Quartile): recupera hasta el 25 %.
• Nivel H (High): recupera hasta el 30 %.

¿Por qué el estándar EPC especifica el nivel M?

El estándar EPC especifica que los GiroCodes deben generarse con el nivel de corrección de errores M, que recupera hasta el 15 % de datos dañados. Esta elección es un equilibrio cuidadoso entre dos factores contrapuestos:

• Mayor corrección de errores = código QR más grande y denso:Un nivel H genera un código QR con más módulos (puntos), lo que lo hace más grande para la misma cantidad de datos. Esto puede ser un problema cuando el código se imprime en un espacio reducido de una factura.
• Menor corrección de errores = código más compacto:El nivel L sería más compacto, pero dejaría el código vulnerable a daños mínimos durante la impresión o el escaneo.

El nivel M ofrece suficiente robustez para uso en facturas impresas (donde puede haber arañazos, marcas de plegado o manchas de impresora) sin aumentar innecesariamente el tamaño del código.

Impacto en la legibilidad y tamaño mínimo

Para garantizar una buena legibilidad, el GiroCode debe cumplir los siguientes requisitos mínimos:

• Tamaño mínimo impreso: 2 × 2 cm (recomendado). Por debajo de este tamaño, las cámaras de smartphones de gama media pueden tener dificultades para leer el código.
• Contraste: El código debe ser oscuro sobre fondo claro (o viceverso si se usa inversión de colores compatible). El contraste debe ser nítido; evitar impresión sobre fondos de color, degradados o imágenes.
• Zona de silencio: El código QR necesita un margen de al menos 4 módulos alrededor de todos sus lados. No colocar texto ni elementos gráficos dentro de este margen.
• Resolución digital: Para uso en pantallas o PDF digitales, se recomienda generar el código QR en formato vectorial (SVG) o en alta resolución (mínimo 200 × 200 píxeles para visualización en pantalla).

Implementación técnica

Si quieres implementar la generación de GiroCodes en tu propia aplicación, el primer paso es construir el payload EPC correctamente y luego usar una librería de generación de QR para codificarlo. Aquí tienes un ejemplo en JavaScript:

function generateEPCPayload({
  name,       // Nombre del beneficiario (máx. 70 chars)
  iban,       // IBAN del beneficiario
  amount,     // Importe en euros (ej: 199.99) o null
  reference,  // Concepto de pago (máx. 140 chars)
  bic = '',   // BIC (opcional en versión 002)
}) {
  const amountStr = amount !== null
    ? 'EUR' + amount.toFixed(2)
    : '';

  return [
    'BCD',          // Línea 1: Service Tag
    '002',          // Línea 2: Versión
    '1',            // Línea 3: UTF-8
    'SCT',          // Línea 4: SEPA Credit Transfer
    bic,            // Línea 5: BIC (opcional)
    name,           // Línea 6: Nombre beneficiario
    iban,           // Línea 7: IBAN
    amountStr,      // Línea 8: Importe
    '',             // Línea 9: Purpose (vacío)
    '',             // Línea 10: Ref. estructurada (vacío)
    reference,      // Línea 11: Concepto de pago
  ].join('\n');
}

// Uso:
const payload = generateEPCPayload({
  name: 'Max Mustermann GmbH',
  iban: 'DE89370400440532013000',
  amount: 199.99,
  reference: 'Factura FA-2024-015',
});
// Después pasa payload a tu librería QR favorita
// (ej: qrcode, qr-code-generator)

Una vez generado el payload, se pasa a una librería de generación de código QR configurada con nivel de corrección de errores M. En JavaScript/Node.js, la librería qrcode (npm) permite especificar este nivel con el parámetroerrorCorrectionLevel: 'M'.

Errores comunes con la norma EPC

A continuación se describen los errores más frecuentes que se cometen al implementar o usar la norma EPC para GiroCodes:

• IBAN con espacios: Algunos usuarios copian el IBAN con espacios cada cuatro dígitos (por ejemplo DE89 3704 0044 0532 0130 00). El estándar EPC requiere el IBAN sin espacios.
• Importe con coma decimal: El estándar EPC usa punto como separador decimal (EUR199.99), no coma. Usar coma provocará errores de lectura en muchas apps.
• Número de líneas incorrecto: El payload debe tener exactamente las líneas en el orden correcto. Una línea de más o de menos, o líneas en orden equivocado, producirá errores al escanear.
• Caracteres no permitidos: Aunque UTF-8 es la codificación estándar, algunos caracteres especiales (emojis, caracteres de control) pueden causar problemas en ciertas apps bancarias. Se recomienda usar solo caracteres del rango Latin-1 para máxima compatibilidad.
• Nivel de corrección de errores incorrecto: Generar el código QR con nivel L o H en lugar del nivel M especificado por el EPC puede reducir la compatibilidad con algunas apps bancarias estrictas en la validación.
• Nombre del beneficiario truncado sin aviso: Si el nombre del beneficiario supera los 70 caracteres y se trunca sin validación, el nombre que recibe la app puede diferir del nombre real en la cuenta, lo que podría generar confusión o rechazo por parte de algunos bancos.
• Concepto de pago superior a 140 caracteres: El estándar limita el concepto a 140 caracteres. Los caracteres adicionales serán ignorados o generarán un error de lectura.

Usar GiroCode profesionalmente – Recomendaciones de software

Quien quiera usar GiroCodes de forma profesional en sus facturas necesitará tarde o temprano un buen software de contabilidad o facturación. Crear GiroCodes manualmente es adecuado para uso ocasional, pero para facturación regular, una solución automatizada se amortiza rápidamente.

Recomendamos dos herramientas probadas que admiten GiroCodes de forma nativa:

* Enlace de afiliado – Si compras a través de este enlace, recibimos una pequeña comisión sin coste adicional para ti.

Para uso ocasional, recomendamos nuestro generador de GiroCode gratuito – completamente local, sin registro.