How do you move an existing hotel chart of accounts to USALI?

You map it rather than rebuild it. Every GL code stays as it is, and each one is linked once to the line of the Uniform System of Accounts for the Lodging Industry (USALI) where it belongs. The management accounts are then produced in the USALI layout from the ledger you already have.

It is the same idea as the spreadsheet most financial controllers already use to turn the trial balance into management accounts, where each account feeds a row of the report. The difference is where the links point, and what happens to the history when one of them changes. In the SSOT Platform the FC makes those links herself, account by account, and the P&L builds in the USALI layout as she goes.

This is Part 3 of USALI for independent hotels, from the general ledger up. Part 1 made the case that a standard accounting package produces an accurate P&L but not a departmental one. Part 2 described the shape the standard gives a hotel’s accounts. This chapter is about getting an existing ledger into that shape, which is the question almost every hotel actually has. Very few get to start from a blank chart of accounts.

Why not rebuild the chart of accounts?

Because rebuilding is the hard way, and it still leaves you needing a mapping.

Short of changing accounting software, which is a different project altogether, a new chart of accounts means creating a whole new set of GL codes. The old ones do not go away. While they hold postings, most systems will only let you close them off, so the ledger ends up carrying two numbering schemes side by side. Whoever posts the invoices and journals has to learn the new numbers without slipping back to the old ones, and any bank rules that post automatically have to be repointed.

Nor does the history move with you. Last year’s postings stay under the old codes and this year’s go under the new ones. To show this year beside last year, someone has to build a table saying which old code became which new one. So a rebuild still ends up needing a mapping; it just maps the old ledger to the new one instead of to USALI.

The table is the clue. Point it at the USALI layout instead of at a new chart of accounts and you get the result without the upheaval: nothing in the accounting system changes, and nobody learns a new code. This is also the recognised route to USALI in practice. Each GL account is mapped to a USALI category, so the statements come straight from the ledger without being reclassified by hand. The stronger claim you will sometimes read, that USALI has to be applied posting by posting as each transaction is entered, does not stand up.

What shape should the ledger be aiming for?

The target is your management accounts in the USALI layout, for the departments you actually operate. Part 2 explained why a 70-room hotel produces a handful of departmental schedules, not the dozens the book has room for.

Within that, keep as much detail as you find useful. The standard itself encourages hotels to add sub-accounts that reflect their own circumstances, provided each one rolls into a standard line item (USALI, 11th revised edition, introduction). Your ledger may hold several accounts for what the statement shows as one line, and that is exactly as it should be.

The rule that matters runs the other way. The ledger can be more detailed than the accounts, but never less. A mapping can add accounts together. It cannot divide one. If a single account holds two kinds of cost that the standard reports on different lines, no mapping can put each part where it belongs.

Two practical notes. Departments do not have to live in the account number: many accounting systems carry them as a separate dimension, a cost centre or department code, and the mapping reads the account and the department together. And a hotel starting from scratch can simply build its ledger in this shape from the first day. Most hotels are not in that position, so the rest of this chapter is about the ledger you already have.

What actually changes: map, remap or split?

Where the mapping sits over your ledger’s history rather than over a single month’s totals, every existing account falls into one of three cases.

• Map it as it is. Most accounts. Linked once, and the full history arrives in the new layout.
• Remap a whole account. For example, an account of card processing fees that had been reported under Rooms, moved to Administrative and General (A&G). The link applies to every period, so past postings, and any budget held against the account, move with it.
• Split a mixed account. For example, card fees sitting inside a commissions account, given their own code. The new code starts in the month it is created, and earlier postings stay where they were.

The first two carry no penalty at all. Correcting where an account points costs you nothing, because its whole history follows the correction. Only the third, splitting an account that holds two kinds of cost, has to wait for its history to build up, and only on the lines that account feeds.

So the real work in moving a ledger to USALI is finding the accounts that mix things together.

Where do mixed accounts usually hide?

In our experience, most often in distribution costs.

An account called something like Commissions and Booking Fees is tidy, and it matches how the invoices arrive. It also tends to collect commission from several online travel agents, per-booking charges from booking systems, a channel manager subscription, the odd meeting-planner commission and sometimes the card acquirer’s fees. The standard puts those on at least four different lines, in more than one department. Once a year of invoices has gone into that one code, nobody can separate it again with confidence, and the ledger cannot tell anyone what each booking channel actually costs.

The test: what you paid for, not who you paid

A single supplier routinely produces costs that belong on different lines. So code from the invoice line, never from the supplier’s name, and where one invoice holds more than one kind of cost, split it. Four questions, in this order:

1. Did a third party sell the room and take a cut? Rooms: Commissions. An agent secured business you would not otherwise have had.
2. Was it charged per booking by the system that carried it? Rooms: Reservations. You generated the demand; the system only transmitted the booking.
3. Is it a licence or subscription, payable whether or not you sell? Information and Telecommunication Systems (IT systems). A systems cost, not a cost of distribution.
4. Did it buy exposure rather than a booking? Sales and Marketing. Demand generation, incurred whether or not a room is sold.

Three cases sit alongside those questions:

• The cost of collecting a card payment belongs in Administrative and General. It is incurred on every card payment, whichever channel the booking came through. Left in Rooms, it understates that department’s profit.
• Group and meeting-planner commission has its own line within Rooms. It lands on larger, lumpier bookings, and mixed with transient commission it distorts both rates.
• Commission follows the department that earned the revenue. Commission on food and beverage business, and cover charges from restaurant booking platforms, belong in food and beverage. The sensible exception is agent commission on a package that includes the room, which stays wholly in Rooms, because apportioning it costs more than it is worth.

When there is no expense at all

Where an agent takes the guest’s payment and passes on a net rate, nothing is invoiced to you. The agent’s margin is already inside the rate, you never see what the guest paid, and the revenue is recorded at the net amount received. The same applies to wholesalers, bed banks and tour operators on net contracted rates. This follows the standard’s own guidance on gross and net revenue.

Grossing any of these up to a notional full rate is tempting, because it makes the average rate look better. It overstates revenue, ADR, RevPAR and expenses all at once, by creating a commission that was never paid.

Worked example: one account becomes seven

An illustrative 74-room hotel, twelve months, one account holding €84,300.

Nothing about the total cost has changed, and neither has the bottom line. What has changed is that €12,850 has left the Rooms department, where it had been understating departmental profit every month, and the rest can now be attributed to the channels that caused it.

How far to split is a judgement. The rule of thumb we use: give an agent its own account once it represents 5% or more of rooms revenue, or costs €10,000 or more in commission a year, whichever comes first. Everything below that shares one account. For a typical Irish independent, that means three to five new codes in total.

The invoice behind most miscoding

In our experience, the most common single source of miscoding is not the commissions account itself but one invoice: the channel manager’s.

One document, one supplier, one payment. Only €1,712 of it is a cost of distribution, and only that figure belongs in the Rooms department, where it will one day be compared with other hotels’ figures.

Four traps

• One supplier, one account. An account named for its suppliers rather than for what was bought holds several lines by construction, and cannot be unpicked afterwards.
• One agent, one treatment. The same agent can sell your rooms both ways: sometimes collecting from the guest and passing on a net rate, sometimes leaving you to collect and invoicing commission. Record the two as separate arrangements, because a euro of revenue means something different in each.
• A payment service is not a net-rate booking. Where an agent only processes the guest’s card payment on your behalf and still invoices commission, your revenue is gross and the commission is a real expense.
• Posting the remittance net. Where the guest paid you and the agent invoices separately, netting the two into one line erases the commission from your accounts, and understates rooms revenue with it.

A short reference

