Electronic invoicing from the hotel restaurant: what data needs to travel from the ticket

The same dish, served at the same table, can end up invoiced three different ways depending on who ordered it: a walk-in diner, a guest who charged it to their room, or a company with a corporate agreement. The kitchen ticket looks identical, but the fiscal path it follows afterward is completely different, and mixing it up is one of the most common mistakes in a hotel restaurant.

Why a hotel restaurant invoices differently from a standalone one

A standalone restaurant, with no hotel attached, almost always invoices the diner sitting at the table directly. A hotel restaurant has an extra layer: the charge can end up on the guest folio, and that folio does not close until check out, sometimes days after the dish was served. The invoice cannot depend on when the dish was served, but on when the folio closes and in whose name.

That means the restaurant system needs to capture, from the moment the ticket is created, information a restaurant with no hotel could wait until the end to ask for: whether the charge goes to the room (Room charge), whether the guest is traveling for a company with an agreement (Master accounts and agreements), and which fiscal data applies to each.

The three paths of the same ticket

Before getting into specific data, it helps to be clear on the full route each type of charge follows.

Walk-in diner data

This is the simplest case, and the one closest to any standalone restaurant. The diner asks for the check, decides whether they want an invoice, and gives their fiscal details right then: name or business name, tax id, fiscal address and the intended use of the invoice. The system needs to capture this before closing the ticket, not after, because once the shift closes, recovering that information depends on someone’s memory.

• Name or business name exactly as it appears on their tax id, without abbreviating.
• Full tax id, verified before issuing, because a mistake here forces a cancellation and reissue.
• Fiscal address, which in several countries determines applicable taxes.
• Use or purpose of the invoice, when the local fiscal framework requires it.

Data for a guest charging to the room

When the charge posts to the folio, the fiscal data is not always in the server’s hands at the table: the guest may have already given it at the front desk at check in, or may not give it until check out. What matters is that the system links the ticket to the correct folio from the very first moment, so check out does not require rebuilding, table by table, who ate what.

• The folio must carry every ticket charged during the stay, with date, revenue center and amount for each one.
• If the guest wants a separate invoice for food and beverage, apart from the lodging invoice, the system must generate both without duplicating or dropping line items.
• If the guest does not request an invoice during the stay and asks for it later, the system needs to keep the detail long enough to issue it, not just a generic total.

Data for a company with a corporate agreement

This is the trickiest case, because it involves a third party who is neither at the table nor at the hotel: the company that signed the agreement. How to write that agreement so it does not cause disputes is covered in this guide (How to write a hotel corporate agreement that does not end in a dispute). On the fiscal side, what needs to travel from the ticket depends on what the agreement spells out.

1. Confirm, from the moment the corporate traveler’s folio (/viajero-corporativo) opens, who the invoice will be issued to: the guest, the company, or split between the two according to the agreement’s cap.
2. If the company only covers up to a set amount and the guest goes over it, the system must be able to split a single folio into two invoices: one to the company for the cap, another to the guest for the excess.
3. Record the company’s full fiscal data when the agreement is signed, not every time a traveler from that company checks in, so nobody depends on each guest bringing it along.
4. If the agreement calls for a single consolidated invoice per period instead of one per stay, the system must be able to group several folios from different guests of the same company into one document, without losing track of which guest generated which charge.

What happens when fiscal data arrives late or changes

In practice, fiscal data is almost never complete the first time. The guest gives a misspelled name, the company changes its tax id between one stay and the next, or someone asks for the invoice three weeks after leaving. The restaurant system has to hold up under this reality without forcing anyone to recapture everything from scratch.

• Keep the consumption detail, not just the total, for as long as the fiscal law requires in order to invoice later.
• Allow a fiscal detail to be corrected and reissued without manually rebuilding what was consumed and when.
• Keep a record of who requested each correction and when, useful if the controller needs to explain a discrepancy in an audit.

An illustrative example with numbers

The figures below are made up to show the calculation; they are not data from any hotel or company. Picture a corporate traveler whose company covers up to 500 per night in food and beverage, and who consumes 680 one night between dinner and the minibar.

Without a system that links the ticket to the agreement’s cap from the moment the charge is generated, this 500 and 180 split gets done by hand at check out, going through ticket after ticket while the guest waits at the desk. With the data traveling from the ticket, check out only confirms a calculation the system already made.

Fiscal mistakes that keep repeating in hotel restaurants

• Invoicing all consumption to the company even when a cap was agreed, because nobody configured the split in the system.
• Losing the consumption detail when the invoice is requested weeks later, and ending up invoicing only a total with no breakdown.
• Using a company’s fiscal data from its last stay without confirming it is still valid, and finding out only when the invoice bounces.
• Not separating the lodging invoice from the food and beverage invoice when the guest asks for it, mixing two documents that are fiscally different.

What to do this week

1. Check whether your system captures the diner’s fiscal data before closing the ticket, not after.
2. Confirm every guest folio keeps the consumption detail, not just a total, until it is invoiced.
3. Check how a split invoice is handled today when the corporate agreement has a cap and the guest goes over it.
4. Review the fiscal data on file for your companies with agreements and confirm it is still valid.
5. Ask how easy it is to correct and reissue an invoice when the data came in wrong the first time.

Inn Restaurant links every ticket to its folio and to the corporate agreement that applies, so the invoice comes out with the right data without rebuilding anything by hand. If you want to see how a folio splits between a company and a guest, the fifteen minute demo (contact) shows it with a real case from your operation.