¿VeriFactu o TicketBAI?
Qué sistema aplica a cada emisor, y cómo lo resuelve una sola integración.
España tiene dos sistemas de facturación verificable, y el que aplica a cada emisor depende de la hacienda ante la que tributa.
| Territorio | Sistema | Administración |
|---|---|---|
| Territorio común | VeriFactu | Agencia Tributaria (AEAT) |
| Álava | TicketBAI | Hacienda Foral de Araba |
| Bizkaia | TicketBAI (dentro de Batuz/LROE) | Hacienda Foral de Bizkaia |
| Gipuzkoa | TicketBAI | Hacienda Foral de Gipuzkoa |
Para tu software, la diferencia es un endpoint
Si tu producto factura para empresas de distintos territorios, necesita cubrir ambos sistemas. Con VeriBai el contrato es el mismo JSON, y el sistema se elige por endpoint:
POST /v1/verifactu/crear: emisores de territorio común.POST /v1/ticketbai/crear+ campoprovincia: emisores forales.
Tu código decide el endpoint según el territorio del emisor; el resto de la integración no cambia.
Diferencias que la API absorbe
- Esquemas XML distintos por sistema, y por provincia en el caso foral.
- Firma: TicketBAI exige firma y encadenado en el momento de la emisión; la respuesta del alta ya incluye el
idTbai. En VeriFactu, el registro se remite de forma verificable a la AEAT. - El envoltorio LROE de Bizkaia: los envíos a Bizkaia van dentro del libro registro del sistema Batuz. Gestionado por la API sin cambios en tu petición.
- Endpoints y reglas de cada hacienda foral: cada una tiene los suyos.
Diferencias que sí verás
- El campo
provinciaes obligatorio en TicketBAI e inexistente en VeriFactu. serie,numeroyfechaExpedicionvan en el nivel superior en TicketBAI y dentro decabeceraen VeriFactu.- La respuesta TicketBAI incluye
idTbai; la de VeriFactu, no. Cada sistema devuelve lo que su normativa define.