The standard’s own expense dictionary is the authority on anything not listed here.

What happens to last year’s figures when you split an account?

A split account’s new code has no past. Its history starts the month it is created, and the earlier postings stay in the old account. That has three consequences, each worth knowing before you start.

Budget comparisons can work from the first month, provided the budget is set in the new structure.

Comparisons with the same month last year arrive twelve months later. A full year against a full year arrives at the second year end, unless the split happens at the start of a financial year.

Where the split moves cost between departments, last year is on a different basis. Move card fees out of a Rooms commission account and into Administrative and General, and from that month the Rooms department stops carrying them. Last year’s Rooms figures still do. Nothing is wrong on either page, yet this year’s Rooms profit looks better than last year’s for a reason that has nothing to do with how the department was run. The fix is one sentence in the commentary saying so.

The tempting alternative is to estimate how much of last year’s account was card fees and move it across. Resist it. An estimate that looks like a measurement is more dangerous than a gap: it becomes the baseline that every later comparison leans on, and when real figures arrive, a change of method reads as a change in performance. The standard itself acknowledges the problem, noting that comparisons in the first year of adoption may be distorted where historical data cannot be adjusted (USALI, 11th revised edition, introduction). It offers no licence to invent the missing history, and neither should anyone else.

Some history is recoverable honestly. Rooms sold and revenue by channel usually come straight from the property management system for past periods, so channel mix and the gross rate by channel are available from the start. The net cost of each channel only exists from the month the ledger carried the detail.

Which is the best argument for splitting as soon as you can. Waiting for a tidier date only moves the day the comparisons catch up.

The route, in five steps

1. List the accounts that carry postings in the periods you want to report. That list is the scope of the job, and it is usually shorter than the chart of accounts suggests.
2. Link each account to the USALI line where it belongs. The standard’s expense dictionary settles most arguments about where a cost goes. Any extra detail you want can stay, as long as it sits beneath a USALI line.
3. Find the accounts that mix two kinds of cost the standard reports on different lines, starting with distribution costs. Give each part its own code, as soon as you can.
4. Correct any account linked to the wrong line by changing the link, not by reposting. Where the mapping sits over your history, the correction covers every period.
5. Where a split has moved cost between departments, say so in the commentary, and never estimate a split nobody recorded.

After that, the GL carries on as it was: same codes, same postings, same audit trail, reporting in the layout the rest of the industry uses.

This is how the SSOT Platform is built. The FC does the linking herself, in a mapping screen with the coding guidance beside it. The P&L builds in the USALI layout as each code is linked, so every link can be checked the moment it is made. A changed link carries the account’s history and budget with it, and any line opens to the postings behind it.

A structure that outlives whoever built it

Part 2 argued that the real reason to adopt USALI is that the thinking has already been done: a hundred years of argument about where a cost belongs, written down. A ledger mapped once to that standard carries the reasoning with it. The next FC inherits a structure that explains itself, rather than a file and a set of habits.

Part 4 works out what each booking channel actually costs, and what that does to your ADR.

Three questions to take back to your own ledger:

• Which of your accounts hold more than one kind of cost?
• If the owner asked tomorrow what each booking channel cost last year, could the ledger answer?
• When a department’s margin improves next year, will you be able to say whether the department changed, or the accounts did?

USALI (the Uniform System of Accounts for the Lodging Industry) is published by HFTP. SSOT Analytics is independent of HFTP. This series explains the concepts in our own words; for the authoritative text, buy the 12th edition at usali.hftp.org, or in the UK and Ireland via hospa.org. There is no substitute for reading the book.

If the first question has an uncomfortable answer, that is the place to start. Talk to us about making your hotel’s reporting benchmark-ready, or follow the series and do it yourself.

Colin Donovan has spent 30 years in hotel finance, as financial controller, general manager and managing director. He is the founder of SSOT Analytics, which builds USALI-aligned financial reporting for independent hotels.