Door locks and fiscal devices: what AI Otel’s operating system is designed to connect

Hardware integration is where a hotel management system (PMS) meets the physical building: key-card encoders from the major door-lock vendors, and ÖKC fiscal devices (the Turkish fiscal receipt device) outlet by outlet. Both are the parts a hotel feels first when something fails, because a guest is standing at the desk. AI Otel’s hotel operating system is designed for both connections, and both are Architected: designed, not built. No working lock or ÖKC integration is claimed today.

The demo runs perfectly. Then a guest arrives at 01:40, the encoder at the desk does not recognize the new reservation, and someone writes a key by hand while the queue grows. Hardware is where a hotel system is judged, on the first night, not in the sales meeting. After reading this article you will know how each connection works, what can go wrong, what AI Otel’s honest status is, and which questions to put to any vendor before you sign.

Why do hardware connections decide the first day of a hotel system?#

Because the first guest at the desk tests the two connections no demo can fake: the encoder that must produce a working key, and the fiscal device that must produce a legal receipt.

A system can hold perfect reservations and still fail at 01:40 if the card does not open the door. The guest judges the hotel by the door, not by the database behind it. Two hardware families sit on the boundary of the front desk: door locks, meaning an encoder at the desk and a lock on each door, and fiscal devices, meaning an ÖKC in each outlet that sells.

Both belong to other vendors, with their own firmware, generations and support contracts. The hotel system is one participant in the connection, never the owner of it. Hardware is also the slowest part of any rollout: it needs a model list, a site visit, a person at each desk and a test on real doors and real devices.

The commercial consequence is simple. A system that cannot drive your encoder becomes a second system you run beside the old one, and the staff pay for it twice. This is why the hardware question belongs in the evaluation, next to the rate manager and the reports, not in the week before go-live.

How does a PMS door lock integration actually work?#

In three parts: the encoder at the front desk writes the key card, the PMS tells the encoder which room and which dates, and the lock on the door is set up to accept only cards written for it.

The encoder is the card writer at the desk. The PMS sends it a command containing the room number, the arrival and departure dates, and usually an identifier for the guest or the card. The lock is a standalone device: it keeps its own clock and its own list of valid cards, and it does not ask the PMS each time a card is inserted. This is why date and time accuracy matters more than it looks.

Check-out is usually an expiry, not a deletion: the card stops working because its departure date has passed. A good connection also lets the desk cancel a card immediately when a guest reports it lost. Re-issuing a key is where most failures happen. A room move, an extended stay or a duplicate card must cancel the previous card; if the cancel step is skipped, the old card still opens the door.

Typical failure points are clock drift between lock and system, room moves done without re-encoding, locks that come back online after a battery change, and an encoder driver that was updated without telling anyone. What a hotel should be able to see afterwards: which cards were issued for a room, when, and by whom. Without that record, a disputed entry cannot be answered. For a fuller treatment of key cards and encoders, see the platform pages on the hotel operating system at ai-otel.com/platform/pms.

What the connection carries#

What is an ÖKC, and what does it have to do with the PMS?#

An ÖKC (ödeme kaydedici cihaz) is the Turkish fiscal receipt device, in practice the cash register in an outlet. Under Law No. 3100 (Resmî Gazete, 15 December 1984, No. 18606) (opens in a new tab), the receipt it issues documents a sale for which no invoice is required and takes the place of an invoice.

The law defines payment recording devices as devices such as electronic cash registers and electronic terminals, and gives their receipts the standing of an invoice where no invoice is required. That makes the receipt a fiscal document, not a printout of the hotel’s internal bill. A folio line in the PMS and an ÖKC receipt are two different objects with two different owners.

GİB describes new-generation devices as computer-based devices that transfer data securely over the internet, and says the fiscal data from their daily closing (Z) reports reaches the Revenue Administration electronically through secure service providers (GİB, Yeni Nesil Ödeme Kaydedici Cihaz: Sık Sorulan Sorular, 1 November 2026 (opens in a new tab)).

