KBS, KVKK and e-invoicing in the PMS core: AI Otel's approach

A hotel PMS (property management system) is the software a hotel runs its stays on. AI Otel built KBS guest identity notifications, KVKK personal data handling, and e-Fatura and e-Arşiv invoicing into the core of its hotel operating system, with each e-invoice waiting for a person's review. ÖKC fiscal device connection is designed, not built.

At 23:40 a guest hands over an identity card at the front desk. In the next few minutes the hotel records a stay, notifies the identity system, stores personal data under a retention rule, opens a bill and eventually issues a fiscal document. Whether those five things agree with each other is decided by the software, not by the receptionist. After reading this article you will know what each step legally involves, how a hotel PMS with KBS and e-invoicing should carry them, and which questions to ask any provider before you trust it.

What does every stay in Türkiye involve?#

Four steps: a payment, a fiscal document (an invoice or e-document), a guest identity notification (KBS) and personal data (KVKK). They happen at the same desk in the same few minutes, which is why they belong in one system. We explain these four steps of every stay in Türkiye in more detail elsewhere; here we look at how they sit inside software.

The separate-tool approach fails in a predictable way. The guest's details are typed once at check-in and again into a notification program. The bill is corrected in one place, the invoice in another. When a dispute arrives, no one can tell which record is true. "In the core" means something concrete: the check-in screen, the guest bill, the identity notification and the invoice all read from one stay record, so a correction made once is visible everywhere it matters.

There is a trade-off, and it should be stated honestly. A core system carries more legal weight than a side tool, so it must show its working, keep history and let a person stop a step. That is a cost, not a selling point. And the boundary is fixed: the software carries the workflow; the legal duty stays with the facility. Dates, penalties and your own scope are for an accountant or legal adviser. Each of the four steps has its own authority and its own rule set, so a provider claiming all four in one screen should be asked to show each one working.

Production use of the compliance line is unverified.

How does KBS work inside the check-in flow?#

KBS (misafir kimlik bildirimi, the guest identity notification system) notifications are prepared and sent from the check-in flow, so the receptionist does not re-enter the guest's details in a second program.

The legal anchor is old and clear. Türkiye's Identity Notification Law No. 1774 requires the responsible operators of hotels, motels, pensions, holiday villages and similar accommodation to keep the identity and arrival and departure records of everyone they host, day by day; an additional article requires facilities to keep those records on computer and report them instantly to general law enforcement (mevzuat.gov.tr, Law No. 1774, consolidated text in force 05.12.2025 (opens in a new tab)).

The mechanism matters more than the law's history. The identity data captured at check-in becomes the notification, the notification is attached to the stay, and the departure record closes it at check-out. A notification prepared from an export is a second data entry with its own errors; a notification prepared inside check-in cannot drift from the guest record.

Visibility is the other half. A failed or pending send must appear to a person on the screen, not disappear into a log. Silence is the dangerous state. A practical test: ask a provider to show a notification being prepared from a live check-in, not from a report.

What does KVKK require from a hotel, and where does it sit in the system?#

KVKK (kişisel verilerin korunması kanunu, the personal data protection law) asks for a lawful basis, a retention period and answers to guests. AI Otel built consent, data export and retention periods into the data model rather than into a policy document.

Start with lawful basis. Law No. 6698 defines explicit consent as consent on a specific subject, based on information and given of free will, and allows processing without it only where an Article 5 condition applies, such as being explicitly provided for in law or necessary for a legal obligation (mevzuat.gov.tr, Law No. 6698, Articles 3 and 5 (opens in a new tab)). KBS is the clearest example of that second path: the identity notification is a legal duty, so its data does not rest on a consent checkbox.

Retention follows the same logic. Personal data is kept only for the period the legislation sets or the purpose needs, and must be erased, destroyed or anonymized once the reason ends, on the controller's initiative or at the person's request (Law No. 6698, Articles 4 and 7). Article 12 adds security duties: technical and administrative measures against unlawful processing and access, and notification of the person concerned and the Personal Data Protection Board as soon as possible if data is obtained unlawfully. Article 11 gives every person the right to ask whether their data is processed, request information, ask for correction or erasure, and object to an outcome against them that arises solely from automated analysis. A data export built into the system is what makes these rights answerable in minutes.

One recent decision deserves every hotelier's attention. In principle decision No. 2025/2120 of 6 November 2025, published in the Resmî Gazete on 9 December 2025, the Personal Data Protection Board concluded that accommodation providers must stop taking photocopies of guests' T.C. identity cards and destroy copies already taken under Article 7, while recording name, surname and T.C. identity number under the Identity Notification Law is lawful. The decision addresses T.C. identity cards, not foreign guests' passports.

"In the data model" has a plain meaning: consent is a field with a date and a stated purpose, retention is a rule attached to a record type, and erasure is a defined action with a record of who asked. A policy PDF cannot do any of that.

