Hotel technology stack: how the core systems fit together

A hotel technology stack is the set of systems a hotel runs: the management system, channel manager, booking engine, outlet tills and fiscal devices, accounting, guest app, door-lock encoder and e-document integrator. It works when each fact, from availability to invoice, has exactly one owning system and every other system reads a copy.

A guest checks out at noon, the bill closes, and at 12:20 the restaurant till sends a minibar charge for a bill that no longer accepts charges. Nobody built that gap on purpose. It comes from two systems each believing they hold the same fact. This guide gives you a way to see your stack as a set of facts with owners, a table you can copy, the joins that usually break, the reporting layer every stack in Türkiye must feed, and a one-page map to draw before your next purchase.

What systems does a hotel technology stack actually contain?#

A working hotel runs eight kinds of system, and each one exists to hold or move a particular kind of fact. The names differ by vendor; the jobs do not.

The management system, usually called the PMS (property management system), is the record of reservations, rooms, guests, charges and the guest bill. AHLA/HTNG describes it as the primary interface for guests, reservations, folio and room data (opens in a new tab). Everything else in the stack either feeds it or reads from it. If you want a closer look at what this means in daily work, see hotel operating system vs PMS: what changes in daily work.

The channel manager holds availability and rates and sends copies to the sales channels. It distributes the rate; it does not have to own it. The booking engine is the booking flow on the hotel's own website. It asks the same availability question as the front desk and the channels.

Outlet tills record charges in the restaurant, bar and spa and pass them to the guest bill. The ÖKC (ödeme kaydedici cihaz, the fiscal till that prints the legally required receipt at the point of sale) is a separate device with its own legal job. Accounting holds the books and the fiscal document. Where a hotel's own systems are not sufficient, e-invoices travel through a special integrator authorised by the Revenue Administration.

The guest app and the door-lock encoder are readers. The app shows the bill and takes requests; the encoder writes key cards from the room assignment the management system already made. None of them should be creating facts of their own.

One vendor may sell several of these together. That reduces the number of joins between companies; it does not remove the need to decide which system owns which fact.

Which system should own which fact?#

Each fact needs one writer and any number of readers. The moment two systems can both change the same fact, the hotel has two truths and a person arbitrating between them at the worst possible hour.

Availability belongs to the management system: rooms, out-of-order blocks and allocations live there, and the channel manager and booking engine read and publish copies. Rate needs exactly one owner, chosen deliberately. If the channel manager owns it, the front desk must quote from that copy, not from a printed rate sheet. The folio belongs to the management system; outlet tills post charges into it and never keep a parallel bill of their own.

Guest identity lives in the registration record taken at check-in. The identity notification and the daily customer list read from it; they do not maintain their own version. The invoice belongs to the accounting and e-document side. The management system holds the charge and the payment; it is not the authority on the invoice number. Room status has one owner, usually housekeeping's board inside the management system, with the front desk reading the same screen.

The cost of two owners is not technical. It is a night receptionist deciding which screen to believe while a guest waits.

How do hotel systems talk, and why do the copies drift?#

Systems talk in two ways: one asks another for the current value, or the owner tells the others when something changes. Most drift comes from the second kind failing quietly.

Asking is simple and always slightly stale. The copy is correct at the moment of the question and wrong a minute later. Being told is the publish-and-subscribe pattern: HTNG's Event Notification Specification (version 3.0, 24 April 2015) (opens in a new tab) describes a system subscribing to the events it needs, such as guest check-in, guest check-out or a room going out of service, with the source system notifying it when they happen.

Being told fails silently. If the listener is down, the sender has already moved on and no one notices until a guest does. Drift has ordinary causes: no event defined for a particular change, a failed retry, a person editing the copy by hand, a date boundary, or a re-keyed charge.

AHLA/HTNG notes that hotel integrations are generally lengthy and complex, especially with the management system. Plan for that, rather than assuming a connection is a one-week job. For the vocabulary vendors will use in those conversations, see hotel PMS integrations explained: APIs in plain words.

The practical rule after any change to a fact: name the copies that must update, and the person who checks that they did.

Where do the joins usually break?#

Joins break at the edges of a business event: a bill closing, a shift changing, a month ending. Each break has a cheap check that catches it before a guest or an accountant does.

For example, a minibar charge posted after checkout. The bill is closed, so the charge lands in a suspense account or is re-keyed. Check whether the till refuses to post to a closed bill, and who is called when it does. For example, room status differing between housekeeping and the desk: one screen says clean, the other says dirty. Check which screen is authoritative and how quickly the other refreshes.

For example, the guest bill and the fiscal document disagreeing by a discount line or a local tax. Check by reconciling one day's documents against the system's day-end report each month. For example, a rate changed in one place only, so a walk-in is quoted a price the channels would not accept.

