Starting in Versai v5.0.0.x, the new Revenue report (a/k/a Revenue by Payment or General Ledger Account) replaces the old Revenue by General Ledger report, Payment Listing for Admissions report, and Payment Listing for Gift Shop report. It is currently as labeled as BETA, so the data should be carefully reviewed each time before making entries in your accounting software.

The new Revenue report offers many exciting changes that clients have requested for years! In order to bring those to fruition, the report–and the actual underlying transaction data–had to be completely rewritten from the ground up. The result is a new report that looks very different and works differently. This means you should explore the new options and expect to adapt your daily bookkeeping procedure. While there may be a learning curve that takes some time, in most cases the growing pains will pay off in efficiencies. For example, you can see the details for tax and what was purchased all on the same report, instead of having to run the Taxes report, Inventory Movement report, or Sales Detail report separately.

New features

• Deeper level of detail and better payment matching to sale lines: Instead of seeing only summary totals, you can now see the individual amounts that make up the totals and see which payment portions matched which sale lines. This allows for better understanding of the data and easier reconciliation. The report logic and calculations to create these matchings/distributions, referred to as “Allocations,” has been completely redefined, so figures from the old report will not match figures on the new report. For example: When there are multiple payments on a transaction, each payment will be matched to lines that add up to the payment amount on the new report, rather than all payments being evenly divided across all lines (i.e. each payment pays for a little of each line) on the old report.
• Revenue from all Business Areas shown side-by-side: The new report shows revenue from all Business Areas (i.e. Versai “tabs”) together. In comparison, the old report separated each Business Area onto its own page and only brought them together on the last page as a summary. For example, the same GL Account could be shown once on each page of the old report but not totaled until the last page, which was far from the numbers that were creating those totals.
  • This allows you to more dynamically analyze the revenue, as well as eliminates confusion about membership and donation revenue that could be shown under multiple Business Areas.
  • The Business Areas can still be separated as a level of detail (i.e. report headers) with subtotals by selecting a Report Format that lists “Business Areas,” but that is now optional, rather than unavoidable.
  • There is also a new option to filter by Business Area based on where the payment was entered, instead of always getting all Business Areas.
• Find a certain record by its number: There is a new option to filter by a specific sale number, gift (membership/donation) number, check number (matches full number), credit card number (matches last four digits), or gift card (matches partial numbers).
• Ecommerce payments filter: There is a new quick filter to see only ecommerce payments or remove them, which is easier than using the Cashiers or Machine filters to accomplish the same result (though those filters are still an option).
• Improved GL Accounts filter: The filter on the old report only showed the predefined accounts from Admissions. The new report includes the “write-in” accounts from other Business Areas. It also gives the option to filter revenue that is not assigned to an account: “_No GLAccount” represents when the account was not defined in the setup area. “_Payment w/o Sale Line” represents when a transaction has an unresolved overpayment, so a part of the payment does not have a sale line to tell it which account to belong to. (See also: Set Up General Ledger Accounts)
• Improved Accrual Basis entries for Unearned and Receivable: Clearly see amounts move in and out of both Unearned and Receivable on appropriate dates.
  • In addition, “placeholder” payments for Receivables in Admissions are now permanent and offset by additional Receivable payments that are negative versions of “real” payments when received. This is instead of simply removing the original Receivable payment once the amount is paid. Receivable transactions will stay labeled as receivable for easy location later.
  • Cash Basis omits all Unearned entries and all Receivable entries and shows only the entries of actual payments on the dates they are entered.
• History of changes to transactions: If a cashier edits a sale (or gift record) that already has a payment, then existing Allocation records on the past date will be offset by (1) new Allocation records that are negative copies of the existing values on the date of the change (not the past date) and (2) new Allocation records with the new values on the date of the change. This method reduces the frequency of reports for past dates changing after the fact and reduces the need for re-running past reports because the changes are reflected on the change date rather than past date. This new feature is in its infancy and will continue to be developed in the future.
• New list of Report Formats: Report Formats represent how the data is subtotaled (sectioned into headers) and sorted.
  • From one Report Format to another, the grand totals stay the same. Report Formats only control the organization and detail for the records included on the report, but which records themselves are included stay the same when only changing the Report Format. In contrast, filters (a/k/a “parameters”) control which records are included on the report.
  • Because the report–and the actual underlying transaction data–has been completely rewritten, the data can now be analyzed and presented in new exciting ways not possible on the old report!
  • But for the same reasons, some of the old Report Format options are no longer valid or possible. You’ll need to explore the options available, select which one(s) will work best for you, and then adapt your daily bookkeeping procedure to use it.
• Graphs! There is a new Report Format that shows graphs of the revenue by Revenue Type, by Payment Method, and by GL Account.

How it works

