Why status matters more than it seems
A booking that's been quoted, one that's been confirmed with the supplier, and one that's been fully paid are three very different things — but in a spreadsheet, they often look identical: a row with a customer name and a date. Without a clear status attached to each one, it's easy to treat a draft as if it were confirmed, or to invoice a customer before supplier availability was actually locked.
The consequences range from mildly embarrassing (telling a customer a hotel is confirmed when it isn't) to genuinely costly (paying a supplier for a booking a customer later cancels, because nobody updated the status in time).
What good status discipline looks like
A booking should move through clear, visible states — draft, confirmed, invoiced, paid — and every person touching it should be able to see which state it's in without asking. That visibility is what prevents the two most common status-related mistakes: acting on a draft as if it were final, and forgetting to move a confirmed booking forward once payment comes in.
Why this needs to be enforced, not just documented
Writing a policy that says "don't invoice drafts" only works if the tool people use makes drafts visually and functionally distinct from confirmed bookings. If a spreadsheet lets someone type an invoice number into a draft row, someone eventually will, especially under time pressure.
How Muhasib enforces it
Muhasib's booking pipeline gives every booking an explicit status — draft, confirmed, invoiced, paid — and the invoicing and purchase-order actions are only available once a booking is actually confirmed, so the system prevents the mistake structurally instead of relying on staff to remember a rule.