# How report calculations work (/docs/reporting/how-calculations-work) Every report in Resytech follows the same underlying rules for which bookings count, what "revenue" means, and which date drives the numbers. Understanding these rules makes it possible to reconcile numbers across reports and explain unexpected differences. Booking statuses — what counts [#booking-statuses--what-counts] A booking goes through these statuses over its lifetime: | Status | Meaning | | ------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Draft** | Pre-commit state — the customer has items in cart but hasn't completed checkout. Not yet a real booking. | | **Pending** | Customer has completed the booking but an operator hasn't manually confirmed it (or no auto-confirm is set). The booking holds inventory and has generated an invoice. | | **Confirmed** | The booking is fully accepted by the operator. | | **Canceled** | The booking has been canceled (by the customer, an operator, or automatically). | The revenue-recognition rule [#the-revenue-recognition-rule] Reports treat **Confirmed and Pending** as the bookings that count toward revenue, customer lifetime value, utilization, and similar money / activity metrics. **Draft and Canceled are excluded**. Why Pending counts: a Pending booking is a real obligation. It holds inventory, the customer has paid (or owes), and the invoice is real. If a report excluded Pending from revenue while including it in AR Aging, the two reports could never reconcile. So Pending counts everywhere. The "operationally active" rule [#the-operationally-active-rule] A few metrics (funnel counts, year-over-year *Bookings Created*) use a wider filter: everything except Draft. Canceled bookings still represent a customer who went through the booking flow, so they belong in the top of the funnel. This is called out per-report below. The cancellation rule [#the-cancellation-rule] The Operations report's **Cancellation Analytics** section deliberately filters to Canceled bookings only — the whole point is to measure cancellations. What "revenue" means [#what-revenue-means] There are several dollar amounts on a booking, and reports use specific ones. | Field | Includes | Excludes | | --------------- | --------------------------------------------------------------------------------- | -------------------------------------------------------------- | | **Subtotal** | Activity price, equipment price, add-on price, coupon discount applied | Tips, fees, taxes, trip protection, gift cards | | **GrandTotal** | Everything Subtotal includes, **plus** fees, taxes, trip protection, **plus tip** | Gift card credit (treated as a payment, not a price reduction) | | **TipAmount** | The tip the customer added (pass-through to staff — never operator revenue) | — | | **PlatformFee** | Resytech's per-booking platform fee | — | Business revenue (what reports show) [#business-revenue-what-reports-show] Every revenue metric in every report (except the dedicated **Tip Report**) uses **Business Revenue**, which strips tips out: ``` Business Revenue = GrandTotal − TipAmount ``` Tips are pass-through to staff — they're not money the operator earned. Including them in revenue would silently inflate every per-activity, per-customer, and per-location number. The Tip Report tracks tips separately so staff payout reconciliation has its own dedicated view. Net revenue [#net-revenue] Reports that show a Net Revenue figure use: ``` Net Revenue = Subtotal − PlatformFee ``` This represents what the operator actually keeps after Resytech's platform fee. Note that Subtotal already excludes tips (and excludes taxes and fees), so Net Revenue is naturally tip-free and tax-free. For per-equipment and per-add-on dashboards, Net Revenue is calculated from the line item slice only — the equipment portion (or add-on portion) of the booking minus a pro-rata share of the platform fee: ``` Equipment Net = equipment_line_total − (PlatformFee × equipment_line_total / Subtotal) ``` This means an equipment dashboard's Net Revenue can never exceed its Gross Revenue, even on multi-line bookings. What's NOT in any revenue figure [#whats-not-in-any-revenue-figure] * **Gift cards** — gift card credit reduces the amount due (i.e., it's a payment method), not a price. A booking paid by gift card still shows the full GrandTotal as revenue. * **Refunds** — refunds are tracked as a separate Refund Amount on the Revenue Report. They are *not* subtracted from Gross Revenue. (See the known inconsistency below.) * **POS sales** — the Reports section covers booking revenue only. POS sales are reported separately in **Dashboard > POS > Reports**. Date axes — which date drives the numbers [#date-axes--which-date-drives-the-numbers] Each booking has two dates that matter for reporting: * **CreatedAt** — when the booking was made (the "booking-on" date) * **StartDateUtc** — when the booking is scheduled to happen (the "service" date) Most reports filter and bucket by **CreatedAt** because operators usually want to see "the bookings we made in May" rather than "the bookings serviced in May". The Year-over-Year and Tip reports are deliberately different — see their individual pages. | Report | Filter date | Grouping date | | --------------------------------------------------- | -------------------- | ------------------------------------------------------------------------------------------------------------------------ | | Revenue | CreatedAt | CreatedAt | | Booking Analytics | CreatedAt | CreatedAt for period histograms; **StartDateUtc** for day-of-week and time-slot analysis (when does the booking happen?) | | Activity / Equipment / Customer / Location / Fiscal | CreatedAt | CreatedAt | | Year-over-Year — Bookings Created | CreatedAt | CreatedAt | | Year-over-Year — Bookings Serviced **and Revenue** | StartDateUtc | StartDateUtc (so the two lines on the chart reconcile) | | Tip Report | CustomerPayment.Date | CustomerPayment.Date (cash-recording window — manual tips added later land in the period they were recorded) | Refund-amount totals on the Revenue Report are an exception (see below). Known inconsistencies [#known-inconsistencies] These are quirks that *will* affect numbers and that operators should know about. They are not bugs — they are deliberate trade-offs. Revenue Report refunds use payment date, not booking date [#revenue-report-refunds-use-payment-date-not-booking-date] Gross revenue on the Revenue Report is filtered by **booking creation date**. Refund totals on the same report are filtered by **payment date** (when the refund was actually issued). The effect: a refund issued in May for a booking that was created in April shows up in the May Refund Amount but is *not* subtracted from any month's Gross Revenue (refunds aren't subtracted from gross anyway). The cell labels remain accurate but reconciling Refund Amount against Gross Revenue for the same period requires care. If this becomes a frequent operator complaint, the underlying refund filter can be switched to booking creation date — file a request. Tips appear in two places [#tips-appear-in-two-places] Tips are *not* part of business revenue on any report, but every dollar a customer pays *does* include the tip portion. The **Payment Method Distribution** on the Revenue Report and the **Tips Collected** on the Tip Report both reflect the gross customer payment. Don't add them together — the tip portion of a credit-card transaction shows up in both views. AR Aging snapshot vs date-range reports [#ar-aging-snapshot-vs-date-range-reports] The **AR Aging** section in the Operations Report is a snapshot at the moment the report runs — it shows every revenue-recognized booking with an outstanding balance, irrespective of the date filter on the rest of the report. The aging buckets compute days-outstanding from "now" against the booking's creation date. Utilization metrics are simplified [#utilization-metrics-are-simplified] The **Utilization Rate** shown on per-activity and per-equipment reports uses a simplified denominator (30 slots/month for activities, `quantity × 30 days` for equipment) rather than schedule-aware capacity math. Treat utilization as a directional indicator, not a precise percentage. The number is most useful when comparing items against each other within the same period. Examples [#examples] "Why does my Activity Dashboard show different revenue than the Activity Report?" [#why-does-my-activity-dashboard-show-different-revenue-than-the-activity-report] Both reports use the same revenue recognition rule. The most likely cause is date axis: the Activity Dashboard's headline KPIs are a fixed 30-day window based on the booking creation date; the Activity Report uses your selected date range. If the windows differ, the numbers will differ. "Why does my Revenue Report not match my POS report?" [#why-does-my-revenue-report-not-match-my-pos-report] The Reports section covers booking revenue (activity, equipment, add-ons, fees, taxes, trip protection). POS sales are tracked separately and don't appear in any booking-revenue report. To see total business revenue, combine the two. "Why are my Confirmed-only numbers different than before?" [#why-are-my-confirmed-only-numbers-different-than-before] Resytech now counts both Confirmed and Pending bookings as revenue-recognized. Reports that historically showed Confirmed only will appear higher by the value of pending bookings in the period. AR Aging and Revenue can now reconcile, where previously they could not. Related [#related] * [Revenue Reports](/docs/reporting/revenue) * [Booking Analytics](/docs/reporting/bookings-analytics) * [Activity Performance](/docs/reporting/activity-performance) * [Equipment Reports](/docs/reporting/equipment-reports)