Preparing for and Using Date-Based Receipt Allocation Reporting

Last reviewed: 11/16/2010
Article ID: R11125

The information in this article applies to:

Tabs3 Version 14 and later
All Tabs3 Version 12, 11 and 10 Installations Converting to Tabs3 Version 14

Summary

Tabs3 Version 14 introduces true date-based receipt allocation reporting. As a result of this enhanced feature set, there are several back office procedures that each firm will want to evaluate and determine whether any changes need to be made to their current procedures, both before and after converting to Version 14. This article provides recommendations for these back office procedures, many of which are already standard for most firms.

This article also provides recommended procedures for those firms converting to Version 14 on how to transition to the new date-based method of receipt allocation. These procedures will help eliminate some issues that can make it difficult to compare Receipt Allocation Reports from different versions.

Date-Based vs. Period-Based Receipt Allocation Reporting

What exactly is Date-Based Receipt Allocation Reporting?

With Tabs3 Version 14, you can now run a Receipt Allocation Report for one or two user-defined periods. You can even run a Receipt Allocation Report for past periods at any time. Previously, the Receipt Allocation Report tracked its figures in periods that were classified as Month-To-Date, Year-To-Date, and To-Date. The Month-To-Date period was cleared whenever the Clear Productivity Totals program was run at month-end. Likewise, the Year-To-Date period was cleared whenever the Clear Productivity Totals program was run at year-end. Since Month-To-Date and Year-To-Date figures were cleared, a report could not be run for prior periods. Tabs3 Version 14 changes that.

In summary, the Receipt Allocation Report was formerly a period-based report in previous versions of Tabs3, whereas it is now a date-based report in Tabs3 Version 14.

Other Date-Based Reports in Tabs3 Version 14

Other NEW date-based reports in Tabs3 Version 14 include the following:

Allocated Payments Report
Unallocated Payments Report
Timekeeper Realization Report
Client Realization Report
Timekeeper Analysis Report
Client Analysis Report
Receipt Allocation Report

Other date-based reports available in Tabs3 Version 14 include the following:

Accounts Receivable Reports (Summary, Detail, & By Invoice)
Cash Receipts Report
Client Budget Report
Client Funds Report
Client Ledger Report
Client Productivity Report
Collections Report
Task Code Billing Report
Task Code Budget Report
Timekeeper Status Report
Transaction File List
Work-in-Process Reports (Summary & Detail)
Write-Up/Write-Down Report

Period-Based Reports in Tabs3 Version 14

Although the Receipt Allocation Report is no longer a period-based report, the following four Tabs3 reports still use period based reporting. Figures tracked on these four reports are based on the billing period in which the statement was updated, which is not necessarily the billing period of the statement date. In order for the following reports to match the Receipt Allocation Report, it is important for statement dates to match the month in which they are reported.

Timekeeper Productivity Report (Billed section)
Category Productivity Report (Billed section)
Productivity Report by Category for each Timekeeper
Productivity Report by Tcode for each Timekeeper

Preparing for the Transition - Best Practices

Every firm has their own billing practices, such as how often final statements are run and updated, the dates used for statements, when payments are entered, when a month is closed out, etc. Some billing practices that were acceptable for previous versions may need to be modified in order to provide consistent reporting periods as well as a smooth transition to date-based reporting.

Consider implementing the following in preparation for updating to Version 14.

Statement Date

With previous versions, billed information was always updated in the Current Reporting Month, regardless of the statement date. Once the current month was closed out, all statements updated would be updated to the following month. This is no longer true with the Tabs3 Version 14 Receipt Allocation Report.

For example, in previous versions, a statement with a statement date of 08/01/3006 (i.e., the year "3006", not "2006") would be included in the August 2006 MTD figures (provided the statement was updated when the Current Reporting Month and Year was August 2006). However, in Tabs3 Version 14, the figures from this statement will not be included in an August 2006 report, but would be included in an August 3006 report or a report using no ending date.

Therefore, the statement date is now quite important in Version 14 for date-based reports. We recommend that you consider how your firm is defining its billing period and what dates are being used for the statement date. This is particularly important if you intend to compare billed amounts on date-based reports with billed amount on period-based reports in Version 14 (e.g., comparing billed amounts on a Receipt Allocation Report with billed amounts on a Timekeeper Productivity Report).

