Guest register automation: an RD 933/2021 guide

Guest register automation almost always breaks in the same place: not at submission, but in what happens before it. A form that never asks how a minor is related to the adults. A payment that lives in another system. A booking made at nine in the evening for an arrival at eleven. Real Decreto 933/2021 requires a complete documentary record of every stay and a fast report of that data, and any gap in the flow ends up showing in an inspection.

Here you have the data the decree asks for, how the time limit is counted, which offences it sets out and how to chain each step so that no stay goes unreported. Each legal point cites its article in the BOE; where the decree says nothing, we say so.

Who does RD 933/2021 apply to?

The obliged parties are the natural or legal persons who carry out or act as intermediaries in accommodation and in the rental of motor vehicles without a driver (art. 2.3). Vehicle rental is subject to the same documentary record duty as accommodation (art. 2.2), so the decree is not a rule written only for hotels.

For a holiday rental manager the practical consequence is direct: if you host travellers, or act as an intermediary for that stay, the duty is yours. It makes no difference whether you have one flat or two hundred.

Delegating the work does not move the liability

Liability for offences falls directly on the obliged parties who commit them, and delegating to a third party does not transfer it (art. 8). You can hire a check-in company, a co-host or software that does all the work. When something fails, the person who answers for it is still the holder of the activity.

That gives you a simple contracting rule:

• Require your own access to the history of submissions and their responses.
• Ask the provider to warn you about every rejection, not just the successes.
• Check that you can export your records in a format you can open without them.

Anyone who depends on a third party's dashboard finds the problem on the day they need an old stay and the provider no longer exists.

What Anexo I asks for and how to collect it

Anexo I lists the data to be recorded. It helps to read it in blocks, because each block comes from a different part of your operation.

| Block | Data required by Anexo I | Where it comes from |
|---|---|---|
| Identity of each traveller | First name, first surname, second surname, sex, type and number of identity document, document support number, nationality, date of birth and place of habitual residence | Check-in form and the traveller's document |
| Contact | Landline, mobile phone and email address | Check-in form |
| Minors | The relationship between the travellers when one of them is a minor | An explicit question in the form |
| Transaction | Payment type, identification of the payment method, holder of the payment method, card expiry date and payment date | Payment gateway or channel payout report |

Identity data is collected from every person

You have to ask every traveller, not only the person who booked. It sounds obvious and yet it is the most repeated mistake: the channel delivers the lead guest's data, the form is filled in once and the companions never appear in any record.

Design the form with one entry per occupant from the start. When the booking says four guests, the check-in link has to ask for four entries and not let the process close with one.

The relationship to a minor is not on any document

Anexo I requires declaring the relationship between the travellers when one of them is a minor. This field cannot be read from a passport, from the MRZ zone or from a platform's booking notice. You have to ask for it.

A flow that fills in the record only from document scans produces incomplete records for every family booking. And it does so without raising any error, because no technical field is left empty: a question is simply missing.

Format errors that cause most rejections

Nearly all rejections come from a handful of fields. Keep them under control in the form, before the data leaves your system.

| Field | Typical error | How to avoid it |
|---|---|---|
| Document number | Spaces, hyphens or the wrong check letter in a DNI or NIE | Normalise the text and compute the letter before accepting the entry |
| Support number | Confusing it with the document number | Show an image of the document marking where each number is |
| Second surname | Foreign guests who do not have one and type a full stop or repeat the first | Let them leave it empty explicitly, with a checkbox |
| Date of birth | Day and month swapped in other countries' formats | Use a date picker, not a free text field |
| Nationality | Country names typed by hand | Offer a closed list of countries with their code |
| Phone | No international prefix | Ask for the prefix in a separate field |

None of these controls is a legal rule in itself. They are the difference between a record accepted first time and one that comes back when the guest no longer answers.

Payment lives in another system

The half of the record most often forgotten is the transaction. Identity and contact come from a guest-facing form; payment type, method, holder, card expiry and payment date sit in your gateway or in the channel's payout report.

Bookings paid by a company need separate care. The payer and the guest are different people, and a data schema that assumes they are the same loses the real holder of the payment method without warning.

Join both blocks through the booking identifier before reporting anything. Any record missing the payment part is incomplete even if the identity is perfect.

Deadline: when the 24 hours start

Article 6.3 says the information must be reported immediately and, in any case, within no more than 24 hours from the booking or the signing of the contract (or its cancellation) and from the start of the contracted services.

Look at the structure. There are two starting points, not a single clock:

1. The booking or the signing of the contract, and also its cancellation.
2. The start of the contracted services, that is, the arrival.

So a process that only acts at check-in is late for the first of the two reports. And a process that only acts at booking falls short on the second, because each traveller's data is not known until they arrive.

Same-day bookings compress everything

Picture a booking made at 21:00 for an arrival at 23:00. Collection, validation and submission have to fit into a couple of hours, at night, with nobody watching. A batch process that runs once a day does not survive that case.

The only setup that holds is the one that starts at booking confirmation: the check-in link goes out with the confirmation and submission is triggered by events, not by a schedule. If your flow depends on the guest filling in a form after walking through the door, every late arrival is an incident waiting to be counted.

