Offline Invoicing Under Verifactu: Incident Mode vs TicketBAI's Connectivity Assumption
Spain's two fiscal systems treat connectivity differently. Verifactu lets you keep invoicing through an outage and sync later. TicketBAI's design assumes you are online. Here is what that means for POS, field work, and multi-region operations.
Offline Invoicing Under Verifactu: Incident Mode vs TicketBAI's Connectivity Assumption
Connectivity fails. Restaurants lose internet mid-service, field technicians work in basements, rural sites run on weak links. How your fiscal system behaves during an outage is not a technical footnote; it decides whether you can legally keep issuing invoices. Spain's two frameworks answer the question differently.
Verifactu: The Formalized Incident Mode
Verifactu includes a structured incident mode (modo de incidencia). When the connection to AEAT fails, a compliant SIF may:
- Continue issuing invoices normally, each with its immutable registration record, hash-chained locally
- Queue the pending records locally
- Synchronize the queued records when connectivity returns, within the required windows
The anti-fraud properties survive the outage because they are local: the chain, the hash, the QR code do not depend on real-time contact with the tax authority. In Verifactu mode (sending), the transmission catches up after reconnection. In record-only mode, nothing was being sent anyway; the records sit in the local archive, available on demand.
What incident mode does not allow: issuing invoices outside a compliant SIF "because the internet was down". A notebook and a pen during an outage is not incident mode. It is unregistered invoicing.
TicketBAI: The Connectivity Assumption
TicketBAI's design assumes constant internet connectivity. Every invoice generates its signed XML and transmits to the provincial tax authority in real time or near real time. There is no equivalent formalized fallback mechanism in the system's design.
For businesses in Alava, Bizkaia, and Gipuzkoa, this changes the infrastructure question from "what do we do during an outage" to "how do we make outages rare and short":
- Redundant connectivity at fixed sites: primary and failover links at POS-heavy locations
- Queuing with clear operator status: software must handle transmission failures gracefully, show the operator exactly which invoices are pending transmission, and retry automatically
- Explicit procedures for offline-heavy work: markets, food trucks, rural installations need arrangements consistent with the provincial authority's expectations, not improvised workarounds
The Comparison That Matters
| Verifactu | TicketBAI | |
|---|---|---|
| Core dependency | Local integrity (hash chain) | Real-time transmission |
| Outage behaviour | Formalized incident mode: issue offline, sync later | No formalized fallback; connectivity assumed |
| QR on invoice | Yes, AEAT verification | Yes, TBAI verification |
| Multi-region implication | National common territory | Alava, Bizkaia, Gipuzkoa (Batuz in Bizkaia) |
Planning by Business Type
Hospitality and retail (POS)
POS is where outages hurt most: service cannot stop. Under Verifactu, confirm your POS software implements incident mode genuinely, with local chaining and automatic sync, not just a retry button. Under TicketBAI, connectivity redundancy is the primary control; a second SIM-based failover link is cheap insurance at a card-and-cash till.
Field services and trades
Invoices issued on-site from a phone or tablet. Under Verifactu, incident mode covers the basement-with-no-signal scenario if the app records and queues locally. Under TicketBAI, the design assumes the invoice waits for signal. Build the flow so the invoice is drafted on-site and issued when connectivity returns, with the operator's clear understanding of when it legally exists.
Multi-region operators
A group with entities in Madrid (Verifactu), Bilbao (TicketBAI plus Batuz), and Pamplona (NaTicket) runs three fiscal behaviours from one operational stack. The software decision is not "does it support Spain" but "does it implement each regime's outage behaviour, chaining, and reporting per entity". Entity-level configuration, not country-level.
Testing Your Outage Behaviour
Once, before you need it:
- Pull the network cable. Issue ten invoices. Check each has its record, its chain position, and its QR.
- Reconnect. Verify the queue synchronizes fully, in order, with no gaps and no duplicates.
- Check the event log. The outage and the resync should be visible events. An inspector can ask.
- For TicketBAI entities: verify the operator-facing status. Which invoices are pending transmission must be unambiguous on screen.
- Document the test in your process documentation. Outage behaviour is part of the system description.
Common Misreadings
"Verifactu incident mode means paper backup is fine." No. Incident mode operates inside the compliant SIF. Paper invoices during an outage are outside the chain.
"TicketBAI has the same fallback as Verifactu." It does not. The design assumes connectivity. Plan infrastructure, not exemptions.
"One Spanish software stack covers all regions automatically." Regional regimes have different schemas, endpoints, and outage behaviour. Verify per entity, per province.
"Outages are an IT detail." In a fiscalized system, outage behaviour defines when an invoice legally exists. That is an operations decision with compliance consequences.
This material is information of a general nature and does not constitute legal or tax advice. For a specific situation, verify the current rules or consult a qualified adviser.