AI terms for the back office: reconciliation, extraction, exception and review queue
This guide defines four key AI terms for hotel back office work: extraction, matching, reconciliation, and review queues. Learn how to judge system reliability by asking the right questions.
Contents
Key takeaways
- Extraction is not understanding: it turns a document into fields, and a wrong field looks exactly like a right one until someone compares it with the page.
- Matching finds pairs; reconciliation explains the difference, so a system that only reports matches has not reconciled anything.
- An exception queue and a review queue answer different questions: one asks what the system could not resolve, the other asks what a person must approve.
- A confidence label is the system's own estimate of its reading, so it belongs next to the field and never in place of an approval.
- Every automated posting needs a named approval and an append-only record that still shows the source document.
Extraction turns a document into fields. Matching pairs two records. Reconciliation explains every difference between them. The exception queue holds what the system could not resolve; the review queue holds what it resolved but a person must approve. A confidence label is the system's own estimate, and an audit trail records who approved what.
The demo runs cleanly: an invoice is read, matched to its delivery note and posted, and nobody touches it. The question that decides whether this belongs in your hotel is not how fast it read the invoice. It is what happens to the one it read wrong. This short guide to AI terms for night audit and back office work gives you the words, the failure modes and the questions to ask, so you can judge the queue before you judge the reading.
What do these four words actually mean?
They name four different steps in one chain, and a demo that blurs them hides where the real work sits.
Extraction turns a document into named fields: supplier, date, invoice number, tax base, tax, total, line items. Matching pairs a record with its counterpart, such as an invoice with its delivery note, or card takings with the point-of-sale end-of-day total. Reconciliation explains every difference between two sets of records until each line is either matched or carries a stated reason.
The two queues are different things. The exception queue holds items the system could not resolve. The review queue holds items it resolved but a person must approve before they become final. A confidence label is the system's own estimate attached to a field or a match. An audit trail is the append-only record of what was read, matched, approved and changed.
Approval, finally, is a named person's decision with a time on it. That is a different thing from a queue being emptied.
| Term | Plain meaning | Question to ask in a demo |
|---|---|---|
| Extraction | A document becomes fields | Which fields, and is the page image kept? |
| Matching | Two records are paired | Which fields are compared, and what happens when the invoice number is missing? |
| Reconciliation | Differences are explained | Show me the difference report, not the match rate |
| Exception queue | What the system could not resolve | Who clears it, and how are old items escalated? |
| Review queue | What a person must approve | What happens if nobody approves? |
| Confidence label | The system's own estimate | Is it a raw score or calibrated? |
| Audit trail | Append-only record | Are corrections made by reversal? |
| Approval | A named decision | Does a person or a batch job clear the item? |
What does extraction mean, and where does it fail?
Extraction turns a document into fields a system can compare, and it fails quietly: nothing crashes, a number is simply wrong.
Reading characters and assigning them to fields are two different jobs. A system can read a page well and still put the tax base in the total column. Silent errors are the norm: a 1 read as a 7, a lost decimal point, a second page that was never processed. The posting looks normal in every list.
Arithmetic checks are the cheapest defence. Line items must sum to the subtotal. Tax must be computed on the base. The total must equal base plus tax. A failed check belongs in the exception queue, not in the ledger. Keep the page image and the position of each field on it, so a person can compare the reading with the paper in one glance.
The normal failure cases in a hotel are known: handwritten delivery notes, multi-page invoices, foreign currency, rotated phone photographs and credit notes. Ask what happens to a document the system cannot read at all. Is it rejected with a reason, or posted with blank fields? For the reading step itself, see What is OCR? Reading invoices and delivery notes into hotel systems.
TipBring your own documents
Bring your own documents to the next demo: one clean supplier invoice, one photographed delivery note with handwriting, one two-page invoice, one foreign-currency invoice and one credit note. Watch what the system does with each, not with the sample it brought.
What is matching, and why is reconciliation more than matching?
Matching pairs two records. Reconciliation is the work of explaining every pair that does not agree, and it ends with a reason, not a tick.
Every line has three possible outcomes: matched, matched within a stated tolerance, or no counterpart. Each outcome needs a destination and a record. Tolerances must be written down and small, for example a rounding difference of a few kuruş, and every use of a tolerance should be logged so a repeated small difference becomes visible as a pattern.
A hotel reconciles on several fronts at once. Supplier invoices are reconciled against delivery notes. Point-of-sale takings are reconciled against cash and card settlements. Agency statements are reconciled against reservations and commission. The city ledger is reconciled against payments received. The useful output is a statement of differences with reasons, which is what the night audit pack should carry forward to the morning; see Night audit reports explained: trial balance, manager's flash and the exception lists.
A system that reports a high match rate without showing the unmatched remainder has reported, not reconciled. Matching rules should be visible to the controller: which fields are compared, what happens when a field is missing, and who may change the rule.
What is an exception queue, and how is it different from a review queue?
The exception queue holds what the system could not resolve. The review queue holds what it resolved but a person must approve before the action becomes final.
The two queues answer different questions, so they need different owners and different habits. Exceptions are worked down to zero. Reviews are worked to a decision. Mixing them is the common mistake: a low-confidence reading then sits beside an approved but unsent e-invoice, and the controller cannot tell what needs thinking from what needs signing.
Every item should carry its reason, its source document, the proposed action and the role allowed to clear it. Age matters more than count: an exception that has sat for a week is usually a missing document or a supplier dispute, not a software fault. Nothing should leave a queue silently. A cleared item keeps its record and the name of whoever cleared it; a rejected item keeps its reason.
Authority should be tiered. A night auditor may clear a rounding difference inside a stated tolerance, while a posting to the ledger or the sending of a fiscal document is a different level.
What should a confidence label tell you, and what should it never do?
A confidence label is the system's own estimate that a field or a match is right. It is useful for routing work and useless as an accounting judgement.
It should sit on the field, not on the document. One page is rarely uniformly good or bad, and a document-level average hides the one bad line. Ask what the number is: a raw score from a model, or a value calibrated against real outcomes. A demo may show the first and describe it as the second, so ask which one the number is.
The dangerous case is a high score on a wrong reading, which is why arithmetic checks catch more than scores do. Thresholds decide behaviour: above a line the system posts, below it the item goes to a queue. Ask for the threshold, who set it, and who may change it. A score should never replace a person's approval on anything that changes the ledger or sends a fiscal document. If the vendor cannot explain how the score was produced, treat it as a sorting hint and nothing more.
Watch outA score is not a check
A confidence score is not a probability you can budget on, and a high score is not a check. Route work with it, never sign with it.
What must an audit trail and an approval step look like?
The trail must show what was read, what it was matched to, who or what approved it, and what changed, in a record that can only be added to.
Append-only means corrections are made by voiding and reversing, not by editing the original entry, and financial records are never deleted. Each entry should point back to the source document image and to the field positions that were used, so a reviewer can check the reading without hunting for the paper. Approval means a named person's decision with a time on it, not a batch job that emptied a queue overnight.
The record should distinguish a rule that ran automatically from a person who decided, because the two carry different responsibility. Tamper-evident is the honest standard: if someone alters a record, the chain shows it. No system should be described as tamper-proof. The same discipline applies to outbound documents: an e-invoice that waits for a person's review is a review queue with a legal consequence, not a delay to be engineered away.
ChecklistSix questions for the vendor
- Can I see the source image next to every extracted field?
- Are corrections made by reversal or by editing?
- Does the record show whether a rule or a person approved this?
- Can I see who changed a matching rule and when?
- Does the trail survive an export to my accountant?
- What happens to a record if someone tries to alter it?
For the wider record a hotel should demand, see AI audit trails in hotels: what a good record should show. One example of the discipline in practice: AI Otel's hotel operating system has KBS, KVKK, e-Fatura and e-Arşiv compliance built into the core, and e-invoices wait for a person's review before sending. It is built and working, ahead of launch.
What to do next
Take five of your own documents and one week of your own statements into the next demo, and ask what happens to each failure rather than how fast the clean ones went through. The terms form one chain: extraction feeds matching, matching feeds reconciliation, and the two queues and the approval step decide what reaches the ledger. The chain is only as strong as its weakest queue, so judge the queue before you judge the reading. For where this helps and where a person must still decide, see the companion piece on AI in hotel accounting. If you want to see how the approval and audit steps above are handled in a system built for Türkiye's compliance duties, request a briefing.
Frequently asked questions
Is OCR the same as data extraction?
No. OCR reads characters from an image; extraction decides which characters are the invoice number, the tax base and the total, and places them in named fields. A system can read a page well and still extract badly, which is why arithmetic checks and the page image matter more than the reading itself.
Can an AI system post invoices to the ledger without a person?
It can be built to, but whether it should is the hotel's decision, not the software's. Anything that changes the ledger or sends a fiscal document should keep a named approval, and corrections should be made by voiding and reversing rather than by editing. Ask the vendor to show the approval step, not to remove it.
What is a tolerance in reconciliation?
A tolerance is a small difference the hotel agrees to accept as matched, typically a rounding gap. It must be written down, kept small, and logged every time it is used, so that a repeated small difference becomes visible as a pattern. Anything above the tolerance goes to the exception queue with a reason.
Does a confidence score tell me the extraction is correct?
No. It is the system's own estimate, usually on a single field, and it is not calibrated by default. Ask whether the number is a raw model score or measured against real outcomes, what threshold triggers automatic posting, and who may change that threshold. Treat an unexplained score as a sorting hint.
How should we test these tools before buying?
Use your own documents, including the bad ones: a handwritten delivery note, a multi-page invoice, a foreign-currency invoice and a credit note. Watch where each failure goes, who clears it, and what the record shows afterwards. A demo that only runs clean samples tests the samples, not the system.