AI Concierge Across a Hotel Group — 3 Properties, 3 Channels, 4 Languages, 91.7% Handled by the Bot, Improved From Real Chats Every Day

The Client

A hospitality group — hotels, resorts and property — registered as 7 separate legal entities under one ownership structure. Some companies run one accounting package, some run another, the rest are keyed into Excel, and every file sits on OneDrive. A single accountant is responsible for the books of all of them, while some of the owners are overseas.

The problem was never that the numbers did not exist. It was that nobody had ever seen all of the operating companies' numbers on one page at the same time.

The Challenge

• •One accountant responsible for every company's books — if she were ever unavailable, there was no backup and no documented process
• •Financial data took months to reach leadership, by which point it was already outdated
• •Cross-company reconciliation between bookings, the accounting platform, and bank statements had, in the client's own words, "never once been completed successfully" by hand
• •Two banks, two structurally different files. Most companies used a manually-keyed voucher ledger; one used a raw electronic statement export. One reader could not read both.
• •Bookings arrived through several channels, each deducting a different commission rate and treating VAT differently — so the booking report total did not equal the ledger total, and neither equalled what actually landed in the bank
• •The group's master workbook had swollen to 350 MB — slow to open, impossible to pull automatically every day. The cause was not data volume: whole-column formatting had been carried in by copying entire sheets, while the real working data was only a few hundred rows.
• •Owners overseas had no route to a group-wide picture at all — the numbers could only be combined after the accountant closed and merged them by hand, which took long enough that the result was no longer useful for a decision

What it costs to leave alone

When nobody sees the whole group at once, one company can run at a loss for months with that number buried in a pile of files. And by the time anyone sees it, it is too late to do anything about that period.

Why an Added Layer, Not a New Accounting System

The client arrived with a problem bigger than one project — group reporting, a building-maintenance workflow, and a chatbot. It was split into three separate proposals, and the accounting report was built first, because it was the one hurting leadership most.

Building a layer on top of what already existed, rather than migrating every company onto one package, came down to four things:

1. •Each company had its own reason for using the package it used — forcing a migration is a different project of a different size
2. •There is one person in accounting — so the answer could not add work for her
3. •The output had to land in a channel leadership already had open — LINE, not a dashboard behind a login
4. •The system had to run on the group's own accounts, with nothing locked to the developer

Before quoting, the client was sent a structural analysis of what all 7 entities' data actually looked like, where it could join up, and which company should be dropped. The result: the company that had already closed was cut from scope before the quote, not after the contract.

Why Safety Came Before Speed

This group was handling highly sensitive cross-company financial data, so the client set data-security conditions before agreeing to the project at all. The agreement that shaped everything else:

Throughout development, the developer would not see a single real figure belonging to the group.

The whole of the first phase was built and tested on simulated data — structurally identical to the real thing, every number invented. The first run against real data happened in the second phase, and the client's own accountant pressed the button, on her own machine, sharing only her screen rather than the data itself. Every account the system runs on stayed in the client's name throughout.

That agreement genuinely made the work slower and harder. It also meant the risk of a data leak during development was zero, not "low".

Out of the group's companies, the client chose to prove the entire path on one pilot company first — read the bank file, read the booking reports, read the ledger, unify, reconcile, summarise, send to LINE. Once that path passed end to end, extending to the remaining five was a matter of pointing at each company's files.

What Happens Every Morning at 07:00

One idea holds the whole design together: let the numbers assemble themselves and arrive as a single message, in a channel leadership already has open. A beautiful dashboard nobody logs into is worth the same as no dashboard at all.

Key Technical Decisions

What Was Delivered

• •Automatic pull from 8 sources on OneDrive
• •A ledger reader for every company, plus the large-file extractor
• •Bank readers for both file formats
• •A booking-report reader with per-channel commission calculation
• •One master table joining every source, written to automatically
• •Three-way reconciliation (bookings, ledger, bank)
• •An AI-written Thai summary leadership can read unaided, with no accounting jargon
• •Delivery to LINE at 07:00, plus a separate sales-pipeline report and a monthly summary
• •Alerting when a workflow fails or a source file stops updating
• •Installed on the group's own accounts, with a user manual and an access-handover document

The installment-1 delivery report named three remaining limitations outright — account-category reading in the ledger was not yet correct in every case, some nodes in the reconciliation layer were still stand-ins, and a re-run could still duplicate rows. All three went onto the next installment's task list, rather than being left for the client to discover.

The Results

1. All 9 planned Phase 1 test items passed within 10 days

A full run-through was verified end-to-end on the pilot company's simulated data: the bank statement read correctly in full, booking reports across 4 channels reconciled correctly with each channel's different commission rate calculated properly, a full monthly P&L read across all categories and months with nothing missing, and the three-way reconciliation completed with zero errors — on a process the client had never once gotten to complete successfully by hand. The daily AI-written summary was confirmed delivered to LINE on every run, with the system itself confirming receipt rather than assuming the message went through.

2. The bank reader produced control totals matching every figure the bank printed

Automated statement reading is only trustworthy if you can prove nothing was skipped. The reader processed a full month of transactions and produced deposits, withdrawals, opening balance and closing balance matching every number the bank printed on the document itself. That means the bank-side figures entering the morning report are not approximations.

