Legal and compliance
Understand the NRUA/XBRL generation boundary
The batch action exists, but it is not yet an approved self-service journey for generating a filing.
- I own or administer an agency
- Agency
On this page
Holidario shows a Generate NRUA XBRL batch action under PMS > Operations. After operations are selected, that action can queue generation for the previous year. It is therefore inaccurate to say that generation has no user-facing surface.
However, that surface is not yet an approved self-service journey: it is exposed through the general operation-read permission rather than specific generation authority; it provides no scope preview or explicit period confirmation; and its immediate message confirms a queue, not the file or its contents. Until those boundaries are resolved and accepted, do not run the action merely because it is visible. Use it only within the procedure agreed with the agency's compliance owner and Holidario.
The dashboard and operation screen are monitoring surfaces. Retry appears only to an account authorized to update filings, but its presence does not prove that the cause is resolved or that using it is safe. Visibility of an action also does not authorize a user to generate, invalidate, reset, or delete a record themselves.
What the organization must decide#
Before requesting preparation, the responsible person must confirm with their professional or administrative source:
- which operations must be included;
- which period applies;
- which activity and reservations belong in the report;
- who is authorized to present it;
- what evidence the organization will retain.
Holidario does not turn a reservation selection into legal advice or independently determine a filing obligation.
Data and states that determine the result#
- Owner Authorize scope and period Confirm operations, completed year, included activity, obligation, and who may file.
- Data Validate operation, NRA, and CRU The operation must be eligible and authorized; NRA must be valid before progressing to the Registry.
- Generation Create or reuse XBRL “Generation queued” proves only the batch, not each operation’s result or a generated file.
- Filing Process intermediate stages Generated, filing created, files signed, and sent are distinct evidence.
- Result Confirm acceptance Accepted and synchronized documents are a later result; a download is not filing evidence.
Batch generation and later submission processing do not perform the same checks. The complete journey depends on:
- an active short-term rental operation that belongs to the team and is authorized for the person;
- a stored NRA and the correct CRU/IDUFIR: a disabled, non-STR, or incomplete operation can be skipped by the batch;
- a completed report year; the visible action defaults to the previous year;
- sufficiently complete relationships and activity data to build the report;
- an NRA with Valid validation status before processing toward Sede Registradores can continue;
- prepared credentials for the later filing stages;
- a period compatible with the configured processing rule.
The Generation queued notice proves only that a batch was created. It does not confirm that every operation contributed data or that a file was generated. Some queued views also group Provisional NRAs with valid ones. Appearing there does not prove the processor can advance: the submission step requires Valid status.
Current product timing rule#
Automatic annual-deposit processing is limited in the current code to February for the previous report year. This is a Holidario operating rule, not a statement of regulation.
Outside that window, a report can exist without appearing under Queued or progressing. Do not change the year to force visibility; check the operation and escalate.
Information for authorizing or requesting assisted generation#
Provide the following without attaching credentials:
- team;
- operation and property;
- report year;
- visible NRA, state, and validation date;
- confirmed CRU/IDUFIR;
- person who approved the scope;
- confirmation that Sede Registradores is prepared;
- internal target date and follow-up owner.
Do not include passwords, keys, certificate copies, full traveller details, or downloaded notification files in a normal ticket.
Distinct evidence that must not be confused#
- XBRL available: the file was generated.
- Generated: a prepared record exists, but no confirmed presentation.
- Presentation created: an intermediate stage completed.
- Files signed: another intermediate stage completed.
- Submitted: the system recorded sending.
- Accepted: a later result is marked accepted.
Downloading the XBRL is not proof of filing. A presentation identifier also does not replace registry documents and synchronized status.
If a filing already exists#
Do not request another for the same period without comparing operation, CRU, year, and state. Normal generation can reuse an existing file in some states. Do not use Regenerate NRUA XBRL (Subsanar), retry, reset, or delete as a way to try again: regeneration can remove the existing file and return the record to draft before creating another batch.
Continue with Monitor NRUA/XBRL status and escalate any correction with the existing record identifier.
Current boundary#
Initial XBRL creation remains an assisted journey despite the batch action. To become self-service it needs specific authority, scope and period preview, confirmation, per-operation results, understandable reuse or duplicate detection, and verifiable recovery. Documentation does not turn a read permission or a queued notice into authorization or success.