Most guidance on faster hotel closes stops at the payoff: clean daily revenue data, automated variance flags, a close that finishes on day 7 instead of day 12. What almost nobody walks through is how that daily data structure actually gets built in the first place: the configuration work that turns a general ledger into a report that tells a Controller, every single day, whether the property is on plan.
This is that piece. If you’re setting up a new property on DP Finance, standardizing reporting across a portfolio, or just inheriting a report structure you didn’t build and want to understand, this is the mechanic underneath the Daily Revenue Report (DRR) and Daily Labor Report (DLR), and it’s the same mechanic in both cases.
The Core Model: Segments, Groups, and Metrics
Both the Daily Revenue Report and the Daily Labor Report are built on a single underlying framework in G/L File Maintenance, under General Ledger > Maintenance > Daily. There are three building blocks, and they stack in order:
Segments pull together one or more G/L accounts that should be treated as a single line on the report. For example, every account related to Transient rooms revenue, or every account posting housekeeping labor. A Segment is the smallest reportable unit; it’s where you connect the report back to your actual chart of accounts.
Groups organize Segments into the lines that print on the report. A Group can hold a single Segment or several, and you control whether the report shows every Segment individually or just the Group’s total (the “Totals Only” setting). Groups also carry a Type, Currency or Units, which matters more than it sounds like: a labor Group set to Units tracks hours, not dollars, and that distinction is what makes labor-productivity metrics possible later.
Metrics are calculations performed between two Groups, or between a Group and a constant. This is where Average Daily Rate, RevPAR, Occupancy Percentage, Average Check, and labor cost percentages actually get defined. A Metric doesn’t hold its own data; it references two Groups and a calculation, and the report engine does the math when the report runs.
Once Segments, Groups, and Metrics exist, they’re assembled into an actual report through Report Control, which defines a Report Code and Report Type (Daily Revenue, Daily Labor, Daily Executive, or Check Book Accounting), and then a set of Report Rows that determine what prints, in what order, and in what format — text headers, Group lines, or Metric lines, each with its own currency format, font style, and totals behavior.
Building a Segment: Connecting the Report to the G/L
Segments are created under Daily Revenue Segments. Each one gets a Segment ID and description, and then you attach G/L accounts to it using a filter screen. Search by account range, description, or other criteria, select the accounts that belong together, and save. A Segment for “Transient Rooms” might pull from a single account; a Segment for “Banquet Food Revenue” might roll up half a dozen accounts across different outlets.
This is also the step where labor reporting introduces a wrinkle worth knowing about ahead of time: for the DLR2 report format specifically, every Group should be built twice: once against a Segment measured in currency, once against the same accounts measured in units (hours). The convention is to append a “D” or “U” suffix to distinguish them. The reason is straightforward once you see it: you can’t calculate “labor cost per occupied room hour” from a currency-only Group, and you can’t calculate a straight dollar variance from a units-only Group. Having both available is what lets a Metric compute either kind of ratio later.
Building a Group: Deciding What Prints and How
A Group requires a Group ID, description, Type (Currency or Units), a decimal Format, and a Reverse Sign setting (used when a naturally credit-balance account needs to display as a positive number, or vice versa). Once saved, you attach Segments to the Group, as many as needed, and control the print order with Move Up / Move Down.
The Totals Only setting on the Report Row (covered below) is what determines whether a reviewer sees each Segment’s detail or just the Group’s bottom line. A Controller reviewing a summary flash report might want Totals Only; someone doing a line-by-line variance investigation during close week wants every Segment visible.
Building a Metric: Where the Real Analysis Happens
Metrics are where a daily report stops being a data dump and starts being an analytical tool. Each Metric requires a Metric Code, a Format, and an Operator (the calculation performed between the two referenced Groups), plus optional fields for description, symbol, and Reverse Sign.
The Group Information section is where the calculation is actually defined: you specify a Group Type (whether each side of the calculation references an actual balance or a budget/estimate), the Group ID for each side, and two optional fields that matter specifically for labor analysis:
- Days Back — pulls a value from a prior date rather than the current one. This solves a real timing problem in hotel labor reporting: a salaried employee’s cleaning labor might post on Tuesday, but the room they cleaned was actually occupied Monday night. Days Back lets a Metric compare Tuesday’s labor cost against Monday’s occupancy.
- Divide By — divides a Group balance by a fixed number to produce a Full-Time-Equivalent value. If three housekeepers’ hours post to one account and a full-time schedule is 8 hours, dividing that Group’s balance by 8 converts total hours into FTE headcount.
Two worked examples make this concrete.
Example 1 — A labor cost percentage. To show housekeeping labor cost as a percentage of rooms revenue, you’d build a Metric referencing the housekeeping labor currency Group (Group 1) and the rooms revenue Group (Group 2), with a Percentage operator. Because rows can be flagged as Budget or Actual, the same Metric structure produces both a Daily Actual labor-cost-% and a Daily Budget labor-cost-%, side by side, which is exactly the comparison a department head or Controller needs to catch a labor overage before it compounds across the month.
Example 2 — Revenue per Available Room (RevPAR). RevPAR is a Metric dividing a rooms revenue Group by a rooms-available Group (frequently a constant rather than a variable G/L balance, since room count rarely changes mid-month). The same underlying logic — Metric = calculation between two referenced values — produces ADR, Occupancy Percentage, and Average Check on the same report using the same mechanism, just with different Groups on either side.
Assembling the Report: Report Control and Report Rows
With Segments, Groups, and Metrics defined, Report Control ties them together into something that actually generates. You create a Report Code, assign a Report Type, and then build Report Rows one at a time. Each Row is either a Text line (a header or label), a Group line, or a Metric line, and each carries its own currency format, unit format, calculation format, font style, underline setting, and Totals Only flag.
Row order in the grid determines print order on the finished report, and it can be reordered at any time with Move Up / Move Down, so a report structure isn’t locked in once it’s built. If ownership wants labor detail moved above F&B revenue, or a new Metric added between two existing Group lines, that’s a Report Row change, not a rebuild.
This is also the level at which budget vs. forecast vs. actual columns get populated. A well-known example already in use across the standard report library is the DRR12 “Budget Forecast Comparisons” format, which adds explicit Daily, MTD, and YTD Actual-vs-Budget and Actual-vs-Forecast variance-percent columns next to the raw dollar figures with the same Group/Segment/Metric structure described above, just laid out with variance math built into the Report Row formatting. That’s the layer that turns a daily report from a record of what happened into an early-warning system for what needs review before close.
Why the Existing Format Library Matters
You don’t need to build every report from scratch. There are currently 15 standard Daily Revenue and Daily Labor report formats (DRR1 through DRR12 and its variants, DLR1 through DLR3) available as starting templates, each with its own predefined column set and row logic. If none of the existing formats fit a specific reporting need, additional custom formats can be requested through Data Plus Support.
Choosing the right starting template rather than reinventing a Segment/Group/Metric structure that already exists is usually the fastest path to a working daily report, with custom Metrics layered on top for anything property- or portfolio-specific.
The Payoff: Daily Structure Is What Makes Close-Week Review Possible
None of this is done during the close-week. It’s usually done once per property and refined occasionally as departments or reporting needs change. But it’s the reason daily revenue and labor validation can happen in minutes rather than hours: once Segments are mapped to the right G/L accounts, Groups are rolling them up correctly, and Metrics are calculating the ratios that actually matter (labor cost %, RevPAR, ADR, occupancy), a Controller reviewing a daily report is confirming numbers that are already organized the right way, not reconstructing them from a raw trial balance every morning.
If you’re setting up a new property, onboarding a newly acquired hotel onto a standardized portfolio structure, or auditing an existing report that was configured by someone who’s since moved on, this is the layer worth getting right. It’s also where Data Plus Support can help directly, whether that’s walking through a Segment/Group/Metric build for a property-specific reporting need or scoping a new report format that doesn’t yet exist in the standard library.
