API and events: what your accountant should be able to read and write from your hotel restaurant system

Every month end, a hotel accountant runs the same ritual: ask the restaurant manager for the sales report, ask the cashier for the shift close, ask the front desk for the room charge report, and sit down to reconcile three files that almost never match exactly. The problem is not that the accountant works too little. The problem is that nobody gave them an orderly way to read the data directly from where it lives.

Why a PDF report is no longer enough

A month-end report is a snapshot taken once, of a moment that already passed. If the accountant needs to check something from two weeks ago, they have to ask for another report, wait for someone to generate it, and trust that nobody touched anything between the period close and the moment the file was produced. An accountant who works with real hotels needs something different: direct access to the data, at the moment they need it, without depending on someone else remembering to export a file for them.

That is what an API solves: an orderly gateway to the data of your hotel restaurant system, where the accountant, or the accounting software they use, can ask for exactly what they need, when they need it, without having to be handed a username and password from the server’s tablet or asking anyone to export a file.

What an API is and what events are, without jargon

An API is simply a set of well-defined doors for requesting or delivering information to a system, without going through the front door that servers and managers use. Each door has a clear purpose: one to look up the menu catalog, another to look up a day’s orders, another to look up shift closes. Whoever comes in through that door can only do what that door allows, nothing more.

An event is different from a report: instead of the accountant asking “what happened today?”, the system tells them the moment something relevant happens: a ticket closed, a room charge posted, a shift’s register closed. The accountant, or their software, gets that notice instantly and can process it right away, instead of waiting until the end of the day to find it all at once.

What your accountant should be able to READ

The list of what an accountant needs to read from a hotel restaurant system is shorter than it sounds, but each item matters for a specific accounting reason.

With these six sets of data available through the API the moment the accountant asks for them, closing the month stops being an investigation across loose files and becomes a direct query to the source of truth.

What your accountant should be able to WRITE, and why it is so little

This is where many hotels get it wrong when configuring access: they give the accountant or their software a wide-permission user “just in case”, and that “just in case” is exactly what a bad actor, inside or outside, would take advantage of if that access ever leaks. The right rule is different: accounting access almost never needs to write anything in the restaurant’s operating system.

The only thing an accountant might need to write, and only if your hotel decides so, is a specific accounting adjustment clearly flagged as such: for example, a note reclassifying a consumption between tax categories. Even there, that adjustment has to be logged in the same audit history as any other operation, with the name of who did it and why, never as a silent edit of a value that already existed.

• The accountant can read catalog, orders, shift closes and folios without restriction within their access.
• The accountant almost never needs to close a ticket, apply a discount or change a price: that is operations, not accounting.
• Any accounting adjustment that does require writing something must be logged with a name, a time and a reason.
• Accounting access is revoked immediately when the accountant or the firm handling the hotel’s books changes.

Access keys by property, not one door for everyone

If your hotel is part of a group with more than one property, or your accounting firm serves several hotels under different owners, the API access key should never be a single one that opens every property at once. Each property should have its own key, and that key should only grant access to that specific property’s data, no matter how many different keys the same person or software manages for different hotels.

This separation protects two things at once: if one property’s key leaks, the damage stays limited to that property, without automatically opening access to the rest. And if your accounting firm stops serving one of the group’s hotels, revoking that specific key does not affect access to the other properties it still serves.

How a new key is issued without exposing anything

1. The owner or general manager requests the key from the system’s administrative panel, never by email or message.
2. The key is generated with read-only permission over the data the accountant needs, per the agreed list.
3. The key is delivered directly to the accountant or configured into the accounting software, without going through a channel where someone else could see it.
4. Every use of the key is logged in the audit history, with what was queried and when.
5. If the hotel changes accountants, the previous key is revoked that same day, not “whenever someone remembers”.

Real-time events versus the end-of-day report

An accountant who only gets an end-of-day report finds problems late: an unauthorized discount, an odd pattern in one revenue center’s closes, a gap between what was charged and what posted to the folio. An accountant who receives real-time events, or who checks the API frequently through the day, can catch those same problems while the shift is still open, when it is still possible to ask someone what happened.

This does not mean the accountant has to stare at a screen all day. It means your hotel restaurant system has to be designed to notify, not only to report afterward, and that notice should arrive through the same orderly API channel, not through a phone call from the manager once something has already gone wrong.

An illustrative example of the time an integration saves

The figures below are made up to show the calculation; they do not describe any real property. Picture a hotel where, without direct API access, the accountant spends 5 hours a month requesting, receiving and reconciling PDF reports from three separate areas: restaurant, register and front desk.

In the example, the 1,600 monthly saving does not come from the accountant working fewer hours for the sake of it: it comes from no longer wasting time requesting, waiting for and comparing files that in theory should say the same thing. That time can go into something that actually adds value, like reviewing trends or preparing the filing with more lead time.

What to do this week

1. Ask your accountant how much time they spend each month requesting and reconciling separate reports from the restaurant, the register and the front desk.
2. Check with your vendor whether your system offers API access with keys separated by property, or only delivers manual reports.
3. Confirm what permissions the accounting user in your system currently has: if it can write something it should not, fix it.
4. If you run more than one property or work with an outside firm, verify each has its own access key.
5. Ask to see last month’s API access audit history, if your system has one available.

Inn Restaurant exposes catalog, orders, shift closes and folio charges through an API with keys separated by property, built so your accountant can query what they need without asking anyone for a report. You can see the detail on the developers page (Developers) or ask about your specific case in a 15-minute demo (contact).