Date > Sales Summary Reconciliation > Variations


  • Operators
  • Sale/payment/allocation date range
  • Isolate web payments (Yes/No)
  • Display inside charges (Yes/No)
  • Include additional production detail (ID, start date, account code) (Yes/No)

These reports show all sales made within the selected date range. Information is broken down by sale item/event and then payment type. The reports list the seat count (quantity) and gross takings for each item/event.

The sales summary reconciliation reports by the date the sale was created (not the date seats were added or changed, nor the date that payments were added).

The first part of the report shows payment allocations, i.e. seats (broken down by production) and products (broken down by product type) that have been marked as paid and for which a payment has been allocated. This section does not include reserved but unpaid seats, nor unbalanced sales.

The 'value' totals are the amounts allocated (if a $30 seat only has $15 payment allocated to it, it appears in the report as $15). The 'quantity' totals are ticket/product counts (in the case of products, it’s a sum of the product 'quantities'. Therefore, if a programme product appears on the sale as quantity = 2, this counts as 2, even though there is only one line item on the sale.

The second part of this report show payments only, subtotalled by payment type. Credit-card payments are grouped together and subtotalled. The 'value' totals are payment values, regardless of whether or not they are allocated to anything. Refunds are counted negatively against subtotals/totals. The 'quantity' totals are payment counts, not seat/product counts.

The 'quantity' total for the first part shouldn't be compared to the 'quantity' total of the second part. One is a total of seats/items, the other is a total of payments/refunds (refunds count as negative in this total).

The 'value' total for the first part will match the 'value' total for the second part if and only if the total of payments matches the total of allocations. Unbalanced sales will make them not match (i.e. payment added but seats/items not marked as paid, or seats/items marked as paid but no payment entered).

As these reports are by sale date only, their totals probably won't match reports that are by:

  • Allocation date
  • Payment entry date
  • Payment entry shift
  • Seat paid date
  • Seat paid shift
  • Booked/sold reports (they include unpaid seats, and usually report on ticket prices, not amounts actually allocated)
  • Production (they only report on a single Production, not usually a date range)
  • Performance (they are usually by performance date)

Editing sales after-the-fact (e.g. fixing up unbalanced sales) will change the totals in these reports. This means you can make a non-balancing report balance, and it also means that subsequent operator changes can unbalance the report.