Account Payments

  • 1. How should account payments be entered and applied? B (Client) Account payments may be entered and applied as separate steps, one combined step, or either. Your selection will depend upon whether you divide these two tasks among your personnel and whether entry and application of carrier payments in one step is feasible in your situation.

    Value

    Combined Process

    If the entry and application of carrier payments will always be done as a one-step process. At the time the payment is entered the payment amount will be applied to the invoices selected or to the oldest balance.

    Either

    If you want the flexibility of entering and applying carrier payments as either a one- or two-step process. A decision will be made at the time a batch is entered.

    Separate Processes

    If the entry and application of account payments will always be done as a two-step process. The first step will be to enter the payment. The second step will be to apply the payment amount to the selected invoices.

  • 2. How should account payments be applied? B (Client) Account payments may be automatically applied to the oldest invoices, individually applied to specific invoices chosen by the operator, or either.

    Value

    Automatic

    If carrier payments should always be applied automatically to the oldest invoices.

    Either

    If the operator should have the option of either applying carrier payments to the desired invoices or automatically applying them to the oldest invoices.

    Select by invoice

    If the operator should always apply carrier payments to specific invoices, without using any automatic application.

  • 3. Is a check number required for account payments? B (Client) Entry of the number of the check used to make each account payment may be required, if desired.

    Value

    Yes

    If entry of a check number should be required when carrier payments are entered.

    No

    If entry of a check number is not required when carrier payments are entered.

  • 4. Is payment by credit card allowed for accounts? B (Client) If you allow carriers to make payments by credit card, you must indicate this here to activate the credit-card-related fields in the software.

    Value

    Yes

    If payment by credit card is allowed for carriers.

    No

    If payment by credit card is not allowed for carriers.

  • 5. To which system are you interfacing credit card payments? B (Non) Note: All of the credit card interfaces require a separate license fee to use. Contact the Naviga Support Center for more information. You can export account credit card payment information to an ASCII file, which can then be imported to credit card distribution software.

    Value

    EdgCapture

    Account credit card payments should be exported to an ASCII file in EdgCapture format.

    Edgil

    Account credit card payments should be exported to an ASCII file in Payway Complete format.

    EIGEN

    Account card payments should be exported to an ASCII file in the EIGEN format.

    ICVerify

    Account credit card payments should be exported to an ASCII file in ICVerify format.

    None

    Account credit card payments should not be exported to an ASCII file.

    Paymentech

    Account credit card payments should be exported to an ASCII file in Chase Paymentech format.

    POS-partner 2000

    Account credit card payments should be exported to an ASCII file in POS-partner 2000 format.

    Skipjack

    Account credit card payments should be exported to an ASCII file in Skipjack format.

    TrnsFirst TrnsCentrl

    Account credit card payments should be exported to an ASCII file in TransFirst Transaction Central format.

    viaWARP

    Account credit card payments should be exported to an ASCII file in viaWARP format.

    VirtualTerminal

    Account credit card payments should be exported to an ASCII file in Virtual Terminal format.

    VISANET

    Account credit card payments should be exported to an ASCII file in VISANET format.

    If ICVerify:

    • 6. If exporting to ICVerify, should the credit card expire date be formatted MMYY or YYMM? B (Non) The credit card month and year may be required in different formats, depending on the ICVerify version.

      Value

      MMYY

      The month should be exported, then the year.

      YYMM

      The year should be exported, then the month.

    • 7. If exporting to ICVerify, how many blank fields should be at the end of each credit card payment? B (Non) This setting is used to handle version 3.1 of ICVerify. The trailing blanks after the payment record are not allowed in version 3.1. However, some sites need to use trailing blanks. Enter the number of trailing blanks that should be exported at the end of each payment record.

    • 8. If exporting to ICVerify, is the ST field required in the output file? B (Non) The ICVerify system might require an “ST” field to denote the beginning of the close batch record. This setting determines whether “ST” is exported.

      Value

      Yes

      An “ST” field should be exported to the ICVerify file.

      No

      The “ST” field should be omitted from the export.

    • 9. If exporting to ICVerify and using the ST field, how many blank fields should follow the ST field? B (Non) This setting is used to handle version 3.1 of ICVerify. The trailing blanks after the ST record are not allowed in version 3.1. However, some sites need to use trailing blanks. Enter the number of trailing blanks that should be exported at the end of each ST record (the default is 21). Note: Not all sites use the ST field. If you have already indicated in Business Rules that you do not use the ST field, the setting of this rule will be ignored.

    • 10. If exporting to ICVerify, which export file format should be used? B (Non) If you use ICVerify, you can select “Retail” to use the original file format or “MOTO” to use the MOTO (Mail Order / Telephone Order) format. MOTO is the same as the Retail format with one exception: between the Payment Amount and the Zip code, there is a “yes/no” field that indicates if the transaction is recurring (currently, this field is a placeholder and is always set to “blank”).

      Value

      MOTO

      The MOTO format is used.

      None

      ICVerify is not used.

      Retail

      The original, retail format is used.

    • 11. Should American Express credit card data be separately exported? BC (Non) American Express credit card payments may be processed through a separate clearing house than other credit card types. In order to separate American Express payments from other credit card payments, account and subscriber payments with American Express (whether a single payment or an auto renew) may be sent to a separate file in /dti/exchange/cm. If Business Rules are set to export American Express payments separately, payments with credit cards other than American Express will go to the standard export file (ICVerify, Payway Complete, VISANET, etc.). American Express payments will be exported to their own file, rather than the standard file.

      Value

      Yes

      American Express credit card payments should be exported to a separate file.

      No

      American Express credit card payments should be exported with other credit card payments in the ICVerify, Payway Complete, VISANET, etc. file.

      If Yes:

      • 12. If you export credit card payments for American Express, what is your merchant ID? BC (Non) The merchant ID is included in the American Express export file.

    If EIGEN:

    • 13. If you interface credit card payments to EIGEN, what is your term ID group? BC (Non) This setting determines the term ID that is exported to the ASCII file interfaced to EIGEN.

    If Paymentech:

    • 14. If you interface credit card payments to Paymentech, what is your format version? BC (Non) Enter the version number (defaults to “2_0_0” for on-premises sites).

    • 15. If you interface credit card payments to Paymentech, what is your user name? BC (Non) Enter your user name (blank by default).

    If Edgil or EdgCapture:

    • 16. If you export payments using the Edgil/EdgCapture format, what is your merchant ID? BC (Client) This setting determines the merchant ID that is exported to the ASCII file interfaced to Payway Complete or EdgCapture.

    • 17. If you export payments using the Edgil/EdgCapture format, what is your OEP ID (order entry process ID)? BC (Client) This setting determines the order entry process ID that is exported to the ASCII file interfaced to Payway Complete or EdgCapture.

    If POS-Partner 2000:

    • 18. If you interface credit card payments to POS-partner 2000, what is your V number? BC (Non) Enter the V number.

    If Skipjack:

    • 19. If you interface credit card payments to Skipjack, what is your merchant serial number? BC (Non) The merchant serial number is included in the Skipjack export file.

    If VISANET:

    • 20. If you interface credit card payments to VISANET, what is your merchant ID? BCP (Non) The merchant ID is included in the VISANET export file.

  • 21. How should account payments be applied when the payment amount does not equal the full amount outstanding? B (Client) This setting determines how underpayment and overpayment amounts are applied.

    Value

    Current Only

    Payments will be applied only to the oldest charge. Let’s say, for example, an account has a $400 charge in the third period and a $500 charge in the fourth period, and makes a payment of $750. With this setting, it will pay off the $400 in the third period and leave $250 as an unapplied payment. The fourth period will remain untouched with a $500 charge.

    Oldest Charges

    Payments will be applied to the oldest charges, and continue to apply payments from oldest to newest until the payment amount is used up. If, for example, an account has a $400 charge in the third period and a $500 charge in the fourth period, and makes a payment of $750, it will pay off the full $500 in the fourth period, and then apply $250 toward the balance in the third period. After this payment, there will be $150 in the third period and $0 in the fourth period. This setting is the more common one, and is the default.

  • 22. How many days will you allow account payments to be backdated? BD (Client) Carrier payments may be backdated to accommodate situations where the accounting department has a deposit date that is not the same date as the payment entry date. This is commonly used if payments received on a Saturday are not entered until the following Monday. The default number of days is 5.

  • 23. How many days will you allow account misc charges and credits to be backdated? BD (Client) This setting works the same as the payment backdating setting above, but it governs miscellaneous charges and credits. The default number of days is 15.

  • 24. How many days after the discount date will you allow the account to qualify for the prompt-pay discount? BCS (Client) If you offer a discount to carriers who make payments by a particular discount date, you may have an unadvertised policy of granting the discount to carriers whose payments are received shortly after the discount date. If this is the case, you must indicate the number of days in this discount “grace period” here. Payments received after the “grace period” will not be given the discount. If you do not offer a prompt-pay discount, or if a no “grace period” policy is in effect, set this rule to 0. The default number of days is 5.

  • 25. What is the payment variance with which the account may earn the discount? B (Client) Payment terms for carriers and dealers may include a prompt pay discount percentage which may be earned if the carrier pays prior to the discount date and pays the entire amount due less the discount. The setting of this rule defines the dollar variance at which the carrier may earn the discount. For example, suppose the total balance owed by a carrier is 100.00. A 5.00 discount is available, and the payment variance defined by this setting is 3.00. Therefore, the carrier may pay 92.00 to 100.00 (100.00 balance, less the 5.00 discount, less the 3.00 variance) and still earn the 5.00 discount. A payment of 92.00 would leave a 3.00 balance for the carrier. This payment variance must be a positive decimal amount. The default value is 0.

  • 26. What is the default bank for account payment entry? B (Client) The default bank is used during account payment entry to define the bank on the payment batch screen. This default may be changed during payment entry. Enter the user-defined bank that is most commonly used for account payment deposits.

  • 27. What account ID should be assigned to an account payment when an invalid invoice number is supplied in the lockbox file? BC (Client) When carrier payments are interfaced via Carrier Lockbox, they are applied to carriers based on invoice number. If a payment is interfaced with an invoice number that does not exist in Circulation, this setting determines what carrier account is credited for the payment. This must be a valid carrier account number. If the setting is left blank, carrier payments with invalid invoice numbers will be assigned a blank account number, and will have to be assigned to a carrier in Payment Entry before the batch can be accepted.

  • 28. When entering account payments, will you be searching by invoice number? B (Client) During payment entry, invoice numbers can be used to locate payments if you set this Business Rule to “yes”.

    Value

    Yes

    Invoice numbers are used to locate payments.

    No

    Invoice numbers are not used.

  • 29. Should only accounts in the same company as the company of the entered bank be selected for BACS Prenotification? B (Client) When this Business Rule is set to “yes,” the accounts selected for BACS Prenotification will be only those that have an account bill source with the same company ID as the company ID of the bank entered. When set to “no” (the default), all accounts will be selected.

Last updated

Logo

COPYRIGHT © 2024 NAVIGA