The Batch
Date must after or on the same day as the GL Close Date.
Accounting departments typically enter payments in controlled groups of payment type and amount, prior to assigning payment entry to a specific person. This process, know as batching, is a standard cash control used to separate the duties of the person creating the batch from the duties of the person entering the payment information.
Batching provides accounting staff a way to verify that the correct number of payments and payment amounts have been processed. After verifying the payments entered (receipts in Personify terminology) against the control accounts, staff posts the batch. Posting simply means that the transactions are made ready to the system. Personify refers to this type of process as a Deferred Posting Batch.
A second kind of transaction is processed by Customer Service Reps over the phone via credit cards or faxed orders with credit card payment information. In this case, control counts and amounts cannot be created, as there is no way to know the number of calls or payments that will be processed on a given day. Each real-time credit card transaction that receives authorization is posted to the financial system immediately. Personify defines this type of batch as a Direct Posting Batch.
Personify also maintains logic for what is defined as a Deferred Receipt. Whenever a credit card is taken for a back-ordered item, cash proceeds against the card cannot be accepted until the association is ready to ship the back-ordered product. When a back-order situation happens, the credit card is pre-authorized for the amount the order and settled when the back-order ships.
The Batch
Date must after or on the same day as the GL Close Date.
| Batch Type | Description |
|---|---|
| Deferred Posting | Deferred posting batches are used for payments that are mailed
or faxed to an organization. They are also used to audit order
payments prior to posting the payment activity to the general
ledger. Using control amounts and control counts, the system verifies
that the amount of a deposit is actually the amount entered in
the system. The control count is the number of checks in a deposit
and the control amount is the total amount of those checks.
The batch of receipts can be posted and made official when the user validates that the correct number of receipts have been entered and the total of those receipts matches what is referenced in the deposit. The counts and amounts of orders paid are updated in the Batch Control Receipts table. Receipts associated with a deferred batch are applied via the Receipt Entry (FAR002) or Quick Pay (FAR011) screens. Payments to proforma orders made via a deferred batch are made active once the batch is posted. When all of the payments contained in a deferred batch have been entered, the batch can be posted. Posting a deferred batch is much more complex than finalizing a direct batch. Also, unlike a direct batch, a deferred batch cannot be posted until the Control Count matches the Calculated Count, and the Control Amount matches the Calculated Amount. When a deferred batch is posted:
|
| Direct Posting | Users, such as the customer service representative answering
the phone, enter the receipt immediately with no requirement for
later posting of the batch. Transactions within direct batches
are posted one at a time as they are created. They are also finalized
by the user so that they can not be inadvertently used again for
data entry. These batches do not require a control count or a
control amount.
The counts and amounts of orders paid are updated in the Batch Control Receipts table. Proforma orders are made active once the cash is applied. Receipts associated with a direct batch are applied via the Receipt Entry (FAR002) or Quick Pay (FAR011) screens. You still need to close the batch by clicking Finalize Direct Batch. A direct-posting batch does not need to go through a “posting” process, because transactions are already real to the system, and their posting flag is set to ‘Y’. A direct batch can be finalized without the need for control counts and amounts having to match actual counts and amounts. Finalizing a direct-posting batch simply makes it impossible for someone to use the batch again. When a direct-posting batch is finalized, the system simply changes the status of the batch to “Posted”, but none of the other processing that takes place when a deferred batch is posted is executed. |
| Adjustment | Captures the creation of order adjustments within a batch control
environment and controls the date of the adjustments created while
the adjustment batch is open. For example, to adjust orders and
have the transactions show in last month’s books, you would create
an adjustment batch with a date in the previous month. Transactions
created while the batch is open will take on the date of the batch
rather than the current date.
Adjustment batches are direct-posting, meaning there is no posting process. While optional, associating batch numbers and dates with adjustment and refund transactions provides an effective audit trail and reporting mechanism.
|
| E-Commerce | This receipt batch is used only by the Personify e-Commerce system, which includes credit card transactions captured for Web orders. All transactions created are posted immediately on credit card authorization, though credit card transactions go through a settlement process. |
| EFT | Electronic Funds Transfer (EFT) transactions are posted directly after validation. The files, along with the EFT680 batch process, validate the information. |
| Lockbox | These batches are a mixture of direct and indirect batches, meaning they can have some transactions posted while others are not. The lockbox processing posts all transactions that clear validation and then allow the user to correct the remaining transactions necessary prior to posting. If the input option on Lockbox Batch Upload (LCK100) is “Table,” then a lockbox batch must be created before running the report. |
| Rapid Deferred | Batches defined as “rapid” are used to facilitate quick order entry when the order number associated with the receipt (payment) is known. Receipts associated with these batches are applied using the Rapid Receipt Entry (FAR010) screen. Proforma orders are made active once the batch is posted. |
| Rapid Direct | Batches defined as “rapid” are used to facilitate quick order entry when the order number associated with the receipt (payment) is known. Receipts associated with these batches are applied using the Rapid Receipt Entry (FAR010) screen. Proforma orders are made active once the screen is saved. |
| Refund | This type of batch deals with refund transactions and creates a specific transaction date for the refund. Refund batches do not allow entry of receipts or adjustments, but they do allow the use of the Refund Control (FAR003A) screen. |