If you use different statement dates for statements that are billed in a specific month, we recommend that you consider using the same month for all statements billed that month. Doing so ensures that all statements final billed and updated for that monthly billing period will be reported when running a new date-based Receipt Allocation Report for the month. For example, when billing for the month of July, we recommend always using a July statement date.

Some firms use the last day of the month for all statements billed that month. For example, when billing September, a September 30th date is always used, even if that day falls on a weekend. Although it is not necessary to use the same date for all statements billed in a month, we do recommend that you use the same month for the statement date.
Some firms use the following month's date for the previous billing period. For example, if your firm uses an August statement date for July billed information, you will want to make sure you always use the same method for the next month (i.e., August billed information with a September statement date). Otherwise, there may be months that are overstated and other months that are understated.
Some firms may use a billing period that spans months. For example, a firm's billing period may consist of a statement date range of August 16th through September 15th. Although this billing period scheme will work, it is somewhat more complicated since the date range used for a period on the Receipt Allocation Report would be a custom range spanning two months. Furthermore, you can run into some issues when configuring report definitions and report suites. This is because date variables are not available for dates other than beginning of the month, end of the month, beginning of the year, and end of the year.

How the Statement Date Affects GLS Integration

The statement date in some cases will be used as the date of GLS journal entries that are created due to unapplied payments being allocated when the statement is updated.

When a payment is entered, GLS journal entries are posted according to how the payment is allocated. These journal entries are posted using a date of the payment transaction. However, in the event a payment cannot be totally applied, a subsequent set of journal entries will be posted at a later time when amounts are billed on a statement and updated. The following explains this scenario:

If you enter a payment for a client that has no accounts receivable, GLS journal entries are created using the date of the payment; the cash account is debited and the unapplied payments account is credited.
Later, after fees and/or costs are billed, GLS journal entries will be created when the final statement is updated using the statement date or payment date, whichever is later. The unapplied payments account will be debited and the associated income accounts will be credited.

If the statement date is later than your GLS Current Fiscal Month, journal entries for the unapplied payments being allocated when the statement is updated cannot be posted to GLS. Instead, they will be logged in the GLS Error Report, thus providing you with the information required to post manual journal entries. Therefore, in order to avoid having to post manual journal entries, prior to updating statements in Version 14, you should verify that the Current Reporting Month in GLS is the same month or later than the month that was used for statement dates.

Month-End Close-Out

The point at which the Advance Current Reporting Month program (or Clear Productivity Totals program in earlier versions of Tabs3) is run determines when the Month-To-Date and Year-To-Date areas for the four period-based productivity reports are cleared and reset to zero. If you intend to compare billed figures on the period-based productivity reports with the Receipt Allocation Report, we recommend implementing the following procedures regarding your Month-End Close-Out to help ensure matching periods:

Use statement dates within the Current Reporting Month.
Make sure that all statements for the current month have been billed and updated before running the Advance Current Reporting Month.
Do not bill and update any statements for the following month until the previous month has been closed out.

Establishing a Transition Date for converting to Version 14

For firms that use the Receipt Allocation Report to make business decisions, it is important to transition from your previous version of Tabs3 to Tabs3 Version 14. Prior to converting to Version 14, you must establish a Transition Date. This Transition Date provides a way to establish a specific cut-off date for the period-based reporting in prior versions as well as a starting date for the new receipt allocation date-based reporting in Version 14.

The following steps will provide you with the reports and procedures necessary to assist you with this process.

