Skip to content

Documents

The email parser reads what your mail client hands over. This page is about everything else a confirmation can arrive as — a PDF attachment, a photograph, a travel-document bundle from a tour operator — and about the step that runs before any of them: deciding what kind of document it is.

Since 2.6.0 you do not tell TravStats whether you are dropping a flight, a cruise or a hotel. A pasted mail, a .msg/.eml file, a PDF or a photograph is sent with domain: "auto" and the server decides. Three things about that decision:

  • It is a weighted scorer, not the language model, so it works on an instance with no Ollama and costs nothing.
  • A signal counts once, however often it repeats. Marketing mail is the longest thing anybody forwards, and a promotion that says “cruise” forty times is not forty times more a cruise.
  • A weak answer still returns what it parsed, with the runners-up, so the dialog can offer a switch instead of asking for the file again. An explicitly named domain keeps its exact previous behaviour.

The result is a property of the document, not of the button that sent it — which is what lets every domain page and the dashboard share one drop zone.

A booking PDF goes through the same pipeline as a mail once its text is extracted: domain detection, then that domain’s parser. The message date of a mail is read from the file; a PDF carries no such date, so a confirmation that names only a day and a month is read against the travel period it describes rather than today.

Fly & cruise bookings, hotel confirmations with a PDF attached, airline itineraries — all the same door.

POST /parse-image reads a photographed document — a hotel bill, the most photographed travel document there is — through OCR and hands the text to the same parser as a mail or a PDF. Until 2.6.0 an image could only ever become a flight. The OCR worker reads German as well as English, since the lodging parser matches on “Nächte”, and on an air-gapped instance with no language pack it degrades to English rather than failing.

A photograph is a worse source than a file: a crooked, shadowed bill yields less than its PDF would. Expect to check the total and the dates on the review screen. A boarding pass is not a document in this sense — it has a reader of its own that starts with the barcode.

Hotel confirmations from Booking.com are read by a deterministic template, no model involved — measured against 95 real confirmations, it finds the stay in 93 and the price in all 93, across both layouts the sender uses. Anything the template does not recognise falls back to the model path, exactly as flights do. The template extracts the house, the dates, the room, the board, the price with its currency and the guests; the postcode is split off the city (“188973 Singapur” is a city and a code, not a city).

Every other sender goes to the language model, which is asked for what the document says, not only what it transcribes:

  • the kind of place — a campground is not a hotel;
  • the group behind a brand — “Courtyard by Marriott” is Marriott;
  • the country a city sits in — a US booking stores the country, not “TX”;
  • the meal plan, the per-night rate, and how many people the booking covers, which 61 %, 47 % and 42 % of real confirmations state. A booking for more than one person points at the companions field and never invents a name — a confirmation names the booker, not the companion.

A total the document actually labels overrules the model; a number counts as money only if it carries a currency or two decimals, so “(1 Erwachsener)” beside “Gesamtpreis” stays a guest count, and the amount belonging to a label is the nearest one. A two-digit year is read against the travel period. Two thirds of an old hotels.com mail was tracking links; those are replaced with placeholders before the model sees the text — for the model only, since a template may key on a link. The result says who looked and what was dropped: “no parser produced a result” is not “no parser ran”.

A tour operator sends two things: an invoice and the travel documents. Measured against seven real bookings, the invoice yields the trip, its price and its flights with IATA codes; the travel documents yield the day-by-day itinerary and the hotels with their addresses. The parser reads both, and the result lands on a trip with its flights and stays attached.

Fourteen lines across those seven bookings look like flights and are not — un-ticketed placeholder legs, separately ticketed ones, the rail transfer to the airport. They are refused with a reason rather than dropped silently, so the review screen shows what was left out and why.

The evidence rule applies to whatever any provider returned, not only to the fallback that happened to carry it before:

  • a flight needs a flight number or both ends of a route; a booking reference must be labelled as one;
  • a stay needs a name and both dates;
  • a date alone is not evidence — every promotional mail has one.

So a promotion comes back as nothing, an airline’s holiday greeting does not become a booking with reference “LEIDER”, and “ab 380 EUR” is a price, not flight AB380. Finding nothing is an answer, not a server fault: the dialog says so and offers manual entry. Only a chain in which no parser ran at all is an error.

  • A picture of a flight ticket is still weaker than its PDF. The image path exists so a hotel bill can be photographed; it is not a reason to photograph documents you have as files.
  • One deterministic hotel template. Booking.com only; every other hotel sender needs the language model.
  • Package tours are measured on seven bookings from a handful of operators. Another operator’s layout may parse partially; the refusals will tell you what was left out.
  • Detection is a score. A document that reads as two things at once — a fly & cruise invoice — is one of them by the score and the other by the switch in the dialog.
  • OCR languages are German and English. A bill in another language is read as if it were one of the two.