Receipts by Category

This Quick-Report is rather unique in that it "interpolates" the amounts from transactions instead of using raw transaction amounts.  Thus the amounts in a particular category may not seem correct (e.g. a payment doesn't all go into the category expected), or an amount appears in "Uncategorized" and it may not be clear why.

Since this report uses "interpolated" amounts rather than raw transaction amounts, it will divide a payment proportionally into the categories that need to be "paid", or accounted for, at the time of payment.  When a bill isn't paid in full, e.g. for long-term guests, this can cause confusion.  The other primary issue is when payments are entered before the charges to be paid, so that at the time of payment there are no categories to put the payment into (causing "Uncategorized" amounts).

Here are a few tips on resolving or at least understanding these issues...

The first thing to do when you see something unexpected in the report is to uncheck the "Summarize" box at the top.  This will switch to Details mode and show the individual "interpolated" transactions -- e.g. a single payment may be shown as several interpolated amounts into different categories.  These details are sorted by category so it should be easy to locate the problem area.  To further investigate an item, you can right-click on it and select Transactions as usual to get to that reservation's transaction details.  Here you may see that a payment is out of order, or that it wasn't paid in full at some point.

If a payment is out of order, probably causing Uncategorized amounts, you can correct that easily.  First close the Reservation Transactions if that's still open, then right-click on the line again and go to Reservation Details.  From there click on Transaction History.  Select the payment and use the Move Up or Move Down buttons to put it in the right place (usually at the bottom, or at least below any Charges that it's paying for).  Note that this doesn't change the dates so it won't affect reporting by dates -- it will only affect the distribution of the payment in the Receipts by Category report.

By the way, if you normally receive a payment before charges can be added, e.g. before they arrive, then that really should be entered as a Deposit.  Once charges are added, then the money is "moved" from Deposits to the appropriate categories (this is one purpose of the "Dep Applied" transactions you see added automatically).

Refunds -- As with Payments, Refund transactions should be entered after the adjustments to Charges that are related to the refund, e.g. use Reverse Charges or enter Discounts or negative Charges first to get the balance to be refunded, then enter the Refund transaction.

Note: When you uncheck "Summarize" on the report to see the detailed transactions, the Refund transactions will be shown with their "refund amount" in the Each and Total columns.  So for instance if there was a refund of $50 in a category, it will show as a positive $50.  However that amount must be considered negative (subtracted) to arrive at the total for the category.

Assigning specific categories to a payment...

Sometimes you may receive a payment that you want to put in a specific category (or categories) instead of letting the program split it up.  For instance if the customer has a $50 balance due for rent, then you add an electric charge of $50 and they pay only the $50 for electric, the program would normally split the payment into $25 rent and $25 electric.

The only way to change this distribution is to manually assign categories to Payments.  You will first need to enable this feature -- go to Maintenance / Program Options / Transactions, and check the box "Allow transaction categories to be selected for payments" (and click OK).

Now when you enter a payment, it will allow you to assign one or more categories to it.  You can also correct allocations for previous payments -- as in the example above, right-click on the transaction in the details list and select Transactions to get to the Reservation Transactions dialog.  Click on the Payment transaction to be categorized, and a button "Edit Category Allocation" will appear at the bottom.  Click that button and add one or more categories as needed.

You can also use the Edit Category Allocation function for Refunds, Deposit Applied transactions and Payment Transfer transactions.  (Deposits themselves can't be categorized -- they must be "applied" first).

Hopefully these tips will help you understand and correct any discrepancies in the report.

Other issues that can result in Uncategorized or inappropriate categorization

Besides the common issues of out-of-order payments and partial payments, there are a few other issues that can cause anomalies, described below.

Credit balances -- if a credit balance (overpayment) exists on a reservation, then that payment cannot be categorized.  Be sure that credit balances are handled appropriately whenever possible, e.g. transferred to another reservation where it's used to pay for a charge, or at least into the Customer record where it can be used for a later reservation.  It will still be Uncategorized in this latter case, but once it's transferred to a new reservation with charges, then it will be "deducted" from Uncategorized so that it balances out in the long run.

Incorrect manual category assignments for previous payments -- If you're already assigning categories to some payments manually (as described above), then this can cause problems if a mistake is made.  Later payments will be automatically allocated to balance the categories to the charges seen, "fixing" any mistakes in the process.  For instance if you had a $50 Charge for Daily Rate but then allocated the Payment to Monthly Rate, then it would report that $50 payment in Monthly Rate.  If you later added another Charge (say for $10 in electricity) and a Payment but did not manually allocate the Payment, then it would see that Monthly Rate had too much allocated and Daily Rate not enough, due to the mistake.  So it would allocate -$50 to Monthly Rate and $50 to Daily Rate, in addition to the $10 in electricity.  Obviously confusing on the report for the new payment, but technically correct since the overall payment allocations are now correct.

Changes to charges or payments after manual allocations -- If you assign a payment to category manually, and then either change the amount of the payment or the amount or category of a charge preceding that payment, then the manual allocation is now unbalanced (unless you remember to correct that also).  This has the same result as an incorrect allocation above.

Incorrectly deleted "Deposit Applied" transactions -- As mentioned elsewhere in the documentation, the Deposit Applied transactions are added automatically by the program to properly account for deposits being applied to the charges.  If you delete a Deposit Applied without deleting the Charges, etc. that resulted in it, this results in throwing off your Deposits balance as well as the Receipts by Category report, since it no longer has a record of that deposit moving into the correct categories.  Likewise, deleting Charges without deleting their Deposit Applied will result in the deposit going into Uncategorized.

Orphans -- if there are orphaned transactions, then the categories can't be interpreted correctly (it will appear as if charges or payments are missing).  Be sure to fix these through Maintenance / Database Maintenance.

Bad Links --  If there are "bad link" conditions in the categories of transactions (e.g. if a category was deleted causing a bad link), then it won't know how to categorize a payment.  While there is a function under Database Maintenance to "Repair <bad links>", this will only set it to 0, which is still an unknown category.  You would need to locate each transaction with a missing/bad category and select the appropriate category for it.

Missing Receipt/Invoice # -- If there is no Receipt #, e.g. if this field was disabled through Data Field Definitions / Transactions, then it can't link Unbound or POS transactions to determine the payment category.  While it's not possible to disable this in current versions, older versions may have this disabled (so any Unbound transactions done in an older version could have this issue).

Payment Transfer Mismatch -- If there is a Pmt Transfer mismatch (one side deleted but not the other), this can cause a problem since it depends on these cancelling each other out to $0 received for the day.  Use the function under Maintenance / Database Maintenance to look for unmatched payment transfers.  If one is found, you need to delete it and re-do it if necessary.

Misc. Income an Expense transactions -- If you're using a version prior to 7.0, a bug can result in these not showing properly.  This has been fixed in version 7, and the fix also applies to transactions entered prior to upgrading.