1. General Ledger Account Numbers (“GLA”) are defined on each item sold (e.g. tickets, merchandise, memberships, donations, fees), referred to as “sale lines.” The GLAs are not recorded on the payments, themselves, that are entered into Versai. But: when cashiers enter payments, it’s at the level of the actual transactions as a whole; they do not enter payments on individual sale lines within transactions. Therefore: in order to analyze revenue by GLAs, the payments received need to be matched and distributed to the sale lines.
2. When a sale with a payment is exited, the payment is applied to what it is paying for.
   • If only one payment is paying for only one sale line, it’s a one-to-one ratio. Such is the case for memberships and donations entered through the Development and Membership tabs.
   • When there are multiple payments paying for only one sale line (a one-to-many ratio), the one sale line value must be broken apart across the payments.
   • When there is one payment paying for multiple sale lines (a one-to-many ratio), the one payment value must be broken apart across the sale lines.
   • When there are multiple payments paying for multiple sale lines (a many-to-many ratio), each payment value must be (a) applied to one sale line covering the whole value, (b) applied to only part of the one sale line’s value, or (c) broken apart across multiple sale lines.
   • In cases of the many-to-many ratio, payments are attempted to be matched to sale lines in the following order: (1) match the whole payment value to the whole (price + tax) sale line value, (2) match the whole payment value to just the price value of the sale line (or just the tax value of the sale line), and then (3) distribute the first unmatched payment over unmatched sale lines–in order of memberships, donations, gift cards, and then chronology–until that payment is exhausted before moving to the next payment (as opposed to distributing all unmatched payments evenly over unmatched sale lines).
   • Sometimes when a transaction has an unresolved overpayment, there will be a remaining portion of the payment does not have a sale line to match to. Without a sale line, there is no GLA to attribute it to, so it will be labeled as “_Payment w/o Sale Line” or “nosaleline”.

   These subdivisions of payments paired with subdivisions of sale lines are referred to as “Allocations.”

3. The Allocations are recorded on the date that the payment is entered.
   • If you select Accrual Basis, then Unearned revenue will have additional Allocation entries that offset the payment on the Payment Date and re-record it on the Earned Date. In other words, it’s moved in and out of Unearned.
   • If you select Accrual Basis, then Receivable revenue will have additional Allocation entries that show the date it was set as Receivable and then offset from Receivable on the date the “real” payment is entered. In other words, it’s moved in and out of Receivable.
   • If there are certain changes to transactions after-the-fact, then the revenue will have additional Allocation entries offsetting the existing Allocation values on the date of the change (not the original past date) and additional Allocation entries showing the revenue under the new values on the date of the change (not the original past date). In other words, it’s moved out of the original and moved into the new on the date the change happened, rather than retroactively updating the records on the original date.
4. On the report, the Allocation Value (i.e. portion of payment applied to portion of sale line) has two classifications based on the payment it comes from and the sale line it comes from:
   • If it represents an amount of the Price of the sale line or an amount of Tax for that sale line. In some instances, you will see values for “_Payment w/o Sale Line” or “nosaleline” (see explanation above). The Price amount + Tax amount (+ any Payment w/o Sale Line amount if present) = Value amount.
   • If it represents an amount of Real Money type of payment method or an amount of Transfer type payment method. The Real Money amount + the Transfer amount = Value amount.
5. Depending on the selected Report Format, the same whole payment or whole sale line may appear in multiple places on the report. This happens when the Report Format organizes the data such that individual Allocations from the same payment or sale line appear under different headers/sections.
   • The Allocations will display information about the payment and the sale line that the Allocation is coming from, but the report will only tally the value of that Allocation, but it is not double-counting the total payment amount or total sale line amount.
   • On those versions of the report, it is not appropriate to try to manually sum the total payment amounts or the total sale line amounts. As a visual cue that those are for informational purposes only, they appear within a line of descriptive text, rather than in their own columns for summing.
   • Similarly, if you select Accrual Basis, it is not appropriate to try to manually sum the Allocations for a particular payment or sale line and expect the net sum to always equal that whole payment amount or whole sale line amount. This is because some Allocations from the same whole payment or whole sale line may appear on dates outside of the selected date range of the report (or have been excluded by other filter selections). When there is an instance of that situation, a footnote will appear next to the whole payment amount or whole sale line amount.
   • If you export the report, it is critical that you sum only the “allocation_value” column. Do not sum the payment_value or sale_line_value columns, because the allocation_value is a subdivision of those values (i.e. payment_value or sale_line_value are informational-only to show which “pots” that Allocation is coming from), and the same payment_value or sale_line_value may appear on multiple rows if there are multiple Allocations coming from those amounts. Similarly, any other “allocation_” columns are to show what the main “allocation_value” is representing, but they are already counted within the main value (i.e. they are not additional amounts). For example: allocation_value_credit_card and allocation_value_check are subdivisions of allocation_value_real_money, which itself is a subdivision of allocation_value.

Tips

• Don’t export without reviewing the report first! It is much easier to understand (a) what the data on the report represents, (b) how the selected Report Format works, and (c) potential problems on the report, such as unresolved/incomplete sales, by reviewing the organized and formatted data on the report in a page layout, than trying to digest complex, unremarkable rows of many columns camouflaged by repeating values of a spreadsheet. So, remember: Preview button before Export button!
• Always run the Exceptions reports before the Revenue report. This is also always the first step of troubleshooting reconciliation discrepancies. The Exceptions reports highlight problematic and incomplete sales that should be reviewed and resolved first. This will ensure the most accurate and reliable figures on the Revenue report.
• Learn more about the data shown on your usual Report Format by referencing different Report Formats. This is always the second step of troubleshooting reconciliation discrepancies. For example: If your current Report Format does not include “Allocation Details” in the name, then select one that does include “Allocation Details” so you can take a deeper look at where the figures are coming from. Is there a particular row showing $0 and you’re wondering why that row is showing up? Selecting “Allocation Details” may show that the $0 row is the net result of multiple Allocations that sum to zero.
• Cashier reports are Cash Basis by nature, representing what the cash drawer actually took in. Therefore, if you are cross-referencing them with the Revenue report, run the Revenue report as Cash Basis.
• The old Payment Listing reports were Cash Basis by nature. Therefore, if you want to see a version of the new Revenue report that replaces the old Payment Listing, run the Revenue report as Cash Basis, and select one of the Report Formats that includes “Payment” in the name and does not include “Allocation Details” in the name, such as the “Business Area, Payment (Amount)” option.