Cancellations count too

Cancellation appears in the same article. An integration that only listens to new bookings leaves cancellations unreported. Subscribe to the channel's cancellation and modification events as well. The same goes for a booking that changes its dates or its number of guests: the record you reported no longer describes the real stay.

How to design guest register automation

The pattern that works is a chain of events: each step fires when the previous one finishes, with no scheduled jobs in between.

1. Receive the confirmed-booking webhook and create the stay record with its identifier.
2. Send the lead guest a check-in link specific to that booking, with one entry per occupant.
3. Validate each entry while the guest fills it in: document format and check digit, dates, required fields and the relationship when there are minors.
4. Join the entry with the payment data of the same booking.
5. Report the data and store the full response with its timestamp.
6. Issue the lock code only when the report has been accepted.
7. Listen for cancellations and modifications and report again when the data changes.

Why the access code comes last

Smart lock integrations usually issue a temporary code on the day of arrival. Move that trigger so it depends on the acknowledgement and not on the calendar. The compliance step then stops being something someone has to remember: without an accepted report there is no code. Instead of an unregistered guest inside, you get an alert on the dashboard.

Any lock with an API that can create and revoke codes on demand will do. The order of the steps matters more than the brand. In the features we are building at Klimpy we describe how we approach this same order.

What to ask your PMS or channel manager

The whole chain depends on your booking system notifying you in time. Before you choose or renew a provider, ask in writing:

• Which events it sends by webhook: new booking, modification, cancellation and a change in the number of guests.
• How late those events arrive and whether they are retried when your server does not respond.
• Which guest data the notice includes and which you have to ask for separately.
• Where the payment data lives and whether you can read it by API with the same booking identifier.
• How each property is identified, so stays from different flats are not mixed.

Vague answers here turn into incomplete records later. Ask for real examples of each event's content, not just the sales documentation.

What to keep from each stay

For each stay keep the content sent, the response received, the time of both and who or which process triggered the submission. With that, an inspection is answered with a query to your database. Also keep the earlier versions when a guest corrects a field, so you can explain what changed and when.

What to do when a submission fails

Failures come in several kinds, and treating them the same is the fastest way to run out of time.

| Failure | Example | What to do |
|---|---|---|
| Transport | Timeout, server error, dropped connection | Retry with growing waits until you get a response; if the time limit is near, alert a person |
| Validation | Malformed document number, unknown country code, empty surname | Do not retry: fix the data at the source, ideally while the guest is still in the form |
| Incomplete data | A companion's entry or the payment holder is missing | Block the submission, ask for the missing data and leave the stay flagged in the queue |
| No acknowledgement | The submission went out but no response was stored | Treat it as unreported until you have the response |

A validation rejection retried in a loop is the worst case: the queue looks busy, the time limit runs out and the stay ends up unreported. Tell the two kinds of error apart from day one.

Validate before transmitting

At the moment of collection, with the guest still there, check the document format and the DNI or NIE check letter. Check the country codes and the required fields as well. An error found hours later has nobody left to fix it.

Offences and fines under LO 4/2015

The penalty regime for offences against RD 933/2021 is governed by chapter V of Ley Orgánica 4/2015; the decree sets no amounts (art. 8.1).

| Type | Conduct (art. 8 of RD 933/2021) | Fine (art. 39 of LO 4/2015) |
|---|---|---|
| Serious | Lacking the documentary records provided for in the decree and omitting the mandatory reports | From 601 to 30.000 euros |
| Minor | Irregularities or deficiencies in completing the records and making the mandatory reports after the set time limit | From 100 to 600 euros |

Read the table the other way round from how it is usually read. Reporting late is minor; not reporting is serious. A system that, when in doubt, would rather send late than never send is pointed the right way. A system that gets stuck waiting for perfect data ends up in the bottom row.

What the table does not say

The table gives ranges, not figures. We will not give you average fines or typical cases: there is no table in the BOE that lets you work out in advance where a specific penalty falls within each range.

Keeping the register for three years

The data in the electronic register must be kept for three years from the end of the service (art. 5.3). This archive is yours, not the copy left on the platform that receives the reports.

Some practical consequences:

• Keep the register in a system you control and can export.
• Count the deletion date from the end of the stay, not from the booking.
• Schedule deletion when that period ends, so you do not keep personal data longer than needed.
• Restrict access: these are identity documents and payment methods.

Checklist before listing a property

Go through this list with every new property, and again when you change channel or provider.

• ☐ The check-in link goes out with the booking confirmation, not with the arrival.
• ☐ The form asks for one entry per traveller.
• ☐ The form asks for the relationship when there is a minor.
• ☐ Payment data is joined to the stay through the booking identifier.
• ☐ Cancellations and modifications also trigger a report.
• ☐ Transport errors are retried and validation errors go to correction.
• ☐ Every response is stored with its time.
• ☐ The lock code depends on the acknowledgement, not on the calendar.
• ☐ The register is kept for three years from the end of the stay and then deleted.
• ☐ You have your own access to the whole history, even if you work with a third party.

Klimpy is in pre-launch; in the compliance section of the Klimpy website we explain how we are approaching this.