A travel expense report can be produced automatically, just not the way most people expect. You do not need another app for photographing receipts. You need something that can read what you already have: meetings in the calendar, confirmations in mail, and the rates that took effect in January. The rest is mechanical arithmetic.
The work nobody wants
It looks the same every time. End of the month, an envelope on the corner of a desk or a folder in downloads. A parking ticket, a fuel receipt, a hotel confirmation, one mail with a train ticket. Somebody has to remember what time the car left and what time it came back, because the per-diem band, and therefore the money, depends on it.
Then comes the transcription. Date, place, purpose, start, end, kilometres, rate per kilometre, fuel price, total, the deduction for the hotel breakfast. Into a form, into a spreadsheet, into accounting. None of it is hard. There is simply a lot of it, and it gets done late in the evening, so it gets done wrong. One wrong band and the form comes back.
An hour of searching, four minutes of maths.
— Month end, abridged
What automatic actually means here
Claude knows nothing about your trip to Brno on its own. The model is not the bottleneck. The bottleneck is that everything the report needs sits in systems Claude cannot see: the calendar, the mailbox, the mileage log, the accounting ledger. A bridge can be built between them.
That bridge, in our work, is a small MCP server. A narrow, clearly scoped connection between Claude and one system. It copies nothing out, it runs on your own infrastructure, and it carries the identity of the person asking. When a salesperson asks for their draft, Claude reads that persons calendar and that persons mail. Not a colleagues calendar, and not payroll.
Concretely: calendar, mail and Pohoda
Nothing you use today changes. The calendar stays a calendar, mail stays mail, accounting stays accounting. Only the connection is new. Let us say five people travel regularly and the company runs thirty trips a month. That is thirty forms somebody assembles by hand today, and thirty drafts that could be waiting the morning after each trip ends.
- It takes the date, the departure and return times and the meeting location from the calendar, so the per-diem band comes from a record rather than a guess.
- It pulls the hotel confirmation, the ticket and the fuel receipt out of mail and attaches them to the right trip.
- It calculates kilometres and the allowance using the rates in force for that year, including the deduction when a meal was provided.
- It assembles the report in the format the company already uses and prepares it for posting in Pohoda or for handover to payroll.
- It flags what does not add up: a missing document, a trip with no stated purpose, an amount outside the usual range.
Picture a service technician who visits twenty customers a month across the country. Today he writes times into a notebook and copies them out on Sunday. With the bridge, Monday morning brings a list of trips assembled from his own calendar and his own mail, he adds the two missing documents, and he is done. It is an illustrative scenario, but it is built entirely from data the company already holds.
What Claude will not do with travel orders, and why that is good
It will not approve a trip and it will not close a settlement. The Czech Labour Code gives the employee ten working days after the trip ends to submit the documents, and the employer another ten working days to settle it, unless a different period is agreed. Those deadlines belong to named people, not to software.
It also will not decide whether a dinner was work, whether an unusual item is acceptable, or whether the trip was necessary in the first place. Those are judgements with consequences and they stay with the signature. That is precisely why the pattern can be trusted: it never takes the last step. It hands over a complete, checkable draft and stops.
What it would take
You start with one system, usually calendar and mail, because that is where most of the answers already are. The bridge is a small piece of software, not a year-long programme. It runs on your infrastructure, it signs in with your identity, and it can be switched off at any time. Once the first one works, the next one (mileage log, accounting) is a matter of days. The way the report gets assembled is then saved as a shared skill, so next month the whole team does it the same way.
What is left
The model is not the bottleneck. The gap between Claude and the data your company already has: that is the bottleneck. With travel expenses the gap is unusually visible. Everything is written down already, just in five different places with nothing between them, so a person does the joining on a Sunday evening. That gap is what we close.
If travel settlements take time you had already promised to something else, write to us. A short call is enough. We will look at where your data sits and tell you straight away whether this makes sense for you or not.