What Short-Term Rental Software Must Handle: VUT Licenses and Modelo 179 in Spain

Most short-term rental software is built around a simple assumption: list a property, take a booking, collect a fee. That model works fine in markets with light regulation. It falls apart in Spain, where Andalusia layers a regional tourist-rental license on top of national reporting rules, and where, as of Royal Decree 1312/2024, a second national registration number sits on top of the regional one. None of this is an edge case you patch in after launch. It changes what a property record has to contain, what has to be true before a listing can go live, and who the software is actually generating reports for.

The VUT number is a dependency, not a form field

A vivienda de uso turistico (VUT) registration number in Andalusia isn't just a reference you store next to the property address. The regulation requires it to be displayed on the listing and on any advertising of the property, and advertising without one is one of the more commonly enforced breaches. Legal advisors who work with VUT owners describe penalty ranges running from roughly €600 up to €30,000 depending on severity and repetition. That changes a build decision: the license number shouldn't be a free-text field an owner fills in once. It needs a status (active, suspended, expired, pending), a validity window, and a rule that blocks a listing from going public, or forces it offline, when that status isn't valid. A property manager finding out their license lapsed six months ago because a listing was never gated on it is a problem software should have prevented, not flagged after the fact.

Who actually files Modelo 179, and what it needs from your booking data

Modelo 179 is a quarterly informative declaration to the Agencia Tributaria (AEAT) covering the cesión de viviendas con fines turisticos, the handover of housing for tourist purposes. The obligation sits with the intermediary, not necessarily the owner, which means platforms, letting agencies, and property management companies are the ones AEAT expects to file it. If a studio builds a reservation system for a management company handling dozens of owners' properties, that company is the filer, and the software is effectively generating a tax document, not just a booking confirmation. The report needs, per property per quarter, the cadastral reference, the dates of each stay, the number of days, the amount paid, and identification of who paid it. That means the booking record at the point of creation needs to capture fields that a generic reservations table often doesn't: cadastral reference tied to the specific unit, guest identification sufficient for tax purposes, and a payment amount attributable to the stay rather than a blended total across fees and add-ons.

A second number: the national registry layered on top

Royal Decree 1312/2024 introduced a national short-term rental register (sometimes referred to as NRUA) requiring a unique registration number per property, separate from the regional VUT number, with the research around it pointing to mandatory enforcement from mid-2025. For software, the practical effect is that a single property can now hold two distinct government-issued identifiers, from two different authorities, with two different renewal cycles and two different sets of consequences for lapsing. A data model built around one license field, which is still common in off-the-shelf rental tools, simply has nowhere to put the second number without a schema change, and schema changes made under deadline pressure are where reporting gaps tend to start.

What this actually looks like in the data model

In practice, a property record for a Costa del Sol rental needs at minimum: a regional license identifier with status and validity dates, a national registration identifier with its own status, a cadastral reference, the owner entity, and the intermediary entity responsible for Modelo 179 (which may or may not be the same as the owner). The booking table needs stay start and end dates, nights, the amount attributable to the stay for tax purposes, and the guest identification used for the filing. On top of that sits a scheduled job: at the close of each quarter, aggregate closed stays per property, group by the filing entity, and produce an export in the layout AEAT expects. None of that is exotic engineering. It's ordinary data modeling, done correctly because someone scoped it against the actual regulation instead of against a features list copied from a generic booking app.

Why this gets caught at scoping, not after an audit

The expensive version of this problem shows up a year or two in, when a management company gets asked for a Modelo 179 history and discovers the first year of bookings never captured cadastral references or stay-level payment breakdowns. That data can't be reliably reconstructed after the fact; it has to exist at the point of booking. This is the same pattern we've seen with other Spanish regulatory requirements that impose hard technical constraints on a build, not just paperwork around it, as described in our piece on Veri*Factu compliant builds. The fix in both cases is the same: treat the regulation as part of the requirements document from the start, not as a report screen added after the system is already live.

If you manage multiple owners' properties, not just your own

Agencies and management companies carrying Modelo 179 liability across a portfolio have a slightly different problem than a single owner does: the software has to know which entity is the filer for each property, which can vary unit by unit if ownership structures are mixed. This overlaps with work we've described for agencies running cross-border real estate CRMs on the Costa del Sol, where owner identity, payment routing, and jurisdiction already have to be modeled carefully for reasons unrelated to rentals. Portfolio operators who also acquire property on an ongoing basis sometimes pair this kind of system with Property Monitor to track new listings feeding the portfolio, though that's a separate concern from the compliance layer itself.

Starting the conversation

Building rental or property management software for this region is less about picking the right booking engine and more about getting the regulatory logic right before a single line of code is written. That's the kind of scoping work we do through our custom software service, and it's also where being physically close to the regulation and the people enforcing it tends to matter, a point we go into more in why regional proximity changes how a software project runs.