How are e-Fatura and e-Arşiv handled, and why does a person review each one?#

A licensed integrator issues the documents; the hotel operating system prepares them, and each e-invoice waits for a person's review before it is sent.

Per the Revenue Administration (GİB), e-Fatura is an electronic document transmitted between seller and buyer through the central GİB platform; it is not a new type of document and carries the same qualities as a paper invoice, and taxpayers registered in the application send and receive invoices to each other this way (GİB eBelge, "e-Fatura Hakkında", 2026 (opens in a new tab)). e-Arşiv Fatura, regulated by Tax Procedure Law General Communiqué No. 509, is issued to taxpayers not registered in e-Fatura and to non-taxpayers, and delivered on paper or electronically depending on the buyer's request (GİB eBelge, "e-Arşiv Hakkında", 2026 (opens in a new tab)). Under the special integration method, a taxpayer sends and receives e-invoices through the IT system of a private integrator holding special integration permission from GİB. Name no integrator; the point is that a licensed one issues the document.

Why the review exists: an invoice is a fiscal document once sent, and a wrong one has to be corrected through the same formal route. A one-minute human check on buyer details, amounts, VAT and date is the cheapest gate in the whole chain. We present it as good practice, never as a legal guarantee. This article states no mandatory dates or thresholds, and describes no invoice as legally valid because software produced it. A practical reviewer habit: check whether the sale needed an invoice at all, since some sales are documented by a fiscal device receipt instead.

Source: GİB eBelge pages, 2026.

Why are corrections voided and reversed instead of deleted?#

Because a financial record that can disappear cannot be audited. AI Otel's billing never deletes: corrections are voided and reversed, and night audit closes the business day.

The mechanism is simple. A wrong charge is marked void with a reason, and a reversing entry is posted against it. The original line stays visible, with who changed it and why. The consequence for the reader: the guest bill and the fiscal document must agree, and a deleted line breaks the trail between the stay, the bill and the invoice. A reversal keeps all three readable.

Night audit closes the business day, fixes that day's totals and moves the system to the next date, so nothing behind the closed day changes silently afterwards. In front desk practice, staff need a reason field and a permission level, not a delete button; training is about the reason, not the click. The trade-off is that bills carry more lines and a guest may ask why. A printed correction with a short explanation settles that faster than an argument about a missing line.

What about ÖKC fiscal devices?#

ÖKC (ödeme kaydedici cihaz, the fiscal cash register) connection is designed, not built. AI Otel's system is designed to connect ÖKC devices outlet by outlet.

Under Law No. 3100, payment recording devices are devices such as electronic cash registers and electronic terminals, and the receipts they issue document sales for which no invoice is required and take the place of an invoice (mevzuat.gov.tr, Law No. 3100, Articles 1 and 2 (opens in a new tab)). GİB describes new-generation ÖKC as computer-based devices that transfer data securely over the internet, with the fiscal information from their daily closing (Z) reports sent to GİB through secure service providers (ynokc.gib.gov.tr, "Yeni Nesil Ödeme Kaydedici Cihaz: Sık Sorulan Sorular", 2026 (opens in a new tab)).

"Outlet by outlet" is the honest shape of the work. A restaurant, a bar and a spa can each have their own device and their own receipt flow, so a single on/off switch is not what integration looks like. The status word is exact: Architected, designed to connect. Any integration, once it is built, still needs the authority and integrator credentials before it runs in a real hotel; the ÖKC connection is not at that stage. This article does not say which outlets must use an ÖKC rather than issue an invoice, or what any connection deadline is. That is an accountant's call. Our five status words explain the difference between designed and built in more detail.

What should you ask any provider about compliance in the core?#

Ask to see the workflow, not the brochure: where the notification is prepared, where consent is stored, who reviews an invoice, and what happens to a mistake after the day is closed.

Run the checklist below in a demo, with a fictional guest, and ask the provider to break something on purpose. Apply the same questions to us. Our compliance line is built and working ahead of launch, and production use is unverified; we answer the checklist with status words, not adjectives. Ask where the four steps meet: if the identity notification, the bill and the invoice come from different records, a correction will eventually disagree with itself. Ask who can stop a step: a person must be able to hold an e-invoice, void a charge and see a failed notification. Ask what is exported and how fast: a guest's Article 11 request is a delivery test, not a policy question. Close with your accountant or legal adviser for dates, penalties and your facility's scope. Public data and legal texts imply no endorsement of any provider.

What to do next#

Take the eight-question checklist to your current provider and to your accountant in the same week: the provider shows the workflow, the accountant confirms dates, penalties and your facility's scope. The article's parts fit together as one idea: the four steps of a stay share one record, so the correction, the notification and the invoice cannot drift apart. If you want to see how that looks in our own system, the hotel operating system page is at https://ai-otel.com/platform/pms, and you can request a briefing at https://ai-otel.com/contact.