Invoices (CFDI)
Each hotel stamps with its own seal, by hand or automatically. Cancelling leaves a receipt, and no invoice is ever overwritten.
What it solves
Lodging is always invoiced by the hotel, because the hotel provides the service. That means each hotel must stamp with its own seal, not the platform's — and the system has to get it right first time, because a badly issued invoice can only be fixed by cancelling it with the tax authority.
You notice it in things like these
- Invoicing a booking means retyping the same data into another program.
- The seal expires without warning and one Monday the hotel cannot issue anything.
- A cancelled invoice cannot be reissued and you have to call support.
How it works
Each hotel, with its own seal
The certificate, key and password are uploaded once from the tax profile. They are not stored: they go to the authorised provider and only the record that they exist stays in the database. The file is checked before sending, because the two mistakes everyone makes are visible in it: uploading the e-signature instead of the seal, and uploading one from a different tax ID.
And with a warning before it expires
A seal lasts four years and expires without warning anyone. Its validity is stored and a warning is sent a month ahead, because the day it expires the hotel can no longer issue and the provider's error says something else entirely: that the issuer does not exist.
Automatic, or with your approval
The hotel chooses whether the guest's invoice is stamped automatically — the default — or arrives as a request with all the data to review. A request can be left before it can even be issued, and the system stamps it or notifies as soon as it can, exactly once. If the provider rejects an automatic one it is not lost: it stays with the hotel, along with what the provider said.
Each booking's invoice card
It shows the issued invoice with its PDF and XML, or the request with its data and "Issue in one click", "Fix data" and "Reject" with a reason — which reaches the guest. It can be issued to a named recipient or to the general public with the hotel's postcode.
Cancelling adds a row, never erases
It is validated before calling the provider — the replacement reason requires the folio that replaces it — and whatever the authority answers is recorded as a new row, never as an edit on the invoice. "In progress" and "rejected" are real states, and a rejected one can be requested again. A cancelled booking can be invoiced again.
One invoice per booking, whatever happens
Everything goes through the same per-booking idempotency key: a double click, the automatic process and the hotel all at once do not produce two invoices. And the invoice is emailed to the guest with the PDF and XML attached, in their language.
Where it lives in the panel
- Reservations & stays
- Reservations
- Invoices
What it needs first
The hotel's tax profile validated: the entity type comes from the tax ID and the regime has to match it.
The hotel's digital seal uploaded. Without it nothing can be issued, and the provider's error does not say so.
What it does not do yet
The limits, told by us
- A cancellation "in progress" is not yet followed automatically until the recipient accepts it: you have to check back.
- The invoice stamped by the automatic process is not emailed; the guest downloads it from the public invoicing page.
Carry on here
Shall we walk through it with your hotel on screen?
Half an hour, your rooms and your rates, and whatever questions you have. No commitment and no card.