Special Features The Batch Entry Process Overview This feature protects you from error, fraud, and theft. Everyone needs to revise or correct data from time to time. In many computer-based accounting systems, you can enter and change data at will, regardless of any unintended consequences. For instance, you may enter and issue an invoice. At some later point in time, it may be necessary for you to adjust the total amount of the invoice in your register. Weeks or months or even years later, you or your accountant may be faced with a discrepancy between that original paper invoice and the register, and wonder why there is a difference. This is tantamount to someone erasing or whiting out numbers in your manual ledger, and then writing new ones over them. Only, on the computer, you see no evidence of erasure or white out. Not only can this drive you or your accountant crazy at the end of a fiscal period, it means that anyone with access to the computer system can make mistakes or even steal from you without your knowledge. What may seem like a convenience is in fact a device that can easily be used against your business—even innocently, when people make mistakes. That is why MyBooks does not allow changes to posted data without adherence to Generally Accepted Accounting Principles (GAAP). These procedures allow you to post reversal and correcting entries to undo and correct previously posted entries. MyBooks uses the "batch entry" method. It protects you with a full audit-trail and a virtually crash-proof batch update (posting) process, as is fully described below. Transaction Entry & Posting This is the data that is entered on a daily basis and provides you with the ability to track the activity and changes in your business on an ongoing basis. Some examples of this type of data would be: customer invoices, purchase orders, vendor invoices, merchandise receipts, journal entries, and time cards. Unlike master file data (e.g., customer records, vendor records, etc.), transaction data is entered into a transient batch file which eventually updates the master files as necessary. You do not update the master files directly with this type of information. Entering this data is at least a two-step process of entering and posting. Typically, there is usually at least one additional step before the posting. That step would be to check the accuracy of the data entered before posting. You access the transaction processes from the Daily User tabs. Whenever you choose such a function, you typically then see another menu with several different steps, as in the example here for cash transaction data on the Sales & Customers tab: You would use these selections primarily in the order shown. First, you enter your transactions and then you print an edit list. The edit list reflects all the data you just entered. Use it to check for accuracy. If any changes, additions, or deletions are necessary, simply go back to the first selection and make the changes, additions, and/or deletions. Repeat these steps until you feel the data is correct and complete. Finally, you need to post this data in order to update all the appropriate master files. Use the last selection to do so. This function will first produce a Journal for your hard-copy audit trail. The posting process itself, in which the transactions are copied to history files and all master data is updated accordingly, is protected by an internal audit trail. If for any reason the posting process is interrupted, whether it is a power failure, or locked or missing records, when you remedy the situation you can just start up the Journal & Post process all over again. The internal audit trail ensures that nothing is double posted, and no transaction data is lost. This eliminates the need for pre-posting backups and other safety mechanisms such as roll-backs. Voiding Transactions In some transaction-based processes, the program automatically generates a number that is assigned to the transaction as its key. This transaction number is generated in a sequential order. The program will not allow the deletion of any transactions in order to maintain the integrity of the sequential number. (Transactions are viewed in sequential number order on a Register found on the 'Reports' menu. Rather than allowing deletion of transactions, which would effectively create 'holes' in the Register prompting a controller to question and investigate the situation (using valuable resources such as time), a 'Void Transaction' option if provided in the transaction menu, as in the case of entering vendor invoices: The 'Void' option stamps the transaction as void and nullifies any effect it could have on any master files. The transaction itself is preserved in a format suitable for presentation on the Register. This method ensures that gaps in the sequential number order and Register are avoided completely.