No.	Step	Notes
1.	Install and run the Pre-Conversion Analysis program. Resolve any warnings before proceeding.	R11100 R11093
Before Converting
2.	Select a Transition Date for which you plan on closing your month and converting. Typically this will be the last day of a month.	Identifying a Transition Date makes it possible to look at figures before the Transition Date and after the Transition Date.
3.	Write down your Transition Date.	Once the Transition Date has been established, it is important that no payments or statements be processed with a date greater than the Transition Date until after the conversion has been completed. Therefore, it is important that from this point forward the entire firm observes the following: Any payments entered before the conversion is performed must be entered using a Payment Date that is on or before your Transition Date. Any statements run before the conversion is performed must be run using a Statement Date that is on or before your Transition Date.
4.	Run a Transaction File List for all payments (WIP and Archive) using a payment transaction date range (not statement date range) greater than your Transition Date. For example, if your Transition Date is 11/30/2006, specify a beginning date range of 12/01/2006 through mm/dd/yyyy.	This step determines whether there are any payments past your Transition Date.
5.	Make sure there are no payments on the Transaction File List run in the previous step. If there are payments on the Transaction File List, you will want to eliminate them by either selecting a later Transition Date or doing the following: If the payment is a work-in-process payment, edit the Payment Date to be on or before your Transition Date. (Note: You may even want to consider deleting the payment and re-entering it after the conversion.) If the payment is a processed payment, reverse the payment, re-enter the payment using a Payment Date that is on or before your Transition Date, and reprocess the payment by running a final statement with the payment on it using a Statement Date that is on or before your Transition Date. (Note: Reversing and reprocessing payments with a different date may affect your Version 12 reports. If you do this, you may want to consider running your reports again.)
6.	Run a Client Ledger Report using your Transition Date for the Report Date, the day after your Transition Date for the Beginning Date and 12/31/2069 for the WIP Pymt Cut-Off Date and Ending Date. Select the Include Zero Balance Clients check box.	This step determines whether there are any statements, write offs, or payments past your Transition Date.
7.	Make sure there is no information on the Client Ledger Report. If there are any statements on the Client Ledger Report run in the previous step, you may want to address them by doing the following: Undo them, rerun them with a different statement date, and update them. Consider selecting a different Transition Date.	Checking for statement dates following your Transition Date will eliminate any commingling of billed information on future reports due to unintentional or mistaken statement dates used in the past.
8.	Run a Receipt Allocation Report for YTD using your Transition Date for the Report Date and mm/dd/yyyy for the WIP Payment Cut-Off Date.	This report will be your month-end Receipt Allocation Report (or year-end Receipt Allocation Report if you are closing out the year) and this report will allocate all unprocessed payments.
9.	Perform all of your other month-end procedures (or year-end procedures, depending on whether you are converting after closing out the month or year).	It is important that the Receipt Allocation Report run in the previous step is the LAST Receipt Allocation Report run before running the Clear Productivity Totals program in your current version of Tabs3.
Converting
10.	Convert to Version 14.	Follow the procedures in the Conversion Instructions.
After Converting
11.	Once the conversion is complete, run a Receipt Allocation Report for the period one day greater than your Transition Date through mm/dd/yyyy. For example, if your Transition Date is 12/31/2006, run the report for 01/01/2007 through mm/dd/yyyy. Make sure that all figures (except unallocated payments) are zero.	You are running this report to verify there are no amounts after your Transition Date that will commingle with the amounts going forward. If there are figures in the report, then there were Pre-Conversion issues that should have been addressed.
12.	Run another Receipt Allocation Report for the range of statement dates used in your previous billing period. For example if your Transition Date is 11/30/2006 and your statements were all dated in the month of November, use 11/01/2006 thru 11/30/2006 for the date ranges.
13.	From this point forward, you will need to make sure that you always use Payment Transaction Dates and Statement Dates greater than your Transition Date.	The Payments program already includes extra date checking routines. The Generate Statements program will be modified to warn the user if a date is specified that is past your GLS Current Fiscal Month.
14.	At the end of your year, run a Receipt Allocation Report for the period of one day greater than your Transition Date through the last day of the year. For example, if your Transition Date is 10/31/2006, run a report for 11/01/2006 through 12/31/2006. Manually adding the figures on this report to the figures on the report from Step #8 will provide you with your YTD figures.	This step is used to give you the ability to determine accurate year-to-date figures. If your Transition Date was your year-end date, then this step is not necessary because you can use the Receipt Allocation Report run in step #8.

References

KB Article R11120 - How the Version 14 Receipt Allocation Report and GLS Integration Changes Affect Your Firm
KB Article R11127 - Working with the New Tabs3 Version 14 Receipt Allocation Report

THE INFORMATION PROVIDED IN THE SOFTWARE TECHNOLOGY, INC. KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. SOFTWARE TECHNOLOGY, INC. DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL SOFTWARE TECHNOLOGY, INC. OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF SOFTWARE TECHNOLOGY, INC. OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY.

© 1999-2012 Software Technology, Inc. All rights reserved. Terms of Use
The maker of Tabs3 and PracticeMaster
Tabs3, PracticeMaster, and the “pinwheel” symbol () are registered trademarks of Software Technology, Inc.
e-Mail Suggestions for the Knowledge Base to: kb@Tabs3.com
Technical Support via e-mail is not available.
Knowledge Base: http://support.Tabs3.com
Web Site: http://www.Tabs3.com