Most hotel groups do not outgrow spreadsheets because the spreadsheet is bad. They outgrow it because procurement is a coordination problem, and a file cannot hold the state of a request, the authority of an approver, and the evidence of a delivery at the same time.
A single property can run purchasing through email, WhatsApp, and a shared workbook for a long time. The cracks appear when the group adds properties, centralizes purchasing, or has to explain a spend decision months later. At that point the question is no longer “where is the spreadsheet?” It is “which version is true, who approved it, what was actually delivered, and which property is paying for it?”
1. A request has no single state
In a spreadsheet workflow, a requisition can be “submitted” in one inbox, “approved” in a WhatsApp thread, “ordered” in a supplier email, and “received” in a delivery note that never reaches finance. Each person holds a different fragment of the truth.
Software fixes this by giving every request one explicit lifecycle. A practical state machine looks something like this:
- Draft — the department is still building the request.
- Submitted — the request is locked and routed for approval.
- Approved or rejected — an authorized person has made a decision.
- Ordered — purchasing has issued a purchase order to a supplier.
- Partially received or received — goods or services have been accepted.
- Closed — the invoice is matched and the request is complete.
The value is not the labels. The value is that every transition has an actor, a timestamp, and a reason. When a request is stuck, everyone can see where it is stuck and who needs to act.
2. The item master is the silent failure
Free-text item names are harmless in a small operation and corrosive in a group. One property orders “A4 paper 80gsm,” another orders “copy paper A4,” and a third orders a supplier SKU that nobody recognizes. Spend reporting becomes a taxonomy project instead of a report.
A usable item master does not need to be perfect on day one. It needs three properties:
- One canonical item with a stable identifier and unit of measure.
- Supplier mappings so the same item can be bought from different vendors under different names.
- A review path for new items, so the catalog grows deliberately instead of absorbing every typo.
The unit of measure matters more than most teams expect. Eggs by the tray, by the piece, and by the kilogram are not interchangeable. If the system does not normalize units, every comparison and every budget check is suspect.
3. Approvals do not match authority
A spreadsheet approval is usually a name in a cell. Real authority is more complicated: a department head may approve up to one threshold, a property general manager another, and group finance above that. People go on leave. Roles change. A property may be added to someone’s responsibilities without changing their job title.
The software model should separate people, roles, and scope. A user can be a department head at one property, an approver for two others, and a viewer at the group level. Approval rules should be evaluated against that scope, not against a hard-coded job title.
4. Receiving is where the audit trail dies
Many procurement systems stop at the purchase order. The operational reality continues: the supplier delivers half the order, substitutes one item, and promises the rest next week. The invoice arrives for the full amount.
A goods receipt note (GRN) closes that gap. It records what was actually accepted, what was rejected, and what remains outstanding. Three-way matching — purchase order, receipt, and invoice — is not an accounting nicety. It is the control that prevents paying for goods that never arrived.
Partial deliveries deserve first-class handling. A system that can only mark an order “received” or “not received” forces staff to lie to it, and the audit trail becomes fiction.
5. Reporting arrives too late to change a decision
Month-end spend reports are useful for accounting and nearly useless for operations. By the time the report arrives, the overspend has happened.
The reports that change behavior are closer to the work:
- Requests waiting on approval, grouped by approver and age.
- Orders past their expected delivery date, grouped by supplier.
- Items received but not invoiced, and invoices without a receipt.
- Spend against budget by property, department, and category.
- Suppliers with repeated rejections, substitutions, or late deliveries.
These are exception reports. They tell someone what to do next. A dashboard that only shows totals invites people to admire the problem.
6. What to build first
The temptation is to start with a large supplier portal or an analytics suite. The higher-leverage sequence is less glamorous:
- Make the request lifecycle explicit and auditable.
- Create a small, governed item master with supplier mappings.
- Model approval authority by role and property scope.
- Add receiving, including partial and rejected deliveries.
- Expose exception queues before building executive dashboards.
Mobile matters throughout. Department heads and storekeepers are rarely at a desk when a delivery arrives. If receiving takes five minutes on a phone, people will use it. If it takes twenty, they will sign the paper and reconcile later — which is how the audit trail disappears.
The real deliverable is a reliable handoff
Hotel procurement software earns its place when it makes handoffs visible: department to purchasing, purchasing to supplier, supplier to receiving, receiving to finance. The dashboard is a view of those handoffs, not a substitute for them.
A spreadsheet can hold numbers. It cannot hold accountability. That is the gap worth closing.