The information in this article applies to:
This article discusses various methods that can be used to handle electronic funds transfers (EFTs) in APS along with how each method affects GLS.
When entering data into APS, you can enter an invoice or a manual check. The following methods are available for entering EFTs:
When using this method, you will need to identify a different range of check numbers that can be used for EFTs. Some firms use a date for the EFT's check number. For example, if the date of the EFT was June 30, 2009, an appropriate manual check number to use would be "20090630." This YYYYMMDD format is recommended because it allows for better sorting in reports that deal with check numbers (e.g., Check Register). It also makes these entries more visually identifiable as EFTs as opposed to standard manual check entries, particularly when the regular check numbers have fewer digits. Or, if your current check numbers are in the 50000 range for example, you can start with 900 or 90000. Using a separate check number range allows the checks to be shown in a different area of the Checks portion of the GLS Reconciliation window. Having a unique check number for the EFT prevents issues with voiding posted EFTs. Keep in mind that the maximum number of digits allowed in the check number field is 8 and alpha characters cannot be used.
A drawback to using a separate check numbering scheme for EFT's is that you will need to pay close attention to the default check number. When adding a manual check or running a batch of checks, APS defaults the next check number to the previously used check number plus one. Therefore, if you add an EFT using a check number of 905 and then print checks, the Print Checks program beginning check number will default to 906 as opposed to the actual last check number.
Using a separate check numbering scheme probably offers the best solution if you are using GLS.
Using a check number of zero for EFTs can present problems with the following:
Voiding an EFT: If multiple manual checks with the same check number exist, you need to be aware of the following when voiding an EFT.
Therefore, when using manual checks with a check number of zero for EFTs, when you want to void an EFT, it is recommended that you enter a manual check with a negative amount as opposed to using the Void Posted Checks program. Otherwise, all EFTs for the vendor with the same check number will be voided. Entering a manual check with a negative amount will create the required reversing GLS journal entries when the Post Checks program is run. Keep in mind that these entries will not appear on a Voided Check List unless you enter a manual Void entry as well.
GLS Reconciliation: Duplicate check numbers of zero for the same vendor will be combined as a single credit entry when the Post Checks program is run. This results in a single item in the Reconciliation window, thus making it difficult to reconcile EFTs separately. One possible work-around would be to run the Post Checks program immediately after entering an EFT; however, this may not be practical since the Post Checks program posts for all vendors and only allows a Cut-Off Date to be specified. If using the GLS Reconciliation program, we recommend not using a check number of zero for EFTs if you need to enter more than one EFT for the same vendor number in a given posting period.
For those firms who do not want to use a check number of zero or separate check numbering scheme, another alternative is available. A separate APS bank account can be set up for EFTs. For reporting purposes, you will want to make sure the bank account number is one greater than the main bank account you are working with. If using GLS, map the new APS bank account to the same GLS cash account. An advantage to using this method is that a separate check number series is maintained from your computer printed checks and you do not have to verify the beginning check number for computer printed checks.
Although this method eliminates the issues with default check numbers, voided EFTs and the Bank Account Reconciliation program, it introduces other issues that may not be acceptable. Reports will need to be run for both bank accounts. Reports that automatically sort transactions by bank account do not provide grand totals and will therefore require manual calculations. These reports will also always show EFT transactions in a separate area and will not combine the transactions in date order. These reports include the Check Register, Pre-Check Register, and Voided Check List.
All other reports do not pose any problems when using this method, either because they are not sorted by bank account or they have the option to sort or not sort by bank account. Furthermore, this method does not cause any problems with 1099 reporting because amounts paid do not distinguish across bank accounts.
If your firm does not use the Check Register, Pre-Check Register, and Voided Check List, or you don't mind running separate reports, then using a separate bank account for EFTs may be a very workable solution for handling EFTs.
Some firms elect to handle EFTs in GLS only and do not even enter them into APS. This method eliminates the issues with voided checks and the Check Reconciliation; however, it also eliminates the ability to track cumulative paid amounts in APS for 1099 purposes and reports. If you don't need to track the total amount paid to a vendor, then entering EFTs directly in GLS and bypassing APS is another option for handling EFTs.
Note: Like APS, the GLS program includes a Recurring Entries feature that makes it easy to post entries for EFTs that occur on a regular basis. In GLS the Recurring Entry program is located in File | Open | Miscellaneous | Recurring Entry.
If you have vendors that are paid monthly via automatic electronic funds transfers (EFTs), you can use the Recurring Entries program in APS to generate the EFTs.
You can set up the transactions in APS as recurring entries. After posting recurring entries for the month, edit the invoice that was created by selecting the Manual Check check box, specifying the appropriate Check Number, and making any other necessary changes. If integrating with GLS, the journal entries will be posted the next time the Post Checks program is run in APS.
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