What is OCR? Reading invoices and delivery notes into hotel systems

OCR, optical character recognition, turns a picture of text into characters a computer can search and store. It gives text, not meaning. In a hotel it is only useful when each read amount is matched to the purchase order and the goods received, and a person confirms it before payment.

A delivery note reaches the loading dock with two cartons crossed out and a correction written by hand. Someone types it into the system that evening, and the invoice that arrives two weeks later is checked against that typing, not against the goods. This article explains what OCR actually does, where it fails on Turkish hotel paperwork, and how to test a tool before buying it, so you can decide whether reading is your problem or whether the real gap is the match behind it.

What does OCR mean, in one paragraph?#

OCR, optical character recognition, turns a picture of text into characters a computer can search, copy and store. It returns text, not meaning: it does not know that one number is a total and another is a due date.

The chain is short and mechanical. A scan or a phone photo becomes an image, the software straightens it and adjusts contrast, finds the lines of text, recognizes characters one by one, and returns a string with a confidence value. That is all.

Not every PDF needs OCR. One kind carries a text layer that can be selected with the mouse; the other is a photograph wrapped in a PDF. Test any file by trying to select a line before assuming you have a reading problem.

Zone or template OCR is told in advance where to look: the total is always in this box, the invoice number always in that one. It is fast on a fixed layout and breaks the day a supplier redesigns the page. What comes out of any variant is characters, their positions and a confidence. What does not come out is a supplier matched to your vendor record, a VAT breakdown, or a check that the lines add up to the printed total.

In daily speech, "OCR programı" usually means the whole capture chain, from scanner to accounting system, not the recognition step alone. Ask a seller which part they are describing. The recognition step is the cheap part; the work sits in the fields you define, the rules you check and the person who confirms the result.

How is OCR different from AI document reading?#

Classic OCR converts pixels into characters. AI document reading adds layout and meaning: it groups lines into fields, handles a supplier layout it has never seen, and returns a structured record with a confidence for each field.

The difference shows in the shape of the error. OCR mistakes look broken: a total of 150,00 coming back as 1S0,00. AI extraction mistakes look normal: a total of 150,00 coming back as 105,00, which passes a glance. Most AI document reading still runs OCR underneath; the model works on the recognized text together with the visual layout, which is why a stamp or a table border can still confuse it.

A language model asked to read an invoice can produce a total that is not printed anywhere on the page. The defence is arithmetic and cross-checks, not trust in the model. Confidence belongs to the field, not to the document: a page can be right on nine fields and wrong on the one that decides the payment.

Neither method replaces the fiscal document. The supplier's invoice, paper or electronic, is the record; the read is a copy of it, and the copy never outranks the original.

If you also want to know how far AI should go in the back office generally, read AI in hotel accounting: where it helps the back office and where it must not decide.

Where does OCR genuinely help in a hotel?#

It helps wherever the same document type arrives many times in a shape a person would otherwise retype: supplier invoices, delivery notes, price lists and the paper that travels with a delivery.

Delivery notes at the dock are the strongest case. Reading the note when the goods arrive gives the storeroom the quantity the same day, weeks before the invoice appears, so the receiving leg of the check is no longer the weakest one. Supplier invoices from small vendors who send a photo or a scanned PDF are the second case. Large suppliers usually send an e-Fatura as structured data, and there is nothing on that file to read.

Price lists and supplier catalogs become a draft price update that purchasing confirms line by line. The reading saves typing; the confirmation keeps the price list honest. It does not help with the decision: reading a unit price correctly says nothing about whether that price is the one you agreed.

Volume decides. If a document type appears a few times a month, typing it is cheaper than a project, and the project carries a maintenance cost nobody budgets for. Start with the document your team retypes most often, not the one that looks most impressive when demonstrated.

Where does OCR go wrong on Turkish hotel paperwork?#

It fails where the page stops looking like clean printed text: Turkish characters, decimal commas, stamps over numbers, handwriting, carbon copies and phone photos taken at an angle.

Turkish characters break first: ı and İ, ş, ğ, ç, ö, ü. A capital İ read as I turns İşletme into Isletme, and a supplier name that no longer matches the vendor record breaks the match before the amounts are even compared.