For example, a guest name spelled three ways across registration, folio and invoice. The daily customer list must show name, surname, room number and room rate, so a spelling difference becomes a legal record difference. For example, a room taken out of service for maintenance that stays on sale because no event told the channel manager.

Every break has an owner. If nobody's name is next to the join, the join is nobody's job.

What must a hotel's stack report in Türkiye, and to whom?#

In Türkiye every stay involves a payment, a fiscal document, a guest identity notification and personal data, so the stack feeds legal reporting as well as operations. Confirm dates, amounts and your own case with an accountant or legal adviser.

Guest identity and personal data#

The Identity Notification Law (Law No. 1774, consolidated text) (opens in a new tab) requires the responsible operators of hotels, motels, pensions, holiday villages and similar lodging places to keep identity and arrival-departure records of every guest, Turkish or foreign, day by day, to keep those records on computer, and to report them instantly to the general law enforcement by connecting to its computer terminals. The law sets administrative fines for failures; confirm amounts with an adviser.

On personal data, the KVKK data security guide (KVKK Yayınları No. 72, April 2025) (opens in a new tab) asks data controllers to assess whether they still need the data they hold, to keep rarely accessed archive data in more secure environments, to destroy data no longer needed under their retention and destruction policy, and to consider security requirements when procuring or developing new systems, including checks that inputs are correct. That last point belongs in your stack map: a system that accepts a mistyped identity number passes the error into every legal record downstream.

Money: e-documents and fiscal tills#

An e-Arşiv invoice is created electronically and delivered to the buyer on paper or electronically, as the buyer asks; businesses enrolled in e-Arşiv issue it to buyers not registered for e-Fatura, under Tax Procedure Law General Communiqué No. 509, as the Revenue Administration explains (opens in a new tab). Where the hotel's own systems are not sufficient, e-invoices are sent and received through a special integrator that has completed the Revenue Administration's tests and holds its permission (opens in a new tab). Having a person review an e-invoice before it is sent is good practice.

At the point of sale, Law No. 3100 (opens in a new tab) requires first- and second-class merchants selling goods or services to final consumers to use a payment recording device that issues a receipt for every sale and a daily closing receipt, with a fiscal memory protected against tampering. Which hotel outlets need one is a question for the hotel's accountant.

Records and the central tourism database#

The Tax Procedure Law (Law No. 213, Articles 240 and 253) (opens in a new tab) requires lodging places to prepare daily customer lists with consecutive serial and sequence numbers, following their room and bed plans and showing each guest's name and surname with the room number and room rate, and to keep books and documents for five years from the start of the calendar year after the year they relate to.

Separately, Ministry circular 2026/1, dated 16.04.2026, obliges accommodation facilities and their software providers to send data to the central tourism database through a web-service connection, daily if the transfer is automatic and monthly by the 15th if it is manual, with a first deadline of 15.05.2026, as reported by alomaliye.com (6 May 2026) and Dünya (18 May 2026). Check the circular itself and your software provider for scope and any sanction.

How do you draw your own system map?#

Draw it on one page: systems down the side, facts across the top, a name in every cell that needs one. The exercise takes an afternoon and settles arguments that otherwise return every season.

Start from the facts, not the vendors. Availability, rate, folio, guest identity, invoice, room status and payment are enough for most hotels. Include the systems people forget: the accountant's program, the outlet tills, the fiscal device, the integrator that sends e-documents.

Mark each join as automatic or manual. A manual join is a person re-keying, and it needs a named owner and working hours. Mark which copies feed a legal report, so a change to a system is checked against the identity notification, the daily list, the fiscal document and the central database transfer.

Test one join a month with a known change, then check every copy. A charge, a rate change or a room block is enough. Keep the map with the vendor contracts and update it whenever a system is replaced. When a replacement is on the table, the map is also the input for PMS data migration: what to move, check and leave behind.

What should you decide before buying anything new?#

Decide ownership and exit before you compare features. Features are visible in a demo; ownership, export and night-time responsibility are not.

Name the owner of availability and rate first. A new system that also writes them creates a second truth unless the old writer is switched off. Ask whether the new system writes a fact or only reads it. A reader is easy to add; a second writer is a permanent reconciliation job.

Ask for the export: reservations, guest records and folio history in a usable file, on request, without a project. Ask which legal reports the new system feeds and which stay with the accountant, and who confirms the central tourism database transfer. Ask who is called when a join fails at 23:00, and whether that is the vendor, the integrator or your own team.

Treat AI assistants as one more reader of the same facts. The question is not how clever the assistant is, but whether each fact has one owner and a defined way to be read. Write the answers into the contract, not into the meeting notes. For the full set of questions to put to vendors, see how to choose a hotel PMS in Türkiye: questions to ask vendors.

What to do next#

Draw the one-page map this week: eight systems, seven facts, one owner per fact, a name on every join. Then use it as the first document in any purchase conversation, because a stack is judged by how few facts it holds twice, not by how many products it contains.