Where the two systems meet: a charge posted to a room in the restaurant or bar has to reach the fiscal device that outlet uses, and the receipt has to be matched back to the guest’s bill before the bill closes. Two failure modes matter. Double recording happens when the charge sits on the folio and a separate receipt never reaches it. Lost linkage happens when a receipt exists with no folio line behind it, and the day-end reconciliation cannot explain the difference.

Which outlets must use an ÖKC rather than issue invoices, and which device generation applies to a given hotel, are tax questions. The hotel’s accountant or legal adviser answers them for the specific case; this article does not. For the outlet-level picture, see ÖKC in hotel outlets: fiscal devices, room charges and invoices and restaurant and bar charges to the room: connecting the POS and the PMS.

What is AI Otel’s status on door locks and ÖKC devices?#

Both are Architected: designed, not built. The operating system is designed for the major door-lock vendors and designed to connect ÖKC fiscal devices outlet by outlet, and no working integration is claimed.

Door locks are Architected: designed for the major door-lock vendors. No vendor is named, no model is certified, and no site has been tested. ÖKC fiscal devices are Architected: designed to connect outlet by outlet. The design intent is one device per selling point, not one device for the whole property, because the design assumes a device at each selling point, each with its own receipt stream. A single central device would blur where the sale actually happened. Whether a given property may serve more than one selling point from one device is a tax question for your accountant.

What sits next to these designs is Built: the hotel operating system itself, covering reservations, front desk, housekeeping, billing, restaurant sales, reports and compliance, built and working, ahead of launch. You can read what that covers in AI Otel’s hotel operating system: what is built and what it covers.

The honest zero, said plainly: there is no lock integration and no ÖKC integration today. What exists is the design and the rest of the system the connection would serve. Read the status word as a boundary, not as marketing. Architected tells you what you can plan around and what you cannot yet buy.

What would going live require?#

Three things in order: the build, the permission and credentials of the hardware side, and a test on real hardware in a real corridor or outlet.

Build first. An Architected connection is a design; someone has to write the code against the vendor’s interface and test it against the device’s actual behavior, not its brochure. Then authority. Lock vendors and fiscal device makers control their interfaces, and fiscal devices sit inside a regulated chain that includes secure service providers. Access is granted, not assumed.

Our general rule for integrations is that built and fixture-tested is not the same as live: going live needs the authority and integrator credentials. That sentence describes integrations that are built, so for locks and ÖKC the credential step comes after the build, not instead of it.

Then a site test: one corridor, one outlet, one device generation, with a named person on the hotel side and a named person on the vendor side, and a written result. Then a fallback plan before the first guest: manual key writing, a standalone encoder mode, and a paper procedure for receipts when a device is down. Only after those four steps does a connection deserve the word live. Until then it stays Architected, and we say so.

What should you ask any vendor before signing?#

Ask for the exact hardware, the exact test and the exact behavior when the link fails. A vendor who cannot answer all three has not done the work.

Which lock and encoder models are certified, with model numbers and firmware versions, not the phrase “compatible with most locks”. Which ÖKC generation and which secure service provider the connection has been tested with, and on which device model. A reference property using the same lock model and the same device generation, ideally at a similar size to yours.

Then the failure paths. What the desk does when the link is down: does the encoder work standalone, who writes keys, and how is that recorded. How a cancelled card is stopped: what the system sends, to which device, and how the hotel verifies that the old card no longer opens the door. How a receipt is matched to a folio line, and who reconciles the day’s receipts when the numbers disagree. Finally, what the contract says about responsibility when the hardware vendor changes firmware or discontinues a model.

What to do next#

Before you compare rate managers and reports, ask for the hardware list: the encoder at your desk and the fiscal devices in your outlets. If a vendor cannot name the models, the test and the fallback, the rest of the comparison is early. The next step is a short conversation about your own hardware, so the answer is about your property and not a generic list: talk to OtelCiro, or request a briefing at info@ai-otel.com.