SES.HOSPEDAJES Error Codes: Rejections and Fixes

You submit a guest communication to SES.HOSPEDAJES and the interface says “sent”. Hours later, the guest still isn’t registered. Or the platform hands you a bare five-digit number with no explanation in sight.

The problem is almost never that you made a serious mistake. But it isn’t always the same kind of mistake either: sometimes it’s one space too many when copying a code or a phone prefix written with +, and sometimes it’s a permission nobody ever switched on for your account. What separates them is when SES tells you. One of the two rejections arrives instantly and makes noise; the other says nothing at all, and it’s the one that costs reports to anyone who treats the job as finished the moment the confirmation appears on screen.

(If the trouble is that the portal won’t load or won’t let you in, not a data rejection, that’s a different problem: see SES.HOSPEDAJES not working. And to understand the platform end to end, there’s the complete SES.HOSPEDAJES guide.)

The two moments SES.HOSPEDAJES can reject you

First moment: rejection on submission

This rejection happens within seconds, before the Ministry has even looked at the guest’s data. SES returns a numeric error code immediately on submission. If you see one of these, the entire submission was rejected and no guest was registered. The second column reproduces the Ministry’s own wording, in Spanish as the service returns it: the full catalogue of codes sits in section 5 of the web service specification, which you download from inside the portal¹.

Code 0 is the one the Ministry describes as “Ok”¹: the submission was accepted for review. It does not mean the data is correct: you’ll find that out at the second moment.

Second moment: silent rejection hours later

This is the rejection that catches most operators off guard. When the first moment raises no error, the Ministry reviews each guest’s data separately. That process can take minutes or several hours. To know the real outcome, you have to check the submission status later.

Each guest can come back as successfully registered, or as rejected with a message describing which piece of data was wrong. The submission as a whole can show “accepted” even if several individual guests were rejected.

This means “sent” is not the same as “registered”. A submission accepted at the first moment can have guests rejected at the second, with nothing on the submission screen indicating this.

SES.HOSPEDAJES silent rejections, at a glance

It is worth separating what the Ministry documents from what it doesn’t. The field formats are written down: the Instrucciones para el alta masiva de comunicaciones, which the platform serves from its own site, carry the field-by-field table with each field’s type, length and when it is mandatory². You do have to go to the portal for them, because the Ministry’s sede carries only the Guía visual and the FAQ³. What the Ministry publishes nowhere are the messages it uses to reject an individual guest at this second moment: they arrive as text inside the response, or as an email to the property’s owner. So the table below comes from no document at all: it is what the platform returns on the submissions we make, ordered by frequency.

Each silent rejection, and how to fix it

Invalid support number

One of the most common reasons for rejection.

The support number is on the front of the DNI, the photo side. It sits in the right-hand data block and is repeated in laser engraving in the transparent window at the top right. The label and its exact position change with the document version, and all three are covered in where the DNI support number is. It is not on the back: that face carries the address, place of birth, parents’ names and the machine-readable strip. Annex I asks for it as a field of its own, separate from the document number⁴, and the Ministry devotes an FAQ entry to where to find it⁵.

Don’t confuse it with the CAN, which is also on the front but in the bottom right corner and exists for NFC reading, nor with the DNI number itself. That one you recognise by its format, not by its place: eight digits and a control letter. Its position moves with the document version (bottom left on the 3.0 and on the 2006-2015 DNIe; on the 4.0 it sits with the rest of the personal data), and a support number never has that shape: it is three letters and six digits.

What usually goes wrong: hunting for it on the back, confusing it with the document’s serial number, or typing it with spaces or hyphens.

The Ministry treats it as a field of its own, soporteDocumento, nine characters long and mandatory whenever the document is a NIF or a NIE². Nine characters is exactly what the three letters and six digits take up.

Second surname required

Annex I asks for the first name, the first surname and the second surname as three separate fields⁴. The platform goes further and makes it conditional: the field table marks apellido2 as mandatory when the document type is NIF², and the web service specification also records a validation change that extended the requirement to the NIE¹. It makes no difference that the guest habitually uses only one surname: if it is missing, the communication will be rejected with the message “Segundo apellido obligatorio”.

Document type doesn’t match nationality

