Envío de ficheros XML

El cumplimiento de TicketBAI contempla la creación de dos tipos de ficheros XML:

• Ficheros de registro: Fichero XML que se crea cuando se emite una nueva factura.

• Ficheros de cancelación: Fichero XML que se crea cuando se cancela una factura, como en el caso de transacciones no realizadas.

TicketBAI requiere que estos ficheros se envían a la Autoridad Tributaria correspondiente, dependiendo de dónde esté declarado el domicilio social del contribuyente que emite las facturas.

Álava y Gipuzkoa

SIGN ES realiza el envío automáticamente en Álava y Gipuzkoa. Las facturas enviadas por SIGN ES se utilizan como el “Libro de facturas emitidas” del sistema SII (Suministro Inmediato de Información) para los contribuyentes obligados. Sin embargo, si se requiere información adicional según contempla el SII, como referencias externas, transmisiones de inmuebles sujetas a IVA, entre otras, esta tendrá que enviarse a través de un servicio adicional llamado OSATU, no contemplado en las especificaciones de TicketBAI (consulta los requisitos del servicio OSATU disponible en español).

El proceso de envío de los ficheros TicketBAI se lleva a cabo en el componente de firma de la API SIGN ES. El componente de firma sincroniza el estado de los ficheros TicketBAI desde el servidor SIGN ES al servidor de la Autoridad Tributaria española. Esta sincronización se implementa sobre el modelo de solicitud/respuesta proporcionado por la Autoridad Tributaria española.

Respuesta

Cuando se envía un fichero, los sistemas de las Autoridades Tributarias realizan automáticamente diversas validaciones, y los resultados de estas comprobaciones se incluyen en la respuesta.

El estado de registro ideal es REGISTERED. SIGN ES ayuda a reducir los rechazos garantizando que los ficheros XML estén correctamente estructurados y que los datos tengan el formato correcto a través de sus procesos de validación.

Sin embargo, si el estado de registro de una factura aparece como REQUIRES_CORRECTION, puede ser necesario volver a enviar el fichero, siempre que la normativa española de facturación no exija la emisión de una factura rectificativa.

Reenvío de facturas

SIGN ES permite el reenvío de facturas en los estados de registro REGISTERED, REQUIRES_CORRECTION y REQUIRES_INSPECTION mediante facturas REMEDY a Zuzendu en los siguientes casos:

• los ficheros de registro han sido rechazados
• los ficheros de registro han sido aceptados con errores pero NO requieren una corrección legal
• ficheros aceptados por TicketBAI en los que el contribuyente necesita modificar información que no requiere una corrección legal

Si se recibe un error porque el contribuyente no ha registrado el certificado de dispositivo en Álava o ha superado el período de aceptación de 30 días en Gipuzkoa, el contribuyente debe registrar o aceptar el certificado de dispositivo de inmediato, según el territorio correspondiente.

No está permitido el reenvío de facturas con estado de registro PENDING o STORED. Estas facturas están esperando la presentación por parte de SIGN ES o están almacenadas porque no es necesaria la transmisión a la Autoridad Tributaria.

Bizkaia

Envío de facturas con SIGN ES

El envío se realiza utilizando un certificado de dispositivo que debe ser registrado en DFB/BFA por el contribuyente obligado. Esto debe realizarse antes de que el dispositivo empiece a generar facturas en nombre del contribuyente.

Al enviar las facturas en tiempo real garantizamos el cumplimiento de los plazos impuestos por BATUZ.

EMPRESAS: SIGN ES realiza el envío automático de facturas TicketBAI en el subapartado 1.1 del LROE – Facturas emitidas con software garante (Modelo 240). Esta presentación es en tiempo real.

PERSONAS FÍSICAS: una vez proporcionado el código de actividad, SIGN ES realiza el envío de facturas TicketBAI en el subapartado 1.1 del LROE – Ingresos con facturas emitidas con software garante (Modelo 140).

Lo ideal es que el activity_code se proporciona en el momento de crear la factura. Esto permite la transmisión en tiempo real de la factura a las autoridades tributarias. De lo contrario, la factura permanecerá en estado STORED y solo se enviará a las autoridades tributarias después de que la factura se haya actualizado con el código de actividad.

📘Note

Comprueba que el código de actividad sea válido en Bizkaia; de lo contrario, la factura será rechazada por la Autoridad Tributaria.

Para las personas físicas, existen dos campos opcionales adicionales: income_tax_amount y pay_collect, que junto con el activity_code forman un conjunto agrupado de datos. Si estos campos se dejan vacíos mientras se proporciona el código de actividad, se marcarán automáticamente como ‘No’ por defecto.

