Filing guests with the authorities in Spain and Italy, automatically
Guest registration is the one part of running accommodation where "we will do it on Monday" is not an option. The deadline is 24 hours from arrival, and it does not care that it was a weekend.
The obligation, briefly
If you host paying guests in Spain or in Italy, you must report each one to the authorities: in Spain through SES.Hospedajes, in Italy through Alloggiati Web. Both give you a deadline measured in hours from arrival, not days from checkout. Both apply per guest, not per booking — a family of four is four records.
This guide is about what that means for software. It is not legal advice, and the operative requirements change; confirm the current rules with the authority or your own adviser before relying on any implementation.
Why the deadline changes the architecture
A 24-hour deadline sounds generous until you notice what it rules out.
It rules out filing as a side effect of a nightly batch, because a guest arriving at 18:00 on Friday cannot wait for whatever runs on Monday. It rules out filing inline with check-in and hoping, because if the authority's endpoint is down at that moment the record is simply lost and nothing will try again. And it rules out treating a failed submission as an error to display, because the person who would have seen the error has gone home.
What it demands instead is a queue with retries running at least hourly, and a record of what was filed, when, and with what reference. In Boris the registration step is one of the four execution areas marked required, precisely because its failure is silent and its consequence is a fine.
The two systems fail in different ways
They are not variations on one integration. They are genuinely different shapes, and a system that abstracts them too early will get both wrong.
SES.Hospedajes is a SOAP service, and the payload is not plain XML: the actual data travels as a compressed archive embedded inside the SOAP envelope. That single detail defeats most naive implementations, because everything looks like a normal web service call until you discover the body has to be zipped first.
Alloggiati Web takes fixed-width text records — each guest one line of exactly 168 characters, every field at a defined offset, padded rather than delimited. There is no forgiveness in that format. A field one character short shifts everything after it, and the record is rejected as a whole with an error that points at the line rather than at your bug.
What they share is that both demand codified values, not free text. Nationality, document type and municipality are enumerations maintained by the authority, and a guest typing "Italy" into a country box produces a record that will be refused. Whatever the guest sees, the system has to resolve it to the official code before submission.
Collect once, file per authority
The workable design is to keep one internal representation of a guest — the fields both authorities need, in your own vocabulary — and to have each provider render that into its own format at submission time. It keeps the check-in form country-agnostic, and it means adding a third country is a new renderer rather than a new data model.
Store the authority's reference when it comes back. That reference is what turns "we submitted it" into "it was accepted", and it is the only thing you can show an inspector. In Boris, a step with the authority's own evidence attached is marked verified, separately from merely having succeeded.
Then delete what you no longer need
Filing is also what ends your basis for holding the guest's document photograph. Once the stay has been filed, the image has done its job. Boris destroys those photographs at that moment, and at the end of the arrival day regardless — see the guide on QR check-in for why that is deliberately not configurable.
What to check in any system that claims to do this
- Does filing retry automatically, at least hourly, without anyone noticing it failed?
- Is a stay that was never filed visibly missing, or just absent from a log?
- Is the authority's reference stored, or only the fact that a request was sent?
- Are nationality, document type and municipality resolved to official codes?
- Does a manual, desk-completed check-in produce the same filing as the automatic one?
- Are document images destroyed once filing succeeds?