SES accepts exactly four document types (NIF, NIE, PAS and OTRO) and requires the number submitted to correspond to the declared type, with a valid format in the case of a NIF or a NIE². Submitting a DNI for a foreign national, or a foreign passport for a Spanish resident, triggers this error.

The practical rule is the Ministry’s own, from its FAQ: the DNI for Spanish citizens, a national identity document for EU citizens, and a passport for every other foreign national⁵.

Incorrect phone number format

Here it pays to be precise about what the Ministry requires and what we have merely observed. All that is documented is that the phone is a 20-character field and that you must fill in at least one of the three: telefono, telefono2 or correo². There is no written rule about the prefix, and the sample request in the web service specification carries a bare national number, with no prefix at all¹.

In our submissions, by contrast, the + symbol produces rejections that disappear when the prefix is written with zeros. So this is the practical recommendation, not the rule:

0034612345678   ✓
+34612345678    ✗

Nationality in the wrong format

This one is written down: nationality is encoded per the ISO 3166-1 Alpha-3 standard, in a three-character field². Three letters, then, not two. The most common mistakes:

Establishment code not found

The property’s establishment code doesn’t exist in SES under that lessor account. Common causes:

• Copied with errors from the portal
• Property registered recently and not yet active
• Property linked to a different lessor account

Verify it in the property record inside the SES.HOSPEDAJES portal.

Reservation in “Incomplete” state

Happens when a mandatory field is missing or blank. SES marks the reservation as “Incomplete” and never even processes the associated guests. The typical case is a vacation rental missing one of the lodging-reservation fields (contract type, number of beds, payment data).

Go through the form field by field. And if the submission came from another tool or a booking file, make sure that tool fills in everything SES expects.

Invalid postal code

Here the Ministry fixes no format: the postal code is a mandatory field of up to 20 characters, with no list of values attached. That is a conspicuous exception inside the same table, because the municipality is encoded with the INE’s five digits and the country with ISO 3166-1 Alpha-3². The 20 characters are there to accommodate foreign postal codes, not because anything goes.

In practice, the rejections we see are always the same ones: four digits instead of five on a Spanish address, a foreign postal code entered as if it were Spanish, or a code that doesn’t belong to the establishment’s province.

Missing payment information

Applies to the reserva de hospedaje (lodging booking) for vacation rentals. Under “Datos del pago”, Annex I of RD 933/2021 asks for the type of means (cash, credit card, payment platform, bank transfer), identification of the means (card type and number, account IBAN, mobile payment solution or others), the holder of the means of payment, the card’s expiry date and the date of payment⁴. The CVV does not appear on that list and is never reported.

Inconsistent dates

Cases we’ve seen: check-out before check-in, dates in MM/DD/YYYY format when DD/MM/YYYY is expected, zero-night stays, time-zone mismatch between PMS and SES.

Code 10121: fix the data and resubmit

Error 10121 (Validation error) means the communication fails the system’s validation: some field doesn’t have the expected format or value, so it is not stored. It usually comes with more specific codes that pinpoint the exact data, and these two carry the field’s name embedded in the message itself¹:

• 10130: “Valor incorrecto para el campo: $NOMBRE_CAMPO” (invalid value for the field).
• 10131: “Es obligatorio indicar un valor en el campo: $NOMBRE_CAMPO” (a value is required in the field).

Where the Ministry writes $NOMBRE_CAMPO you will see the real field name, so the response is telling you exactly what to fix. Fix that field and resubmit. If the message arrives without a field name, check the usual suspects: support number, date format, and postal code.

How to tell if the failure came on submission or hours later

How RegistroViajero catches the silent rejections

RegistroViajero handles both moments for you: it checks the submission status after each communication, spots which guests were rejected, and tells you the specific reason.

If you have questions about SES.HOSPEDAJES credentials, that article explains in detail the difference between portal credentials and web service credentials, and how to configure the lessor code correctly.

Prefer not to watch the codes by hand? See how RegistroViajero works.

The error codes and the per-field formats come from the Ministry’s own technical documentation. What is documented nowhere are the messages the platform uses to reject an individual guest in the later review: those come from the responses we receive on our own submissions and can change without notice. The underlying obligations come from Real Decreto 933/2021.

This article is for informational purposes and does not replace professional legal advice.