The decimal comma is the expensive one. 1.250,00 can come back as 1.250 or as 1250.00 or as 1,250.00, and a thousand-fold error sits quietly in a column of normal-looking numbers.

Stamps and signatures land on the quantity column and on the total. A round stamp over a figure is exactly where the reader has the least information, and the reader's confidence is often still high. Handwriting is the information you most need and can least read: the correction written at the dock, three cartons short, is the sentence the invoice check depends on. Carbon-copy delivery notes, faded thermal slips and photos taken under warehouse light all reduce the input quality before the software starts.

Units are read as bare numbers. Twelve of what: koli, adet, kilogram, litre? A case-to-piece conversion changes the quantity by the pack size, and the reader will not tell you which unit it saw. Multi-page invoices put the lines on page one, the VAT summary on page two and the total on page three, and each page is read as if it were a separate document.

What is the three-way match, and why does it decide whether OCR was worth it?#

The three-way match compares what was ordered, what was received and what is being invoiced, and payment waits until the three agree within tolerances you set in advance. OCR only feeds the third leg.

The order is approved before the goods arrive, with quantities and agreed prices. Without an order there is nothing to match against, and no reading technology can invent that control. The receiving note is signed at the dock with the quantity and condition actually delivered. This is the leg hotels most often skip, and it is the leg that protects the money.

The invoice is compared line by line: quantity against the receiving note, unit price against the order, VAT rate against the supplier's status, freight against what was agreed. Tolerances are agreed in advance, for example a small quantity difference on weighed goods. Anything outside the tolerance is held for purchasing, not paid and corrected later.

Typical exceptions: short delivery, substitution, an unannounced price increase, freight added on the invoice but never on the order, and a unit that changed from case to piece between order and invoice. A good system proposes the match line by line, shows the invoice image beside each line, and stops at the exception instead of guessing. The reading is a convenience; the match is the control. For the full procedure behind the match, see hotel purchasing and receiving: a procedure from order to storeroom.

How do you test an invoice-reading tool before you buy it?#

Test it on your own documents, count errors per field rather than per document, and check whether every read field links back to the place on the page it came from.

Take twenty to thirty real documents from last month and include the ugly ones: a stamped delivery note, a phone photo, a supplier with an unusual layout, a page with a handwritten correction. Name the fields that matter before the test: supplier, invoice number, date, line quantity, unit, unit price, VAT rate, total. A tool that is good at everything you did not define has told you nothing.

Weight the errors. A wrong total costs money; a wrong internal note costs a correction. Report the two separately or the average will hide the risk. Ask what happens at low confidence: does the tool mark the field for review, or does it fill the field anyway and move on?

Check the image link. Can a person click a field and see the exact area of the page it came from, at readable size? Check the destination: does the read land as a draft a person confirms, or does it post straight into the ledger? Test Turkish characters and decimal commas explicitly, with your own examples, rather than accepting a demonstration on a clean English invoice.

Who checks the read, and what stays in the record?#

A person confirms every amount that reaches the ledger, and the record keeps the image, the extracted fields, the confidence and who changed what.

Separate the roles. The person who received the goods should not be the only person who approves the invoice that pays for them. Treat the correction as data: when someone fixes a read quantity, that correction tells you which supplier, which layout and which field fail, and it is the best evidence for improving the setup.

Keep the image exactly as it arrived, unedited, next to the extracted record. The supplier's invoice is the fiscal document; the extracted fields are a convenience built on top of it. A corrected read should show the original value, the new value and who changed it, so a question asked six months later can be answered from the record rather than from memory.

Never delete a wrong read. Void it and re-enter, the same rule that applies to any financial record in a hotel. Decide in advance what moves to the accounting system at day end and how a person checks that the move was complete; the same discipline applies to what moves from the PMS to the accounting system at day end.

What to do next#

Pick one document type your team retypes every week, run twenty of last month's real pages through the tool you are considering, and count errors per field before you decide anything. Then put the match in place: a read invoice is only worth the comparison it feeds, so the order, the receiving note and the invoice have to meet in the same place, with a person confirming the result and the image kept beside it.