# Tip Report (/docs/reporting/tip-report) Overview [#overview] The Tip Report is for staff payout reconciliation. Access from **Dashboard > Reports > Tips**. Tips are pass-through to staff and never operator revenue. Every other report on the dashboard strips tips out of business revenue (see [How report calculations work](/docs/reporting/how-calculations-work)). The Tip Report is where tips actually live as a first-class metric. What this report counts [#what-this-report-counts] * **Payments counted**: customer-payment rows with a non-zero tip portion. * **Refunds counted**: customer-payment rows that represent a tip refund (negative tip amounts). * **Date axis**: **payment date** (`CustomerPayment.Date`), not booking creation date. A manual cash tip recorded two weeks after the booking lands in the payout window when it was recorded — which is what you want for paying out staff. * **Booking statuses**: every status — the report's filtering happens at the payment-row level, not the booking level. If a tip exists on a payment row, it counts. Summary Metrics [#summary-metrics] | Metric | What it is | How it's calculated | | -------------------------- | -------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | | **Total Tips Collected** | Gross tips received in the period | Sum of positive `TipAmount` values across payment rows in the period | | **Total Tips Refunded** | Tip refunds issued in the period | Absolute sum of negative `TipAmount` values across payment rows in the period | | **Net Tips for Staff** | Money to pay out to staff | Sum of `TipNetOfStripeFee` for payment rows where this is set, plus tip amounts on manual payments | | **Stripe Fees on Tips** | Processing fees that came out of tips | `Total Tips Collected − Net Tips for Staff − Total Tips Refunded` (approximately — depends on which rows have Stripe-fee allocation) | | **Tip Participation Rate** | Share of recognized bookings that included any tip | Bookings with a non-zero `TipAmount` ÷ all recognized bookings in the period, as a percent | Net vs Gross [#net-vs-gross] **Net Tips for Staff** is the headline number — it's what you owe your team for the period. It excludes: * **Refunded tips** — already returned to the customer. * **Stripe processing fees** allocated to the tip portion of card payments. Resytech apportions a fair share of the Stripe fee to the tip side of the payment so the operator isn't subsidizing the processor's cut of the tip. Manual payments (cash, check, electronic, other) have no Stripe fee allocation — the full tip amount on those rows is staff-owed. Tips by Period [#tips-by-period] A trend chart with two lines — gross tips collected and net tips for staff — so you can see how much of the gross is going to processing fees or refunds over time. * **Group by** controls the period bucket (day, week, month). * Each data point uses `CustomerPayment.Date` for bucket assignment. * Signed values: payment-in rows contribute positively, refund rows contribute negatively. Tip Detail Table [#tip-detail-table] A per-booking row for every tipped booking in the period: | Column | What it is | | --------------------- | ------------------------------------------------------------------- | | **Customer** | Customer name (or "Guest" if anonymous) | | **Activity** | The activity on the booking | | **Source** | Booking source (website, manual, etc.) | | **Confirmation Code** | For looking up the booking | | **Service Date** | `Booking.StartDateUtc` | | **Tip Amount** | Sum of `TipAmount` across this booking's payment rows in the period | | **Refunded Tip** | Sum of refunded-tip rows for this booking in the period | | **Net Tip** | Tip Amount − Refunded Tip − Stripe fee allocated to this tip | CSV export is available from this table — useful for handing off to payroll. Filters [#filters] * **Date range** — filters payment rows by `CustomerPayment.Date`. * **Activities** — narrow to specific activities (filters by the booking that the payment row is associated with). * **Sources** — filter by booking source. * **Booking statuses** — explicitly filter by booking status (defaults to no filter — every tipped booking shows). * **Group by** — `day`, `week`, or `month` for the trend chart. Why payment date, not booking date? [#why-payment-date-not-booking-date] Operators typically need to pay tips out on a regular cadence (e.g., biweekly). If a cash tip is recorded on March 15 for a booking that happened on March 1, the payout that covers March 11–25 should include that tip — regardless of when the booking itself was created. Using payment date solves three problems: 1. **Manual tips added later** land in the period they're recorded. 2. **Refunds issued in a later period** correctly subtract from that period's net (not retroactively from the booking-date period). 3. **Stripe fee allocation** happens when the `charge.updated` webhook fires, which is when the payment-row's `TipNetOfStripeFee` gets populated — by payment date. Reconciling with the Revenue Report [#reconciling-with-the-revenue-report] The Revenue Report's **Payment Method Distribution** section shows total gross customer payments, including tips. The Tip Report's gross tips total is a *subset* of that. Do not double-count: if you're computing total operator revenue, use the Revenue Report's Gross Revenue (which excludes tips). If you're computing total cash flow, the Operations report's Payment Methods section is the right source. Related How-To Guides [#related-how-to-guides] * [Run a Tip Report](/how-to/reporting/run-tip-report) * [How report calculations work](/docs/reporting/how-calculations-work)