Wow, what a week. This year marked my 19th consecutive HITEC and it was by far the best. There was electricity in the air, along with a tropical storm. The educational sessions were top notch and the addition of vendor showcases was a great idea. And it was one of the busiest for me in the way of appointments made in advance with nine different vendors. I also had two HITEC first-timers with me this year. Deuce Sapp is our company’s IT director and Brad Good is the controller for the Galt House. I truly enjoy introducing new folks to the few people I have known through these years.
One of the areas that my team was focused on in our various vendor meetings surrounds the overly complex area of solid budget and planning tools that easily serve as an analytics platform. There are easily a dozen vendors reading this, and seeing my previous sentence, are getting ready to track me down to tell me about their application. Please don’t. My team is well down the road on vendor selection, but it is a road that has a number of unnecessary bumps.
So let’s get back to this open letter, which is to a subset of the various technologies running in today’s hotels. I’d like to address every vendor that has a revenue generation or payment settlement software application that was on display in Austin. This includes property management systems, point of sale systems, website booking portals, spa management systems, golf course tee time/retail systems, payment gateways, etc. There are many of you out there. And even those software applications that don’t specifically record financial transactions, they can have a direct impact. Think about revenue management, sales and catering, channel distribution, time and attendance, etc.
When my team met with several vendors about BI, budget and planning, and daily reports/dashboards we had a number of key requirements that we needed to consider. We wanted to make sure that data from any flavor PMS, POS, etc could be funneled into the solution as well as make sure we had absolute data integrity between daily reports and monthly financials. My focus has always been to bring greater transparency between the numbers presented in our guest facing systems and those that end up on the monthly financial reports to owners and management companies.
The path this data follows from “the front door to the board room” is often interrupted by translation tables, interfaces, auditing and finally posting into the general ledger. Every software vendor seems to approach things differently and give folks like me the flexibility to stage the data any way I want. But that is the approach that has existed for too long. I learned it as ETL – Extract, Transform, and Load. What a nightmare that simple phrase conjures up — and maybe I don’t want to spend the time describing to you what I want from your system.
When you are in the finance area of this industry you focus on presenting financial statements in the standardized format outlined in the Uniform System of Accounts for the Lodging Industry (USALI), now in its 11th edition. There was a great deal of changes in this edition that the chains committed to following, both in statistics and in financial reporting design.
Who do you think has to translate the daily revenue system data into the correct general ledger accounts to adhere to these standards? Finance.
When finance needs to look for a solution that can provide meaningful and accurate management information that also retains data integrity under USALI, the initial setup is always the beast. Then every time one of these source systems gets a new transaction code, or rate code, or job code, something goes awry because some table somewhere didn’t get setup correctly.
Here’s my proposition.
If you have a software application that is designed to record financial transaction then you have been asked to have it interface either the general ledger or another intermediate system, or else someone is transcribing the end of day revenue/settlement summary into a journal entry. (Raise your hand if you have ever balanced an NCR 926 Z reading and filled out the “D” card.)
If there is an interface, it is usually a non-elegant table set up somewhere in the process. It might be a table in the sending application, or in the receiving application, or sometimes requires a separate application to translate. But tell me why your application, that starts the data accumulation, can’t come designed to be USALI-ready right out of the box. In other words, the end of day summary of revenues, settlements, and statistics should come pre-formatted in the logical sequence and categorization outlined in USALI.
As a long-time member of HFTP, the producer of HITEC, and contributor to keeping USALI relevant and current, I think the time has come for the finance side of the association to ask the technology side of the association to embrace USALI as a common language when designing data flow tied to financial reporting or even right down to the descriptions used in canned reporting.
With all due respect, there are a number of vendors that openly used USALI on their booth displays. One vendor we met with has a tool that has over 200 USALI-standard metrics defined in its company package. Another vendor that offers a great BI tool for daily reports and dashboards ensures data integrity to the general ledger by being the intermediate application that prepare the journal entry. But both of these tools will still require that we design an ETL process up front.
I look forward to the day when you can walk into a PMS vendor’s booth and to see a copy of the company’s USALI-compliant daily journal entry. Same for the POS vendors. And maybe someday the market leading sales and catering software will “post” a banquet check directly to a PMS master account.
Articles By The Same Author: