Receivables (Account)

If your company manages some or all of its receivables, it's important to fully understand Receivables (ALT-R) tab settings. These will determine both how receivables work for the account procedurally by your company and how the customer is billed. Typically, the posting type and other settings should correspond with the way the customer remits their payments.

Rent to Own (Hire Purchase)

A special type of account is required for Rent to Own (Hire Purchase). We suggest that you only use this account for Rent to Own activity to avoid any confusion. The account is considered "cash-only." The only receivables activity allowed is the invoicing of orders associated with a Rent to Own contract. For receivables processing, the account is an "open item" and "job" billed account. The credit limit should match or exceed any purchase amount.

When a customer order linked to a Rent to Own (Hire Purchase) contract is invoiced, the due date of that invoice is set to match the end of the contract term. The original purchase is not aged until the due date passes and will be represented either as part of the customer's current balance. In some cases, we may show the amount due in the future separately; however, it is not maintained in the data separately from the current balance.

Customer statements will reflect the purchase and any current cycle adjustments as current. Unpaid adjustments (for billing) from prior cycles will be reflected as past due if unpaid. You must select "Contract (Summary)" as the Statement type.

The frequency (how often) a customer is billed can vary by contract (agreement). One contract might be billed monthly while another might be weekly. Aging doesn't reflect the age based on the number of billings or frequency of those bills. For example, a customer with a weekly plan who hasn't paid the past two (2) weeks might still show as "current" until the next billing cycle runs. Aging is only done once per month when the monthly billing process runs. In the same regard, the statement doesn't show past due amounts in weekly increments or any other period that doesn't match the monthly billing cycle.

The contract document can serve as a "status" of the current state of the agreement and we suggest using email notifications for payment reminders.

Rent to Own Setup

Creating a Rent to Own Contract

Revolving Charge

Revolving charge is a new account option for receivables accounts. It provides the ability to bill a customer an amount based on either a percentage and/or minimum payment amount that may be unique to each customer.

The finance (or service) charge uses the existing options; however, the charge is calculated on either the entire balance at time of billing or the average daily balance during the prior billing period, not just past due amounts.

More information for Revolving Charge can be found by clicking here.

AR Branch

This is an optional setting that indicates the branch location to which a customer is assigned for receivables activity. This limits account selection to the designated branch (or branches... if a list is assigned) in receivables activities such as Posting and Credit/Debit adjustments. In addition, setting the AR Branch determines the branch document logo and branch address that will be used when statement documents are viewed or delivered by printing, email, or faxing. There is no requirement that an AR Branch be specified unless your company decides to procedurally make it one. This setting doesn't apply to companies operating a single location.

In addition to assigning one specific branch, users can set up a list of branches and assign that list to an account. Branch lists won't show up in the normal "branch" drop down. To designate a list, users much first choose "Branch List" from the alternate menu. Branch lists are defined from the "Branch Lists" database form available in the Maintenance area. Branch lists are not used for determining the branch logo for statements (if a branch list is assigned, the branch logo will default to the main or "master" branch location).

Changes to the AR Branch will affect ALL existing statement documents that are viewed or delivered by printing, email, or faxing after the change if a branch logo is designated.

Statement delivery is not done by branch unless you assign account ranges or prefixes to indicate the account branch and use account ranges when processing. AR Branch has no effect on the order of statements for delivery. Accounts can be selected from the Statements transaction regardless of their assigned branch.

Account Type

There are three (3) account types: cash, charge, and system. Account types determine the basic functionality or purpose of the account.

 

1. Cash: This type of account should be used for any customers who pay using "cash" type payment (includes check, bank card, etc.) or for customers who are Capital One Trade Credit (formerly BlueTarp® Financial Service) card holders. Cash type accounts are not allowed to charge* and may not be used with certain Point of Sale transactions such as Open Tickets and Charge Returns, for example.

*Capital One Trade Credit (formerly BlueTarp) accounts function similar to a "charge" account, but the receivables are not maintained by your company's server in this case. Capital One Trade Credit (formerly BlueTarp) accounts function like a charge account in regards to Point of Sale, but otherwise are handled financially more like a credit card. Customers who are flagged as Capital One Trade Credit (formerly BlueTarp) are required to be "cash" type accounts.

2. Charge : The "charge" type of account should be used with customers for whom your company maintains as part of your accounts receivable (sends out statements, etc.). Charge customers can still pay using cash-type payment methods if they prefer. This type is also used for "draw down" type accounts. A draw down refers to the situation where a customer has paid an amount prior to any purchases so that their future charges will draw down from their existing credit balance. To designate an account for draw down use, set the type to "charge," credit limit to zero, and apply the customer's draw down payment under the Payments activity in Point of Sale using the selection Receive on Account.

3. System : "System" refers to an account your company maintains for its own use that does not belong to a specific individual, but is used more generically. It is assigned rarely as an account type, and most companies have only one system account. An example of a "system" account is the default CASH account used for anonymous sales. Typically, this type should never be used for an account assigned to a specific customer. There are a number of functional differences between "system" and "cash" accounts that might not be immediately apparent.

Please also refer to the section Statement Documents for further information.

Posting Type

There are two (2) posting types:

1. Open Item : An "open item" customer remits payment for specific invoices rather than the overall balance due.

2. Balance Forward : "Balance forward" customers remit payment for their total balance due, not specific transactions.

This setting affects how data is maintained for the customer, AR processing, and the appearance and options provided for monthly billing (statements). Balance Forward customers only maintain balances and do not track payment details for individual invoices. Open item accounts update the payment status of each invoice (purchase), credits, etc.

Posting (AR) Type Changes With release 10.3.0 (March 2015), we no longer restrict changes between Balance Forward and Open Item account types. In past releases, it was only possible to modify an Open Item account to Balance Forward type, but not the reverse. Now, you can modify accounts from Balance Forward to Open Item. To convert a balance forward customer to open item, we update the "AR Paid" amounts on existing invoice records linked with the account and/or job. The aged balances for the account (and job if "job" billing) are used to mark paid amounts on invoices for the corresponding billing periods (cycles). This is done in reverse order so that the older items are marked paid before any newer items (this is done for each billing period and by job if the account is job billing). Unapplied discounts, credit memos (returns), and finance charges are not affected. At the end, we compare the detailed invoice records to the balances for the customer and if they match, we allow the change to proceed. Note: When converting a balance forward customer to open item, you have no control over which existing invoices are marked paid. This is done automatically by job and for the oldest items first. If all balances are zero, all prior invoices for the account will be marked paid.* This will not work in all instances (see the listing below for exclusions and conditions). In cases where we are unable to convert an account, changes will be reversed and the account will remain as is. A message is shown if the software cannot convert the data. ØThe automated Billing Cycle processing must not be in progress. ØNo negative balances are allowed in Current or Past Due balances. ØBalances must have sufficient charges (invoices/debits) for each cycle (Current, Past Due). ØChanges aren't allowed to accounts that are currently locked for posting or while posting is currently in progress. Paid date is not known and is not set on invoice records when oldest items are marked paid. This may be a factor if you use custom reports for pay-when-paid type reporting. *Invoices for balance forward accounts are not usually marked paid otherwise.

There are statement differences for each type, and payment application (posting) varies somewhat. With "open item" accounts, payments are applied to individual charges (invoices, finance charges, and adjustments), not only to balances (balances are maintained as a summary of open items and do change when payments are applied). Payments posted to "balance forward" accounts are applied to balances, not specific invoices.

Billing Level

There are two (2) billing levels: Account and Job. It's important to point out that any account can have jobs even if they are billed at the "account" level. All accounts can have jobs regardless of their billing level or any other settings. Settings only impact the way jobs function.

Billing level affects how balances are represented, finance charges, discounting, and how payments are applied. Billing level also determines whether or not a job's credit limit can be enforced (except in the case of a "draw down PO" type job).

Depending upon your choice either more or less detail is maintained for jobs. The "job" billing level maintains more detail for each job than the "account" level does. When changing an existing "job" billing account to an "account" type, the change removes any previous job balances, etc. and uses the overall account balances from that point forward. Changing from account billing to job is now allowed (with release 10.3.1, see below). A modification in this direction moves from less detail to more. Some existing information cannot be separated by job and is assigned to the master job (zero) instead.

1. Account :

   "Account" billing means that the customer is focused on their overall account and doesn't require that jobs operate as if they were independent accounts. With the Account level, aging is only done for the overall account. Adjustments and payments cannot be entered for a specific job. In addition, posting is done for all jobs. The credit limit for any jobs assigned to the account will be ignored and only the main account's balances considered for the purposes of overrides, etc.

2. Job:

   A billing level of "job" treat jobs almost like independent accounts. This difference primarily influences payment entry, statements, and posting. Each job is aged independently; however, a summary aging is provided for the overall account (unless suppressed by the statement type). If invoices are reprinted with statements, they are printed or delivered with each job individually. Adjustments can only be done at the job level. Discounts and finance charges are also calculated by job. Each job may have its own credit limit which is enforced as long as the main account's credit limit is not exceeded. Job entry is also normally required when receiving payments.*

*When using the "consolidated" posting option with job level customers, payments added in the Posting area use job #0 by default.

Changing Accounts from Account to Job Level Billing In releases prior to 10.3.1 (March 2015), we did not allow changes from an "account" to "job" billing type on accounts with activity. With release 10.3.1 and later, this restriction is no longer in place and we have added additional code to convert account billing customer accounts to job. Job billed accounts maintain totals and balances separately by job. In these cases, the jobs act more like independent accounts in many ways. This new ability is being done so that companies are more comfortable starting with balance forward and account billing types, which are easier to manage, knowing that they can change them to a more detailed type if needed later on. I. Restrictions a. The Billing Cycle close (checklist) may not be in progress. b. No negative balances are allowed in either the current or any past due balances. c. Billing type may not be changed at the same time as a Posting Type change (Balance Forward to Open Item, for example). d. All master (account) balances must be fully applied to jobs. e. If the account is Open Item, each job balance must match the sum of the open charges by job and must not exceed the account total for each balance period. f. Changes aren't allowed to accounts that are currently locked for posting or while posting is currently in progress. II. Special Handling a. Consolidated account balances (Current, Past Due, Credits) are applied to Jobs in Job order (e.g., Job 0, then Job 1, etc.) until the balances are fully applied. b. Due to a lack of job references, the following amounts are fully applied to the master job 0 (zero): Disputed Balance Finance Charges Finance Charges Paid YTD Finance Charges (Last Statement) New Finance Charges c. We distribute any remaining statement and current discount to jobs rather than just job zero. d. Any difference in summing job balances for Statement Balance and Opening Balance as compared to the Master account settings will be applied to Job 0. Additional Information Changes to the billing type only impact the account going forward. Prior statement documents are not changed and would reflect the state of the account settings at the time the statement was generated. Statement documents are not generated during delivery (via print, Email, or fax) from the Statements transaction on the Receivables menu, but are generated by a scheduled task that runs monthly between business days. For the billing type to affect the customer's next statement (as well as most other account changes), changes must be made prior to this scheduled task. Billing processing is scheduled and usually runs on a designated day of the month (or sometimes the last day of the month).

Statement Type

Statement type determines two (2) things: (1) sorting order for job details and (2) whether or not optional pages are included when statements are created. Statement type does not determine whether an account can have jobs, nor does it usually affect whether individual job statements are created or not.* Any account can have jobs. Billing Level is the setting that determines whether separate job statements are created.

Choices

There are 9 statement type settings available:

1. Consolidated

2. Job

3. Consolidated (No Summary)

4. Job (No Summary)*

5. Consolidated (No Remittance)

6. Job (No Remittance)

7. Consolidated (No Summary, No Remittance)

8. Job (No Summary, No Remittance)

9. Job Summary and Remit Only**

*If this statement type is assigned to a job billed account, the only billing document sent to the main account would be a "summary" of the job activity. Choosing "no summary," in this case, causes the account summary of jobs to be suppressed. Only job statement documents would be sent in this case.

**If this statement type is used with job billing accounts, it suppresses the job statement and only produces a summary/remit statement for the account. If reprints are enabled for the customer and their account is job level billing, using this statement type effectively bypasses the job statement processing including any invoice reprints (which normally would be delivered with the job statement). Job statements are still generated in this case; however, they are not printed or emailed, etc. when using the Statements transaction on the Receivables menu. Job statements can still be individually viewed, printed, and emailed from the Documents form.

Canadian Statements For our customers in Canada, the summary page of the statements prints summary totals for the GST and PST/HST tax amounts during the statement period. These figures are gathered from customer (account) and job totals based on the current statement date. The period is between the current statement date and the current statement date less one month (note: if your prior statement did not run on this date, or ran in the middle of a business day, the totals won't match the billing period exactly). The figures use totals which are updated on a regular basis, but are dependent on application services. Services must be running for these figures to update.

Sorting

The consolidated selections cause any details involving both jobs and dates to be sorted first by date then by job.

The job selections cause details involving both jobs and dates to be sorted first by job then by date.

Optional Pages

Summary and remittance pages are optional. The "summary" lists either (a) activity for the current period for balance forward type accounts or (b) unpaid transactions for open item type accounts. For customers assigned to the "job" billing level, the summary offers an overall account aging in addition (for this reason, it's wise to not disable the summary on "job" billing accounts). The "remittance" pages only apply to open item type accounts. The remittance page, or pages, lists unpaid item so that a customer can designate the one's they are paying. Remittance pages are only printed for the overall account, not each job; however, remittance details can be listed by job if a statement type of "job" is being used.

In the case of the "Job Summary and Remit Only" selection, the summary and remit are the only pages provided. In this case, the "statement" page is suppressed.

Print Zero Statement

This setting determines whether (or not) a statement should be skipped (not delivered) for customers based on their level of activity. There are three (3) choices: yes, no, and "if current activity." The last option ("if current activity") will deliver a statement even if the account's balance is zero as long as some activity on the account occurred during the billing period. None of these settings prevent a statement document from creating, they just affect delivery. There is a separate setting saved with each statement document that determines whether they are "skipped" when it comes to printing.

Reprint Invoices

This setting determines whether or not invoices are reprinted (or transmitted) along with monthly statements during billing and interim statements upon request. This setting does not have any impact on Point of Sale delivery of invoices. Valid choices are Y (Yes), N (No) or blank (same as N). With open item customers, only invoices which are both new and open (unpaid) are reprinted. For balance forward accounts, all invoices from the billing period are reprinted regardless of payment status. When statements are being printed or delivered, the user can disable reprints but still create statements. Billing level (account or job) determines whether any reprints are delivered by job or account. For example, if your customer is job billing, the jobs receive their reprints individually as long as job statements are produced. With account level billing, statements are delivered to the account only (no job statements are generated in this case). It is possible on a Job Billing account to disable the job statements and indicate a "summary" statement only. If done, this effectively blocks both the job statement and any reprints since those are linked to the job's statement. Only the account would receive a "summary" statement of job activity in that case.

Invoice reprints can be printed along with the statement using a different tray on the same network printer. This works nicely if different colors of paper are used or if a different paper alignment is assigned making the invoices and statements easier to distinguish. For email delivery, invoices are attached to an email as a separate attachment from the statement document. For example, a customer with 16 invoices would receive 2 attachments, one attachment would be a PDF (Portable Document File) containing all 16 invoices and another PDF with just the statement. The file name of the invoice attachment includes the number of invoices that file contains.

In addition, a parameter is available for setting the default print format for invoices reprinted with statements. Choices include full page, 2 per Page, and 4 per page. The "2 per Page" prints 2 invoice pages per sheet of paper, side-by-side, in a horizontal alignment. The "4 per Page" prints 4 invoice pages per sheet of paper vertically aligned.

The "No Prices @ POS" setting found on the Codes tab has no effect on invoices that will be reprinted for delivery with statements.

Credit Limit

This sets the credit limit for the entire account and should include all jobs. If the credit limits of jobs exceed the overall account's limit, and the account's limit is met or exceeded, overrides will be required and prompts will appear during sale, ticket, and order transactions. Credit limits are typically not set on cash type accounts, draw down, or Capital One Trade Credit (formerly BlueTarp Financial) customers.

Note: When you change the account's credit limit, the previous AR Log Note Entry displays automatically. In the Promised Payment Notes field, type the reason for the change and the new credit limit amount to add an AR log entry. This allows the credit limit change to be audited.

Statement Message Code

Statements can print messages related to the customer's balance or something more general such as "Happy Holidays" or advertising sales and promotions. Before being used, a code must be defined using the special form available next to the input field. Codes can be up to 4-characters in length and the message assigned to the code can be up to 128-characters in length.

Some codes are reserved for balance triggered messages; these are: BAL, 30, 60, 90, and 120.

To use these with a customer, assign the base code BAL as the account's statement message code. Create and assign your own messages to BAL, 30, 60, 90, and 120 codes. Messages will be printed on customer's statements based on their oldest unpaid balance, so if an account has a 90 day balance, they'll see the 90 day message printed on their statement. Note: if you assign the code BAL to a customer and you haven't defined or assigned messages to the balance codes, default messages regarding the balances will still be printed.

Messages are linked with statements when the statement data is created, not when statements are delivered (by printing, faxing, or email), so if you want to change the message on one or more accounts, be sure to do it before automated monthly AR processing occurs! Job balances are used for determining the message code if Job-level Billing is enabled for the account; otherwise, the account balance is used (there are no "job" balances in this case).

Bankcards on File

This refers to the tokenization feature available with VeriFone® PAYware Connect® SIM versions 2.0.4.7 and above. Tokenization refers to the ability to link a customer's card information to a token or identifier that is saved with their account in place of actual card information. This allows for card purchases at Point of Sale without a physical card necessarily being present. Information for the customer's card is linked with a PAYware "contract" and customer identifier for the customer's account using the Merchant Console. Once setup, this information is then linked with either the overall account or individual jobs in the software.

Only one card per job is allowed and the presence of a job card/contract overrides any consolidated contract that may be present. Although multiple contracts (different cards) can be defined for the same customer, the application does not provide the ability to select a card at Point of Sale. When a card-contract is present during Point of Sale processing, a prompt appears asking the user whether or not to use the card information on file. Card information is not shown to the user and is only available through the on-line (Merchant Console) portal. Only system administrator type users have the ability to view or access this form.

The label associated with the form maintenance icon does indicate to any user whether or not card information is present. If no card information has been saved, the label will say "No Bankcards on file." Otherwise, if card contract information has been saved for the customer, the label text is changed to "Bankcard(s) on file" and is displayed in a darker colored font.

No validation of the information entered is provided. No warnings are provided if the customer ID or contract ID has not been setup or has been entered incorrectly. The "Description at POS" text area is displayed to the user at Point of Sale. This should be used to indicate a description of the card as anonymously as possible. This information is neither encrypted nor protected and should never be set to match an actual card number.

Should a user respond "no" to the prompt, the card contract can still be selected by using the "Use Card On File" option on the context menu in the Bankcard payment panel displayed on the Process (F12) form.

Removing an Existing Card Contract

To remove an existing contract from an account, do the following.

1. Modify the customer from the Account Maintenance form (Database menu in Point of Sale or Receivables).

2. Choose the File Maintenance Settings icon next to Bankcard(s) on file.

3. When the "Payware AddOn Contract" dialog box appears, select the card contract to be removed.

4. Clear all check box selections for jobs and consolidated.

5. Choose the Accept button. The dialog will close.

6. Choose Process (F12) on the Account Maintenance form.

The VeriFone SIM version is determined by either (a) the system parameter (Maintenance > Database > Parameters > Setup (Tab), Software (Subtab)) default setting or (b) the settings for the pad assigned to the station (Maintenance, Database, Devices). If the pad is set to "system default," the pad uses the version designated by the parameter; otherwise, the version specified for the individual pad is used. If no versions are designated, the lowest version available is used. We have added tokenization (saving card information for customers), the ability to process a return using the original invoice's card information, manual card entry on the pad, sending Purchase Level II Data to the processor, and enabling of VeriShield Total Protect™ for an additional layer of protection. Users who wish to take advantage of the Purchase Level II Data feature available with the latest VeriFone SIM version, should be aware that this changes the structure of the requests we send. Doing this, requires that we re-certify with card processors in some cases. Unless your company is using either TSYS® or Chase Paymentech™ as a processor, for which certification has been completed, you should check with our support department before enabling this version and enabling Purchase Level II Data. All other features should function with the following processors: TSYS®, Chase Paymentech™, and WorldPay® (RBS). Any other processors should be verified with our support department before enabling VeriFone SIM version 2_0_4_7 or higher.

Capital One Trade Credit (formerly BlueTarp®) Account

Capital One Trade Credit (formerly BlueTarp Financial service) provides credit management services to Lumber & Building Material dealers and their customers. Capital One Trade Credit (formerly BlueTarp) card holders can be mapped to accounts in the database. Once done, these accounts are flagged as Capital One Trade Credit (formerly BlueTarp) accounts and will operate differently at Point of Sale. Capital One Trade Credit (formerly BlueTarp) customers credit is managed by Capital One Trade Credit (formerly BlueTarp Financial), not your company. For this reason, they are "cash" customers, not "charge." At Point of Sale, the payment method uses the area normally reserved for a receivable's charge; however, the form also displays additional fields specifically related to the Capital One Trade Credit (formerly BlueTarp Financial) card holders assigned to that customer. When a Capital One Trade Credit (formerly BlueTarp) transaction processes, an authorization is done as well as a daily transfer of data between your company and Capital One Trade Credit (formerly BlueTarp Financial).

Statement Delivery

At least one selection is required even if you won't be printing statements. Choices include: print, Email, and fax. It is possible for cash-only accounts to create statement documents, so you should make sure the zero statement setting is N (no) in those cases. These options don't affect other types of document delivery (those are handled at the job-level, modify the master (zero) job or other jobs to affect Email and other delivery for Point of Sale document).

To make processing more efficient, we suggest that you limit each customer to one delivery method; however, there is no enforced restriction and multiple delivery methods are possible.

It's important to point out that the same account options (regarding statements) are applied to all delivery selections equally. For example, it is not possible to Email and fax a customer's statement document, but only Email (and not fax) their invoices. At time of statement delivery, the only overrides provided regard print processing. Optionally, users can choose to either print or not print both statements and/or invoices individually. This ability is not provided for Email and fax delivery which will always use the customer's defaults.

A contact selection is required in the field below the check boxes. Additional information may be required for the contact before choosing either the email or fax options (email address or Fax number). Email and fax capability must be configured before use. All actual processing for email and fax delivery is not provided by the application and relies upon external software, services, and/or hardware that your company must manage independently.

Email and Delivery Email is a fast, easy, and inexpensive way to deliver copies of documents to customers and vendors; however, users should also keep in mind that email delivery is not guaranteed. Even with a valid email address, it's possible that any given message may never reach the intended recipient. In addition, there isn't a foolproof way of confirming delivery without some type of response from, or communication with, the intended recipient. From the application, it's possible to see if an email was submitted successfully or not to your designated SMTP server, but this is still no guarantee of delivery. An email may have a valid domain, but not be a valid account. Sometimes the recipient's mail server will bounce the message back to the sender, but not always. It is also possible for the mail server host or the recipient's mail application to automatically delete any messages it thinks are spam. Before you rely on email for important communication, such as billing, we suggest that your company put in place some type of email verification process. This may be as simple as sending one manual test email to the customer and asking them to reply as confirmation they've received the message. After receiving the confirmation, you then enable email delivery. In addition, it may be wise to provide customers who opt to choose email delivery with some form of agreement, disclaimer, or statement regarding possible delivery issues. For example, this might inform them that email delivery is not guaranteed and that they are still responsible for paying their bill even if they don't receive a copy of their statement electronically. This statement could even be included in the initial confirmation email along with a message that their reply constitutes agreement with your company’s terms.

To Contact Name/Contact Number

Use this list to specify the contact person for statement delivery and payment notification. For printed statements, the application uses the name only and the account address, not the contact's address. The application uses the designated contact's email address for email delivery, and the contact's fax phone number is used for delivery by fax. The main contact for the account is the default selection but you can change it to another contact if desired. When you add a new account, you enter a primary contact in the Name field in the main form area (above the folders). To add, change, or remove contacts, use the Contacts tab. The application assigns contact numbers when you add them; this number will display in the Contact Number field for reference.

Enable Payment Notification

You can use this feature to send a notification to your customer when you have processed their submitted payments (either account or online e-commerce payments). After you set up this feature, the application sends out email notifications to enabled accounts to explain how much you applied to their account or job and when you posted the payment. This notification message reads:

• A payment of <amount> was received for the account <account number>, <account name> at <date, time>.

When you process a notification for an account’s job, this message reads:

• A payment of <amount> was received for the account-job <account number>-<job number>, <job name> at <date, time>.

Note: If your customer pays you in a foreign currency, the appropriate currency codes and symbols display in the email messages.

To enable this feature, see Customer Payment Notification.

Discount Percentage

The percentage entered in this field will be used for calculating an "early pay"' discount for invoices involving a charge method of payment.

If payment is applied to open items or balances by the discount date, a discount will be given.

There are three (3) counters maintained in the data for discounts: Statement, Current, and Applied (paid).

Statement

"Statement Discount" is the total amount of discounts accrued during the previous billing period (the figure from the customers most recent billing statement).

Current

"Current Discount" is the amount of discounts for new or "current" billing period activity (not yet billed).

Applied

"Applied Discount" maintains the amount of discount (prior month's billing) that has been applied during the current billing cycle (period). In certain cases, the discount amount applied can be modified by the user posting payments and credits. This includes the ability to apply more discount than what was indicated by the customer's last bill or current activity. You don't necessarily see "applied" on forms displaying discount information. Instead, you may see a "remaining" amount which is the statement discount less any applied discount. If a user gives more discount than the "remaining" statement discount, the current discount (if any) may be reduced. Negative current discounts are not carried forward.

Discount amounts are calculated at time of invoicing. At the same time, the amount increments the account's "current" discount balance. When billing is processed, the previous cycle's discount is cleared and replaced with the "current" discount. Current discount is then set to zero. Current discount can be affected by credit memos (returns) processed for the account which reduce the figure. Additionally, if all of a customer's prior month discount is used, the current month's discount may be used when posting (applying payments) thus reducing the amount that will appear on the next month's statement.

Discounts are based on the non-net total of a sale and can be calculated either including sales tax or not (a system parameter controls this). "Non-net" means discounts are only calculated for the total of those items that are not flagged to be "net" items in the item database.

Finance Charge Percentage

This is the percentage to be used for calculating finance charges for this customer. If a percentage (above zero) is entered, finance charges will be calculated on any balance greater than the terms specified (next field). Finance charges are usually calculated at the close of the billing cycle, but can be optionally assessed on a different (earlier) date upon request.

Two system parameters exist related to finance charges; they are: minimum finance charge and overdue balance.

Overdue Balance

Overdue balance determines the balance limit required before any finance charges are assessed. For example, if the overdue balance is set to $1.00, a customer who carries a $0.50 balance into the next billing period will not be assessed a finance charge; however, a customer with $1.50 would be assessed the minimum finance charge (see below).

Minimum Finance Charge

The minimum finance charge is the lowest amount of finance charge a customer will be assessed if they carry an eligible overdue balance (higher than the overdue balance parameter). A customer might have a 2% finance charge and carry a balance of $100 past due; if the minimum finance charge is set to $5.00, the account will be assessed a $5.00 finance charge rather than $2.00 (2% of $100).

Terms (Finance Charges)

This setting is used in conjunction with the Finance Charge Percentage field (above) to determine at what point finance charges should be assessed. Choices include: 30+ days, 60+ days, 90+ days, and 120+ days. Finance charge assessment is part of a scheduled process that runs monthly... usually as part of the AR (Accounts Receivable) checklist. Finance charges may optionally be assessed on a different (earlier) date upon request.

For customers using Capital One Trade Credit (formerly BlueTarp Financial) for credit management, the finance charge terms is transmitted with the Capital One Trade Credit (formerly BlueTarp) invoice data. They may use this for determining the terms for payment (period until payment is due) which may affect billing. Please ask Capital One Trade Credit (formerly BlueTarp) if you have questions about how they use this field.

Promised Payment Date & Notes

Sometimes it will be necessary to contact a customer regarding overdue payments. When done, this area allows a record to be made of the contact. Select the date the customer has promised payment and add a text note about the contact.

Under the Receivables application area, there is a report named "Payment Past Due" which uses dates entered in the "promised payment" area for reporting on potentially overdue accounts. This can be a useful tool in monitoring delinquent customers.

Signature Pad

ePad Vision Signature Pad feature only. When you have an ePad Vision device, you can add this account setting to require a prompt for a signature for account purchases and payments. Customers may want this to be able to check on purchases made on their account. If this setting is not added, the ePad Vision signature prompt does not display during the Process Document procedure. When this option is enabled, it displays when the account processes Sales, Orders, Direct Shipments, Tickets, Account Payments, and Returns.

Capture Signature

To display the signature capture prompt for ePad Vision devices for the customer's transactions, select this check box.

Hide Sale Price

To display the Signature prompt without the price, check the Hide Sale Price check box.
To display the price of the items on the device, leave this check box unselected.