A fiscal integration is still a distributed system. Networks fail, services enter maintenance and sometimes a request reaches its destination while the response never makes it back.

The practical question is unavoidable: if the AEAT does not respond, must a business stop issuing invoices?

No. The AEAT states that a connection, power, system or electronic-office incident does not require invoicing to stop. Submission must be retried periodically once the service recovers, identifying the incident as required by the technical specifications.

Issuing the invoice and registering its outcome are separate steps

An invoice needs a number, date, customer, lines, taxes and totals. In a VERI*FACTU system it also needs a fiscal record chained to the previous record.

Waiting for the AEAT response before confirming issuance looks simple, but creates a worse problem. If the system submits the record and loses the response, it no longer knows whether to reuse the number, issue another invoice or wait. The network would have turned a fiscal operation into a gamble.

FiscalRail avoids that ambiguity. The invoice, its number and its immutable VERI*FACTU record are created together. The issuance response contains the invoice and a pending registration status. Submission to the AEAT happens afterwards.

A remote outage cannot make an issued invoice disappear or cause the API client to issue a duplicate by mistake.

What is retried automatically

FiscalRail preserves each submission attempt and treats transport failures, HTTP 408, 429 and 5xx responses, and SOAP server faults as transient. Those cases are retried with exponential backoff and jitter so a recovering service is not overwhelmed.

If a request may have reached the AEAT but its result is indeterminate, the next attempt keeps the same fiscal record. A duplicate response can reconcile the earlier attempt without creating another invoice or registration record.

Not every error should be retried blindly. A certificate failure, invalid request or data rejection needs attention. Sending the same invalid data repeatedly does not make it valid.

The states your integration should observe

Invoice issuance is synchronous; the VERI*FACTU result is asynchronous. An integration should listen for these terminal events:

  • accepted: the AEAT accepted the record.
  • accepted_with_errors: it accepted the record but returned an issue that needs review.
  • rejected: it rejected the record; inspect the structured error and original message.

Webhooks may arrive more than once and are not ordered. Deduplicate by Event ID and retrieve the invoice for its current state rather than inferring state from arrival order.

A QR code is not a substitute for this tracking either. An invoice carrying the fiscal QR does not prove that its record has reached a terminal outcome.

What your product should do during an outage

  • Confirm that the invoice is issued and retain its ID and number.
  • Show the fiscal record as pending, not failed, while the outcome is unknown.
  • Do not ask the user to issue the invoice again.
  • Process the final outcome through webhooks and make errors inspectable.
  • Distinguish a transport incident from a content rejection.

Support should also be able to trace the original request, every submission attempt and the AEAT response. “We are retrying it” is only a useful guarantee when an auditable trail exists behind it.

Test it before it happens

FiscalRail Test accounts can simulate a transient HTTP 503 response followed by acceptance. This lets you verify your interface and webhook behaviour without causing a real incident or contacting the AEAT.

Read the Spain Test guide and the VERI*FACTU guide.

The official source is the AEAT's VERI*FACTU systems FAQ.

This article is not tax advice. Ask your adviser how the obligations apply to your activity.