A rooming list is a billing document wearing a hotel’s clothes

A rooming list looks like the simplest document on a production. Names, hotels, room numbers, dates. It is the one a coordinator expects to knock out in an afternoon.

Then the invoice arrives, and it turns out the document was never really about where people slept. It was about who pays for which nights, and that question was never properly answered, because the format did not have anywhere to put the answer.

Two documents pretending to be one

There are genuinely two artefacts here and they serve different readers.

The hotel needs an occupancy list: names, arrival, departure, room type, who is sharing. Front desk information. The production needs a ledger: nightly rate, tax, number of nights, and the paying party for each line. Accounting information.

Most templates are built for the first and then asked to do the second at the end of the job, usually by a different person, usually against an invoice that groups things differently. That is where the arguments come from. Not from disorganisation — from a document that was never structured to hold the fact being disputed.

The paying party is the point

On a service production, "who pays" is rarely one answer. The client covers the director and the agency people. The production company covers local crew. A talent agency covers the cast, or covers them for some nights and not others. Somebody's extra night before the shoot is personal and gets billed back.

If the paying party is not a field on every room, that information lives in a colour-coded highlight or in the coordinator's memory, and neither survives the six weeks between wrap and the final reconciliation. When the summary has to be produced by paying party — which it always does, because that is how it gets invoiced — it has to be reconstructed.

Making it a field costs nothing at entry and removes the entire reconstruction. The summary becomes a grouping rather than a research project.

Split stays are the real test

Here is the case that breaks templates.

One person checks in on the 12th, leaves on the 15th, comes back on the 18th, and leaves on the 22nd. Same person, same hotel, possibly a different room, possibly a different rate, possibly a different payer for the second block.

In a spreadsheet this becomes either two rows for one person — which breaks headcounts and makes the occupancy list wrong — or one row with a note in a comment field, which means the ledger cannot compute anything. Neither is right, and everyone has picked one and lived with the consequences.

A room has to be able to hold more than one stay. Until it can, split stays are handled by convention, and conventions are what a document loses when it is passed to somebody else.

The math is the substance

Nightly rate, times nights, plus tax, grouped by payer, subtotalled, with a grand total that ties to something. That is not a decorative table at the bottom of the document — it is the reason the document exists. Long stays run across pages, so the continuation has to carry the running figures rather than restarting them.

And the currency has to be explicit. On a foreign production, a rate quoted in local currency and an invoice settled in dollars are two facts, and a summary that shows only one of them will be queried by somebody.

It should build itself from what you already know

The last piece: nobody should be typing crew names into a rooming list. The crew record already exists, and the schedule already knows which days each person is present. Matching present-days against a hotel's date window generates most of the rooming list mechanically — the coordinator's job becomes the exceptions, which is where their judgement was actually needed.

That is the general shape of the argument across all of this work. The tedious eighty per cent is derivable from records you already hold. What is left is the twenty per cent that requires someone who knows the production — and that is the part worth a coordinator's evening.