The information in this article applies to:
This article discusses why we recommend using regular payments instead of separate fee, expense, and advance payments. In older versions of Tabs3 (i.e., Version 12 and prior), it was necessary to enter separate fee, expense and advance payments in order to automatically post GLS journal entries to the desired accounts. It is no longer necessary to enter separate fee, expense, and advance payments to accomplish this. Using regular payments is easy and simplifies your day-to-day procedures.
Tabs3 is specifically designed so that you enter only one payment transaction for each payment received and Tabs3 takes care of the rest. That single payment will automatically be applied to fees, expenses, and advances, as well as post journal entries based on how the payment applied. You have the ability to allocate the payment as desired in Tabs3 as well as configure Tabs3 for how you want your journal entries posted to GLS.
Payments are allocated at the time of entry, and if necessary the allocation of a payment can be changed at the time of entry using the Edit Payment Allocation button in the Payment Entry window. When entering a regular payment, the payment can apply to any due amount. To review or specify the allocation of the payment, click the Edit Payment Allocation button, as shown below.

A Payment Allocation window similar to the following will be displayed.

In the Payment Allocation window, you can review the default allocation of the payment, and change it if desired.
If you want to specify new allocation amounts, you can edit the amounts in the Apply column. Click the Done button when the amounts are applied appropriately or the Unapplied Amount is 0.00. After clicking Done, you will be returned to the Payment Entry window to complete the remaining fields. The payment will be allocated immediately upon saving. Payments can only be allocated according to what is due. Payments entered before items are due will automatically allocate when additional amounts are final billed and updated.
The default Tabs3 payment allocation (shown in the Apply column) is based on the Method to Apply Payments option on the Setup tab of Client Information and the Apply Payment to Finance Charge option on the Billing Options tab of Client Information.
There are five different methods of default payment allocation from which to select, and you can designate whether finance charges are paid off First or Last.
Apply to Finance Charge First
1. Oldest Finance Charge, Oldest Advance, Oldest Expense, Oldest Fee
2. All (Oldest Finance Charge, Oldest Advance, Oldest Expense), All Fees
3. All (Oldest Finance Charge, Oldest Advance), All Expenses, All Fees
4. All (Oldest Advance, Oldest Finance Charge), All Expenses, All Fees
5. All Advances, All Expenses, All Finance Charge, All Fees
Apply to Finance Charge Last
1. Oldest Advance, Oldest Expense, Oldest Fees, Oldest Finance Charge
2. All (Oldest Advs, Oldest Exps), All Fees, All Finance Charges
3. All Advances, All Expenses, All Fees, All Finance Charges
4. All Advances, All Expenses, All Fees, All Finance Charges
5. All Advances, All Expenses, All Fees, All Finance Charges
Tabs3 has three types of payment tcodes: Type 1 (regular), Type 2 (fee), and Type 3 (cost). Type 1 payment tcodes are recommended for virtually all payment transactions. Payments entered using the Type 1 tcode are considered "regular" payments and will apply to any due amounts. Payments entered using the Type 2 tcode are considered "fee" payments and will apply only to fee transactions. Likewise, payments entered using the Type 3 tcode are considered "cost" payments and will only apply to cost transactions. An additional field determines whether the cost payment is an expense or advance payment. Using Type 2 and Type 3 payments is no longer necessary due to changes in how Tabs3 allocates payments.
Using a regular payment prevents allocation issues from occurring on a client's ledger. For example, if a client submits a $400 payment for $300 fees and $100 costs, but it is entered as a "fee payment" only, the client will display a net amount due of 0.00. In this example, the client's ledger will display $100 due for costs and a credit balance of $100 due for fees, with a net amount due of 0.00. The client will continue to print on accounts receivable reports until the discrepancy is resolved.
Using a fee or cost payment should be an exception to your normal procedures. The only time fee or cost payments are used is when that money must only apply to fees, or only apply to expenses, or only apply to advances, and the payment amount exceeds the amount due. If the amount due exceeds the payment amount, you can use a regular payment and simply change the default allocation when the payment is entered to match the client's request. However, when the payment amount exceeds the amount due, the excess amount is tracked as an unapplied payment and will be allocated later when a statement is billed, thereby requiring a fee or cost payment to be used in order to adhere to the requirement when the payment is allocated.
Firms that used Tabs3 in Version 12 or prior needed to enter specific fee, expense, and advance payments according to which accounts you needed the payment to credit in the General Ledger Software (GLS) when integrating the two systems. It is no longer necessary to enter separate fee, expense, and advance payments. New integration techniques were introduced with Version 14 that allow regular payments to be integrated to GLS according to the transactions they were allocated toward, rather than the tcode of the payment entry. This change eliminates the need to process multiple payment entries for a single payment transaction. With proper GLS Integration Setup, you can now enter a regular payment and have the appropriate GLS accounts posted for each transaction.
Tabs3 GLS Integration Setup changed significantly with the release of Version 14. Payments are allocated at the time of entry, and therefore GLS journal entries are made automatically based on the specified allocations, provided the GLS integration is set up to do so. This change allows you to enter a single regular payment and Tabs3 will automatically distribute the income in GLS. For example, Tabs3 can be set up to post a debit journal entry to the Operating Account and multiple credit journal entries to various income accounts according to how the payment allocated to fees, expenses, advances, timekeepers, cost types, etc. Additionally, journal entries can be posted based on predefined fee allocation rules.
In order for the GLS integration to occur exactly how you want it, you need to configure the GLS integration. Integration with GLS is very robust and provides the ability to post journal entries virtually any way you would want to integrate. The following screen shot shows an example of how fees can be configured to integrate. Once the posting method is specified, you then configure which GLS accounts you want to post to. Complete details can be found in R11170, Integrating Tabs3 Payments with GLS in Current Versions.
![]() |
![]() |
More information regarding how GLS integration changes may have affected firms that used older versions of Tabs3 and GLS is provided in KB article R11120, "How the Receipt Allocation Report and GLS Integration Changes Affect Your Firm."
Another benefit to entering payments using the regular payment tcode is the ease of report comparison. When using the regular payment tcode, all payments are entered as a single transaction in Tabs3 and integrate as a single payment into the operating account. This allows you to use the Cash Receipts Report in comparison with your GLS Reconciliation Report to be certain that all Tabs3 payments have integrated properly into GLS.
The addition of credit card processing to Tabs3 in Version 15 has created another reason for using the regular payment tcode. When processing payments, each card swipe is charged a convenience fee by the card issuer. If you have been authorizing separate payments for fees, expenses, and advances, those fees have been adding up. Additionally, your client's credit card statement will reflect multiple transactions for what the client understood was a single payment transaction. From the Payment Entry window, you can determine the amounts allocated to fees, expenses, and advances without running a credit card authorization multiple times, which saves you both time and money when a client selects to pay with a credit card.
We strongly recommend using Tabs3 regular payments (Type 1) for all of your payments. Once configured, payment allocation and the posting of GLS journal entries are virtually automatic and require few, if any, manual adjustments.
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