What a process that actually works looks like

Yes, it can be automated

The Ministry built for this. The decree requires submission by electronic means, the platform supports batch uploads and a machine-to-machine web service, and the credentials for it are issued to you when you register a property — see submitting guest data.

Most booking systems and specialist services connect to it. If you are typing every guest by hand and have more than a handful of bookings, you are doing work that was automated for you on day one.

The eight steps

Whatever tools you use, a process that holds up does these things in this order:

1. Collect the required details, securely.
2. Check them for obvious errors before they go anywhere.
3. Get the guest's acceptance — with a signature from everyone aged 14 and over.
4. Attach each guest to the right booking and the right property.
5. Submit to SES.Hospedajes.
6. Confirm whether it was accepted or rejected.
7. Flag failures so somebody fixes them.
8. Keep the records for three years, if you let professionally.

Steps 6 and 7 are the ones almost everyone leaves out, and they are where the breaches come from.

The four places it actually goes wrong

Not theory. These are the failures that recur.

1. The handover gap

The owner believes the agent files everything. The agent believes they file only their own bookings. A direct booking arrives, sits in the space between the two assumptions, and is never reported.

The fix costs nothing: write down which party files which bookings, including direct bookings, owner stays and friends-and-family stays. See who is responsible.

2. The rejection nobody read

A submission the platform accepts is not necessarily one that went through. Individual travellers get rejected inside an otherwise successful batch.

Something filed at 23:40 and bounced at 23:41 is, by the following evening, a missed deadline nobody knows about.

The fix: somebody or something checks the outcome, not that it was sent. This is a habit, not a technology — and it is the single cheapest improvement most owners can make. See when a submission is rejected.

3. The guest who doesn't reply

The largest cause of late filings by some distance, and the one software genuinely cannot solve. A form sent is not a form completed.

4. The certificate that expired

Quietly, in February. Discovered in July, at nine in the evening, by someone trying to file for guests who arrived that afternoon — and the replacement takes weeks.

The fix: a calendar reminder two months before expiry, not two weeks. See digital certificates.

The evidence question

Worth separating from everything above, because it is newer and catches people who are otherwise doing well.

Submitting the data satisfies the duty to report. It does not, on its own, produce anything showing that a particular guest gave you those details and confirmed them. The decree requires a signature from every traveller aged 14 and over — and a spreadsheet re-keyed into the portal produces no signature at all.

Owners have started running into this when asked to evidence a registration rather than simply to have made one. By then the stay is over and the guest has gone home.

If your current process involves copying details across by hand, that gap is worth closing regardless of which route you use.

The test

A process is working if you can answer these without checking:

• Which bookings do I file, and which does somebody else file?
• How would I find out that last night's submission was rejected?
• When does my certificate expire?
• If someone asked me to prove a guest from June gave me their details, what would I show them?

If any of those makes you pause, that is where your process breaks — not in the part you have been worrying about.