Si la base imponible del IVA es diferente de los ingresos del IRPF, el contribuyente deberá rellenar el campo income_tax_amount. Para orientación sobre cómo calcularlo, puedes consultar nuestro artículo ¿Cómo calcular el importe de ingresos del IRPF en una factura?

El campo pay_collect indica si el contribuyente ha optado por el criterio de cobros y pagos.

📘Note

El código de actividad solo puede introducirse una vez, ya sea durante la creación de la factura o al actualizarla, y no puede modificarse posteriormente. Esto también aplica a los campos income_tax_amount y pay_collection, una vez que los envías junto con el código de actividad. Esto garantiza que esta información, una vez introducida, permanezca coherente e invariable.

El campo vat_withholding en nuestra API podría aplicarse tanto a personas físicas como a empresas, específicamente a transacciones B2B que incluyen facturas completas y sus correcciones. Este campo contempla un escenario específico del sistema fiscal que implica a autónomos que, al emitir facturas a empresas u otros autónomos, están obligados a retener una parte del IRPF (impuesto sobre la renta) de sus ingresos. En este sistema, es el comprador, no el vendedor, quien remite directamente una parte del impuesto a la autoridad.

Respuesta

Al recibir una solicitud, los sistemas de la Autoridad Tributaria de Bizkaia realizan automáticamente validaciones, y el resultado de estas validaciones se refleja en la respuesta, al igual que en otras provincias.

Idealmente, el estado de registro debería ser REGISTERED. SIGN ES minimiza los rechazos garantizando la estructura correcta de los ficheros XML y el formato correcto de los datos introducidos a través de las validaciones aplicadas.

Sin embargo, si el estado de registro de una factura muestra REQUIRES_INSPECTION, es probable que los ficheros deban volver a enviarse al sistema de la Autoridad Tributaria de Bizkaia, siempre que la normativa española de facturación no exija una factura rectificativa. Dependiendo del caso, esto puede hacerse mediante el reenvío a través del subapartado 1.1 para facturas emitidas con software garante o mediante el subapartado 1.2 para facturas emitidas sin software garante.

Reenvío de facturas

SIGN ES permite el reenvío de facturas en estado de registro REQUIRES_INSPECTION mediante facturas REMEDY a través de los subapartados 1.1 y 1.2. No está permitido el reenvío de facturas con estado de registro PENDING y STORED. Estas facturas están esperando la presentación por parte de SIGN ES o están almacenadas porque no es necesaria la transmisión a la Autoridad Tributaria o falta información importante.

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

• el error se debe a datos no válidos introducidos en los campos del bloque annotations
• el certificado de dispositivo no estaba registrado o fue registrado incorrectamente por el contribuyente en el momento de la transmisión

El reenvío a través del subapartado 1.2 es posible si:

• el subapartado 1.1 fue rechazado y el reenvío a través de 1.1 no es posible
• si la factura ya ha sido subsanada y enviada a través de 1.2. También es posible subsanar la factura subsanada si la factura de subsanación se encuentra en estado REGISTERED

Facturas sin conexión

Las facturas emitidas sin conexión en Bizkaia se clasifican como “emitidas sin software garante” y deben transmitirse al subapartado 1.2 del LROE.

Para transmitir estas facturas, primero debe registrarlas en el sistema SIGN ES como facturas externas, utilizando el tipo de factura EXTERNAL. Este paso es esencial para asignar un UUID a la factura generada sin conexión.

Cuando la factura se carga como factura EXTERNAL, no se transmitirá a la agencia tributaria. En cambio, como cualquier otra factura externa, tendrá un estado de registro de INVALID.

Para transmitir la factura, el siguiente paso requiere la creación de una factura de tipo REMEDY, referenciando el UUID asignado previamente a la factura externa.

Entorno de prueba

El entorno de prueba en Bizkaia requiere NIF, número de IVA y certificado de dispositivo específicos para evitar errores de rechazo. En fiskaly, hemos solicitado formalmente y obtenido esta información de las autoridades. Estos datos específicos anularán automáticamente los datos de prueba proporcionados durante la creación de ficheros XML, SOLO EN EL ENTORNO DE PRUEBA. De esta manera, garantizamos un flujo de trabajo de pruebas fluido con respuestas de transmisión efectivas.

📘Note

La API de SIGN ES realiza validaciones que evitan el rechazo de los ficheros XML al enviarlos a la Autoridad Tributaria.