3. The whole build was made and tested without one real figure being seen

The entire first phase was built on simulated data and proved every step of the path — bank file, booking reports across 4 channels with per-channel commission, monthly ledger, master table, reconciliation, AI summary, LINE delivery. Every step passed, and the client's own accountant ran the first real data herself. For a business group's financial statements, that is not a small detail — it is the difference between "low risk" and "no risk".

The Most Expensive Lesson: The Report That Quietly Forgot a Company

In live use, companies went missing from the summary message with no warning at all — through three separate mechanisms, each frightening in a different way.

Mechanism 1 — two length caps that happened to stack. One morning's report was missing 2 companies, and the cause was not one thing but two overlapping ones. The AI writing the summary hit its configured length ceiling exactly, and was cut mid-sentence inside one company's paragraph, so the next company was never written at all. Then, in the message-formatting step before sending, a second, fixed line cap trimmed the text from 1,279 characters to 857 — removing another company sitting near the end. Worst of all, a length guard had already been written into the system, and it never ran, because the text had already been truncated before reaching it.

Mechanism 2 — a Buddhist-era year left behind in the client's own sheet name. Another company disappeared because the tab name in her file still carried the old year, so the system could not find it and skipped it — while the group total carried on being calculated as though nothing had happened.

Mechanism 3 — and this is the dangerous one: the client's fix never reached the system. She was told to correct the tab name. On checking afterwards, it turned out the system was not reading her original file at all — it was reading the extracted mini-file. Which means that unless somebody re-ran the extraction, the next morning's report would still skip that company, while she believed it was already fixed.

And the 30-second check handed to the client

Rather than having the client phone every time she was unsure, a check was written into the manual:

Add up the per-company figures printed in the message, and compare them to the printed group total. — If they match, the missing company was dropped upstream (a data problem) — If they do not match, it was dropped at display time (a printing problem)

Two completely different causes, separated in 30 seconds, without opening a single line of log.

When the AI Did Its Own Arithmetic, After Being Told Not To

The prompt carried an explicit hard rule: never guess, never recalculate — only phrase the numbers it is given.

It broke that rule. One report printed a group total that appeared nowhere in the data it had been handed — it had calculated it itself. Another printed record counts that did not match, on a day when there was in fact nothing to compare against.

The lesson carried into every project since: writing a rule into a prompt is not enforcing the rule. Every number a decision-maker will read has to be calculated outside the AI, and handed to it purely to be phrased.

An Honest Note on What Comes Next

At handover, the bank-side reconciliation could not yet match individual transactions, and the client was told directly not to base any decision on the figures in that section. That was reported to them rather than left to be discovered — and it is the next phase's work, not an unsolvable problem.

Since then the client has extended the system to real data across the pilot company and the remaining five, with daily automated runs checked and showing no issues, and a related sales-tracking module now verified working against real deals. That expansion is still actively in progress, not a closed deliverable — a full real-data test, a training walkthrough, and a final handover of system access back to the client haven't happened yet, so this project isn't being described as fully complete. Phase 1, the foundation described above, is the confirmed, tested result this case study stands behind.

Lessons Learned

• •A report missing one company is more dangerous than a report that says "error" — because it looks completely normal. Any summary that lists entities has to be forced to name all of them, every time, even at zero.
• •Writing a rule into a prompt is not enforcing the rule. Every number a decision-maker reads must be computed outside the AI.
• •Sensitive cross-company financial data needs trust designed into the build process itself, not just a signed NDA. Using simulated data throughout development, and having the client run the first real-data test on their own machine, meant real financial data never had to pass through outside hands before the client was ready.
• •A file format that "looks similar" between two sources can turn out to be a structurally different document, not just a different layout. What looked like simply a different bank turned out to be a raw account-statement export with no voucher numbers at all, while the other companies used a manually-keyed voucher ledger — a genuinely different document type requiring its own dedicated parser plus a generated reference number to catch duplicates, since the source file had none. Get a real sample file from every entity before assuming one import method works for all of them.
• •Thai-format dates (day-month-year) can break silently if left for spreadsheet software to auto-interpret. An early version saved CSVs as a spreadsheet file and read them back through spreadsheet software, which quietly reinterpreted Thai-style dates as US-style — swapping day and month for any day number 1-12 with no warning shown, corrupting about a third of the affected records. The fix was reading the raw CSV directly, bypassing spreadsheet auto-interpretation entirely. Totals matching does not mean the dates are correct.
• •A file that is enormous is not necessarily a file with a lot of data. The 350 MB master workbook held only a few hundred real rows; the size was whole-column formatting dragged in by copying entire sheets. Check what is actually making a file big before concluding it cannot be automated.
• •A cross-company system only moves as fast as the client's own accounting team can keep the source data current. When expanding from the pilot, two companies reported zero revenue for several days straight — not a bug, but because the accounting team hadn't yet keyed the revenue figures into those companies' source files. Expanding to several companies at once means checking each one's data readiness first, not assuming they're all equally ready.
• •A fix the client makes does not automatically reach the system. If the system reads a derived copy rather than the original, the client can correct the original, believe the problem is solved, and be wrong. Say out loud which file the system actually reads.