Read the hotel’s list against yours, row by row
The hotel returns your rooming list in its own room codes and its own name format, and the differences that matter are buried in the ones that do not. The rooming-list audit reads the hotel’s file on its own terms and hands you the short list of what genuinely disagrees.
A rooming list audit compares the list a hotel returns against the reservations you sent, and reports what actually differs. Blocks matches rows by confirmation number first, works out what the hotel’s own room codes mean from the rest of the same file, treats "BRENNAN, TYLER" and "Tyler Brennan" as one person, and proposes every correction for you to confirm.
“The hotel sent it back in their PMS format and every single row came out as a room-type mismatch.”
Blocks works out what a code like NQQ means from the rest of the same file. Where the evidence is not there, it says nothing rather than filing a finding you have to dismiss 300 times.
“Half the "errors" were just their system writing surnames first. The one real date change never surfaced.”
Name formats are read as formats, not as differences. Small spelling shifts on a clearly matched guest collect in their own collapsed group, out of the headline count, so a moved date is not buried under them.
“They faxed us a printed list. There is no way I am typing 200 confirmation numbers off a scan.”
Blocks keeps the numbers off a scan and marks them unverified. They never decide which guest is which, never overwrite a number you already have, and stay out of the import until you tick that you have checked them yourself.
“I am not letting anything overwrite a VIP’s reservation with the hotel’s version of it.”
Nothing overwrites anything. Every correction the audit finds is proposed, and you confirm each one before it touches your rooming list.
What is a rooming list audit?
It is the check you do when a hotel sends your rooming list back — comparing what the hotel has on file against the reservations you actually sent, and finding the rows that moved. Done by hand it is the worst hour of the event: two lists in two formats, hundreds of rows, and no reliable way to line them up except reading them. Blocks does the lining up. It matches rows by confirmation number first, because that is the only key both sides agree on, and falls back to guest name and dates where a confirmation number is missing. Then it sorts what it finds: names that changed, dates that changed, guests on your list the hotel does not have, and guests on the hotel’s list you never sent. You read a grouped summary of what disagrees instead of re-reading the list. What the audit is not is a sync. Nothing the hotel sent is written into your records on its own — each correction is proposed and applied only when you confirm it, one at a time.
Why does the hotel’s rooming list never match the one you sent?
Because the hotel is not sending your list back. It is sending you its own system’s view of the same rooms, and its system has its own words for everything. Your "Double Queen" comes back as NQQ, QQ or 2QNS. Your "Tyler Brennan" comes back as BRENNAN, TYLER or BRENNAN/TYLER, because that is what a property management system exports. Read literally, every row of a coded export disagrees with yours, and a check that reports every row as a finding has told you nothing. That is the failure this page is about: on the six-format corpus Blocks tests against, literal comparison produced roughly thirty-two false room-type findings and thirty-three false name mismatches on a single coded file — and a genuine date change planted in the same file never surfaced at all, because nobody reads to the bottom of a list of sixty-five errors. The job is not to compare harder. It is to read the hotel’s file on its own terms first, and only then compare.
How does the audit handle the hotel’s own room codes?
It works out what each code means from the rest of the same file, and only from that file. If a code sits on thirty of your Double Queen rooms and on one King, the thirty are treated as a match and the one is reported — the outlier is the finding, not the pattern. Where the file does not give enough evidence to tell, the audit says nothing rather than guessing, because a confident wrong answer costs more than a silence. Two properties of that design matter when you are deciding whether to trust it. First, a genuine room change still comes through: if the hotel wrote one of your own room names on a row where you wrote a different one, that is a real crossing and it is reported. Second, nothing is remembered between audits. Each file is read on its own terms, so a hotel that changes its codes next season carries no stale assumption from last season into this one, and Blocks never builds a lexicon of one property’s codes and applies it to another. There is no shared PMS dictionary anywhere in the product — hotel codes are the hotel’s, and Blocks has no authority to copy them.
Will it flag every spelling difference as an error?
No. "BRENNAN, TYLER", "BRENNAN/TYLER" and "Tyler Brennan" are read as the same person, so a format is never reported as a change. Suffixes are kept rather than dropped, so Smith, Jr and Smith, Sr stay two different people, and the transform switches itself off entirely on rows carrying words like HOLD, SECURITY, TBD or Inc — so "HOLD/SECURITY" is never read as somebody called Security Hold. What is left over is real difference, and it is graded. A small spelling shift on a guest who is clearly the same person collects in a collapsed group called "Possible name changes" — "Ana Ruiz" against "Anna Ruiz" — which stays out of the headline count and needs nothing from you unless you want the hotel to confirm one, in which case flag it and it rides along in the changes email. A genuine mismatch — "Katherine" against "Kathryn", or a different surname — stays a hard finding. And on a possible name change the audit deliberately does not offer to correct your record: the hotel’s spelling of your guest is the wrong source of truth for your own list.
What if the hotel sends back a scan or a fax?
It still works, with the confirmation numbers kept and marked unverified. An image-only PDF has no text layer to check a reading against, so those numbers are handled behind four fences. They have no matching authority at all: rows from a scan are matched on name and dates, never on a number read off an image, so a mis-read digit can never attach the wrong guest to the wrong reservation. They never overwrite — an unverified number can only fill a confirmation field you have left empty, and that rule is enforced in the database rather than in the screen. They are never hotel-facing: no correction is filed off one and no scanned number is emailed back to the property as your record. And the import is the verification event — they stay out of it until you tick that you have checked them yourself, against a line telling you exactly how many were read that way. Every PDF the hotel sends is read natively, page by page, rather than flattened into extracted text first. That fix mattered: a partially-read file used to reach the audit as "23 missing reservations", which reads to a coordinator as the hotel dropping twenty-three rooms rather than as Blocks misreading the file.
How much does the audit actually cut, and where do I start one?
Measured on a corpus of six real hotel-return formats, coded property-management exports went from thirty-five actionable findings to three, and every format produced zero false name-mismatch rows where coded exports used to produce around thirty-three each. The three that remain are the ones worth an email. You start the audit where the file arrives: when a hotel emails its list back, the attachment on the event’s Comms tab starts the audit directly, so there is no downloading and re-uploading in between. Upload works too. The review is durable — walk away mid-way and the page comes back where you left it rather than re-reading the file from scratch — and a stored review opens again from a link instead of being parsed a second time. When you are done, Blocks drafts a changes-only email back to the hotel, just the rows that need fixing, that goes out on your click and never on its own. Auditing and sending are coordinator work: department leads can read a result, but the hotel-facing half stays with the person who owns the relationship.
Frequently asked questions
The hotel returns your rooming list in its own room codes and its own name format, and the differences that matter are buried in the ones that do not. The rooming-list audit reads the hotel’s file on its own terms and hands you the short list of what genuinely disagrees.
What is a rooming list audit?
How does Blocks handle a hotel’s own room codes like NQQ or 2QNS?
Will the audit report a name mismatch just because the hotel writes surnames first?
Can Blocks audit a scanned or faxed rooming list?
Does the audit change my rooming list automatically?
How much noise does the audit remove?
Where do I start an audit from?
Have more questions? Check our glossary of terms or get in touch.
Bring us your next room block.
See how your team can track deadlines, place guests, and check the hotel’s list in one live plan.