---

 Design of a typical AR System

---

The EadWin/AR will extend the stereotypical AR model by enabling all charges, payments, credits and refunds relating to individual constituents to pass through the EadWin/AR system. This will permit tracking of all constituent related accounting transactions to be performed from one set of programs. The following augmentations will be done to implement and enhance the usefulness of this model:

• A Cashiering and Point of Sale process will be introduced that will allow charges, payments, credits and refunds to be recorded in the system at the time their incurred. This allows real-time transactions to be performed and properly tracked.
• A receipt is provided to customers to show accounting transactions that have taken place. These will be given to the customer at the time the transaction occurred. This is used to help support an online processing system.
• Transactions can be recorded into the system that are not based on individual constituents which will effectively allowing the computer to act like a cash register. This will allow an EadWin presence in a high volume cash based environment like a book store.
• Transaction Control Codes associated with each transaction type defined will allow transactions to be recorded into the system with a minimum amount of clerk input. By choosing a code, the program will know 'Descriptions' and 'Accounts' and much of the other information needed to track and process a particular transaction.
• Multiple Account Types (AKA Sub Accounts, AKA Accounts) will allow customers to maintain through the AR system to the GL several account balances at the same institution. This will allow the system to integrate non logical accounting transactions into one system while retaining a desired separation of transactions and balances. For example dormitory transactions can be kept separate from registration transactions.
• Support for third party billing will allow a customer to apply charges to a patron that agrees to assume the responsibilities of paying for those charges.
  
  

  Major Input Programs used in an AR system.

  The Cashiering Program.

  The cashiering program is responsible for posting individual charges and payments into the AR system.
  
  Typically a customer will present himself to pay for a set of classes or to pay any other expenses. After the clerk adds or selects a constituent from the system a set of charges and payments are recorded into the system.
  
  A Receipt is then printed to act as proof of the transaction.
  
  At the end of the clerks day a cash box reconciliation report is printed. This is used to compare the amount of payments recorded into the computer with the amount of money in the cash box that the clerk has been receiving from customers.
  
  
  Special situations occur which add to the complexity of the cashiering program:
  
  • A student wanting to return or void a transaction.
  • A student wanting to post a charge to another customer's account (aka patron).
  • A student could ask for a refund.
  
  
  

  The Point of Sale (POS) program

  Their are some processes which dictate that the operating environment does not need to be controlled as tightly as the cashiering program provides. The point of sale program will act as a limited version of the cashier program. It will differ from the cashier by making the following assumptions:
  
  • Transactions are not posted to a specific constituent. Rather this will be more like a cash register that starts with a balance of $0.00 and considers a transaction complete when charges have payments recorded against them.
  • A transaction is considered complete when charges and payments are recorded and one receipt is printed. Logic needs to be implemented to prevent multiple refunds being made to the same receipt.
  • Since the nature of the process is to not record the identity of the organization to a particular constituent a mechanism needs to be provided to handle a bad payment.
    POS Receipts will differ in that an individual s name is not available to print.
  • *** Taxable issues need to be defined.

  External Interfaces:

  The AR system will accommodate several external interfaces to take advantage of the resources provided by the AR system. Functions like the bank deposit, general ledger posting report, account balances and other financial reporting tools will be consolidated into the AR program. This will reduce the learning curve of several EadWin programs. External interfaces include:
  
  • Batch input - Several non EadWin/AR programs will generate data that will be imported into the accounts Receivable system. A temporary transaction table will hold these entries. A specification for this input data needs to be defined and a process to validate and input this data needs to be defined.
  • Financial Aid is the primary example of the type of process that will post to this batch file.
  • An Internet collections application would be another example.
  • Direct input of AR Transactions - Several processes will directly post into the Accounts Receivable system without requiring clerk import invocation processes. For example:
    The registration recalculation program computes the amount of class fee's and tuition that a student owes for taking a set of classes. These charges will be maintained in the AR system.
    A fund raising program will record the receipt of moneys into the system. These funds will actually be recorded in the AR system.
  • Query of the AR transaction - Certain processes will query the AR transaction table for constitution related information.
  • The registration recalculation program will query the AR system for a list of registration transactions that were formerly posted by the Registration system.
  • The general ledger posting routines will query the AR transaction table looking for entries that were not previously posted into the AR system. *Perhaps this should be handed in a second temporary file.
  • Query of the AR transaction control code file. Any process that will eventually post into AR will query the AR transaction control codes for information. For example:
    Class Scheduling can be used to setup class fees. When this function is performed a list of potential AR transaction control codes is created.
    Fund Raising and financial aid transaction control codes are both defined in AR. These codes will be used for inquiry purposes by these programs.
  These need to be moved somewhere
  A student wanting to setup a payment plan or setup a charge deferral plan.
  Capabilities to import online batch transactions need to be supplied.
  
  

  Major Output Programs used in an AR system

  Invoices

  An invoice is a piece of paper that acts as a bill. It contains a list of charges. It is given to a customer who will then pay the invoice. Invoicing is the process of creating invoices. Since charges are recorded into the system at the time the charge was made, the invoicing procedure will be mostly a reporting process. Invoicing usually occurs at intervals not usually coincident with when charges take place. Examples are: A student has an employer pay for a class, or, a business wants the school to teach a class and is willing to pay for the class. In both cases, charges are recorded into the system but are not payable until a later time, usually when the class starts. Ramifications of this are:
  
  • There is generally a delay between when charges are posted into the system and when charges are actually billed to the customer.
  • There is generally a delay between when payments are received into the system to clear unpaid transactions.
  • Normally details of an invoice are usually only printed once. Reprinting the same invoice has audit control ramifications.
  
  Q: When is the invoice delivered to the customer?
  A1: HCC - usually after the class has been held.
  A2: MHC - usually when its been determined that the class will not be canceled and no more transactions are necessary, probably when the class starts.
  
  Q: When are the charges put into the system?
  A: In an accrual based accounting system charges are put into the system at the time the charges are incurred and depending on institution policies may either be posted to the general ledger at roughly the same time charges are incurred or when they are billed to the customer.
  
  Q:When is the payment of the invoice considered late?
  A: The aging report should base the timeliness of payment on when the invoice was sent not when the charges were posted.
  
  Q: How should the payment of the invoice be applied to the constituents account?
  A: Choices are pay off the invoice, pay off the entries on the invoice, pay off the balance of the customer account. HCC - pay off the balance
  
  How are the payments of invoices tracked, for example should the invoices print an invoice number or is a time stamp sufficient?
  Should this be a site defined invoice number or an internally generated number?
  Should this number be used as the key to recording a payment?
  
  An invoice number is useful if our payoff logic requires an invoice number because the institution tracks payment status of individual invoices.
  
  

  Statements

  Statements are usually sent to customers who have an outstanding balance. They are usually printed monthly and contain details of what invoices have been generated and what payments have been received over a given time span.
  
  

  Aging Report

  An aging report contains a list of all customers who have a balance. The balance of these customers are divided by intervals of time. Organizing data into aging columns way allows a clerk to quickly determine who is late paying bills.
  
  

  Audit Trail

  The audit trail report contains a list of all transactions that have been unexpectedly changed.
  
  

  General Ledger Posting Report

  The general ledger posting report is a report which contains a summary of all financial transactions that have been posted into the Accounts Receivable system. The transactions listed on the report will only ever appear in a general ledger posting report once. The transactions are sorted and summarized in such a way that a general ledger clerk can record the entries with a minimum amount of work.
  
  

  Receipts

  Receipts are printed by the Cashier and POS programs after charges and payments, and any other transaction has been posted into the system against a customer. The receipt is a list of transactions that were recorded. It is used as a manual form of evidence that transactions took place. Transactions listed on a receipt should only be printed once.
  
  

  Cashier based reports

  Usually a cashier will print receipts (which are described above) and they will print a cash box summary report which should contain totals of how much money should be in the cash. This report can be triggered at anytime by the clerk for a routine verification of totals. It should also be printed before the cash box is officially cleared.
  
  

  End of Day reports

  End of day reports are printed at the end of an accounting day. They summarize transactions that have been recorded into the system through the day. The organization and requirements of these reports varies from installation to installation.
  
  

  Functional capabilities and their use in an AR system.

  Recording of a charge

  A charge increase the amount of money a customer owes. It is usually input into the system through the cashier, POS, or via an external interface. When a charge is input into the system, a time stamp, a reference to the customer incurring the charge, a transaction control code, and an amount is usually recorded. Some charges usually have an amount associated that never changes. Sometimes a charge is billed to another constituent. Sometimes a charge can reference another constituent. A POS system may need to know if this particular transaction is taxable and if so at what rate. Charges are usually payable at the time the charge is made. For instance if a student signs up for a class, the student is expected to pay for the class immediately. However several situations could occur that change the immediacy of the collectable:
  Student has a relative or employer pay for the charge. Normally the relative or employer would not be billed until when the class started. This would allow the student time to reconsider the enrollment, and give the school a chance to cancel the class.
  Student arranges to pay for the charges at a different time.
  Student is expecting financial aid.
  
  Recording a Class Fee
  Class fee's and tuition charges will be posted into the AR system with an external interface program.
  
  

  Promissory Note vs. Pay-as-you-go

  Promissory notes are promises to pay for a product or service. Once defined it is considered a receivable that the customer agrees to pay at a later time. Usually a customer could agree to pay an entire balance at once or in increments spread over time. Normally the general ledger will be billed for the entire amount of the note in a special asset account which will decrease as payments are made.
  
  Pay-as-you-go is a concept which states the customer will pay for products and services as they are consumed. A discontinuance of the services stops the obligation. If pre-arrangements are made for a pay-as-you-go type of billing, the general ledger is not usually notified of these pre-arrangements until a service is rendered and the charge becomes payable.
  
  Graduate Schools of America charges its students $3000/mo, therefore it could be said they run a pay-as-you-go type of billing system.
  
  

  Recurring Charges vs. Deferred Charges

  A recurring charge is a charge that occurs more than once, usually at defined intervals. A deferred charge is a charge whose obligation has been postponed to a date later than the date the charge was incurred. It is up to the site and the policies it has created to determine whether the amount of the charge should be posted to the general ledger.
  * Promissory notes could be setup as either of the above.
  
  

  Finance Charges

  Customers who do not pay in a timely manner will sometimes be charged small amounts as an incentive to pay future bills on time. These charges are called finance charges or interest charges. Normally these charges are applied monthly and are based on an outstanding debt.
  
  

  Recording a payment

  A payment reduces the amount of money a customer owes. It is usually input into the system through the cashier, POS, or an external interface. When a payment is input into the system a time stamp, a reference to the customer incurring the charge, a transaction control code, and an amount is usually recorded. At the end of a Cashiering session or a POS session, a clerk will add up the payments during the session and compare that against the amount of money in the cash box. Giving the ability to divide the payment types, gives the clerk the ability to determine which type of payment needs further reconciliation, and the installation site the ability to create a computerized deposit report. Some payments require additional information like a check number or a credit card number in order to complete the payment transaction.
  
  

  Credit Card Payments

  Constituents will sometimes pay with a credit card. Depending on the school credit card payments are processed differently. In this version, credit card payments will not be directly handled. Instead the transaction record will have preallocated a number of user configurable fields. The transaction control code editor will allow the definition of these user configurable fields on a code by code basis.
  For sites who support credit cards via a machine placed at each computer terminal, payment type transaction control codes can contain additional attributes which the clerks can then use to post authorization numbers into the transaction.
  For sites who support credit card payments via an end of day process, the transaction control code editor can have attributes setup to capture the information of a credit card. The clerks can then post credit card information into the transaction.
  Canada: Refunds based on credit card payments should be sent back to the Credit Card company.
  Internet accounting?
  
  

  Recording a credit

  A credit reduces the amount of money a customer owes. Discount is a common example of a credit. It is usually input into the system through the cashier, POS, or external interface when a non-cash financial transaction occurs. When a charge is input into the system a time stamp, a reference to the customer incurring the charge, a transaction control code, and an amount is usually recorded.
  
  

  Recording a refund

  Refunds are issued when the student has a credit balance and desires to clear the balance. It is usually input into the system through the cashier, POS, or external interface when a non-cash financial transaction occurs. When a refund is input into the system a time stamp, a reference to the customer incurring the charge, a transaction control code, and an amount is usually recorded.
  Rules:
  A refund cannot be greater than the credit balance.
  A refund can only be input if the customer has a credit balance.
  
  

  Refund Requests

  Some sites do not allow a clerk to perform a refund. So the question of when is a refund recorded into the system is an issue. The basic premise is .. is the refund recorded at the time the refund request sent to the accounting department, or at the time the refund check has been drafted?
  
  

  Changing transactions

  Normally speaking transactions should not be changed. To fix an incorrect entry a correcting transaction should be entered which would have the effect of offsetting or correcting the original entry in the account. The reason for this inflexibility has to do with the fact that the Accounts Receivable process is a controlled process and changing an entry is a violation of the control imposed on the process. Exceptions to this have to do with notes and reference numbers that are posted against this transaction.
  
  

  Voiding a transaction

  The main reason that clerks tend to want to remove transactions rather than posting correction transactions has to do with the fact that both the wrong transaction and the correcting transactions are printed on reports which gives a sloppy and confusing appearance. Capabilities should be supplied to hide these entries on reports. Reports should also be available which show any changes to the transaction files.
  
  Transactions are voided when a transaction is considered incorrect. Usually a clerk will point to a defective transaction and press a Void button. What will happen externally is all evidence of the transaction will be removed from the system from a cashiers point of view. Internally however a negative transaction is created. This is to account for the fact that the transaction may have been posted to the general ledger. Only transactions that the clerk can input into the system, as opposed to transactions loaded via batch processes, can be removed from the system.
  
  Miscellaneous or Unorganized
  

  Account Types

  Multiple Account Types (AKA Sub Accounts, AKA Accounts) will allow customers to maintain through the AR system to the GL several account balances at the same institution. This will allow the system to integrate non logical accounting transactions into one system while retaining a desired separation of transactions and balances. For example dormitory transactions can be kept separate from registration transactions.
  
  Invoices use account types as sort categories or detail breaks.
  Statements could be filtered by account types.
  Aging reports could be divided or subtotaled by account types
  Interest charges could be applied by account types.
  Receipts should be divided by account types.
  Daily reports, Audit trails, and transaction dump reports should be filtered or subtotaled by account types.
  
  

  Transaction Control Codes

  Transaction Control Codes are used to define a transaction that is recorded into the Accounts Receivable system. Each type of transaction that the installation site will recognize should create a transaction control code. Transaction control code attributes include:
  
  • A code which is used for sorting purposes.
  • A password is used to restrict usage of a particular transaction control code to clerks who know the password.
  • The description is used to describe the transaction in a way that the customer can understand.
  • Its usage within the EadWin environment. For example whether this is a charge, a credit, a payment, a refund, or a registration class fee charge.
  • A general ledger account number that the accounting department can understand the nature of the transaction.
  • A cash box accumulator to define which cash box was affected by this transaction.
  • Record the definition of additional input fields that can be used during the input of the transaction.
  • A default amount.
  • Which account types can use this transaction control code.
  
  *HCC imbeds financial and budget years into their general ledger account numbers. Consequently methods could be provided to allow the school to create new transaction control codes, or update the codes on a batch basis would be an assistance to them
  
  

  Cash Box

  A cash box is a physical container that is used to hold money. This is sometimes called a cash drawer. The computer keeps track of a cash box because the Cashiering/POS system expects clerks to post funds into these cash boxes. By tracking the cash box the comptroller can have the computer further assist cash box reconciliation processes and deposit report processes.
  
  

  Cash Box Accumulators

  A cash box is a physical container that is used to hold money. Cash box accumulators are the little slots in the cash box used to hold the different types of moneys. Payment and refund type transactions use cash box accumulators to categorize the money type for easier reconciliation.
  
  

  Satellite Cashiering

  An example of satellite cashiering would be a Colusa branch of Yuba College who is recording financial transactions. YC does not have immediate notification of what is happening in Colusa and consequently problems could arise mostly dealing with security related issue.
  
  

  Discount Processing

  Several sites have requested that we incorporate some form of discount processing system into AR. Unfortunately a capable system has not yet been defined. The current method of recording discounts is to create a discount type credit and post the discount manually using the Cashier or POS system.
  ** How about a discount mechanism based on an inventory system that gives discounts by customer.
  
  

  Collection process

  An unpaid collectable poses a problem in Accounts Receivable systems. If a customer does not pay a balance and the installation cannot collect this amount then the installation has two courses of action:
  The school writes off the balance, and possibly records a hold code.
  The school passes the debt to a collection agency. Normally in this case a hold code is placed on the customer, and the school is directed to not take any actions with this customer until the collection agency has cleared this account.
  In either case, the unpaid transactions need to be removed from the system and the accounting department needs to post special transactions.
  
  

  Security

  Since the Accounts Receivable process deals with financial information security and safety is important. Issues include:
  Who are which clerks are allowed to use this program?
  What can the clerks do when they do use the AR program?
  What happens when invalid information has been entered into the system?
  What kind of transactions can clerks do? Clerks can change notes that are posted against the transaction.
  What should happen when the power is lost?
  
  

  Data Archive and Purge

  Accounting transactions tend to accumulate rather quickly. While a large history of transactions is in some cases desirable, generally speaking, the more transactions that are on-line in the system, the more difficult is to manage. And in reality detail is only truly needed until it is paid off, and completely posted into the general ledger. Therefore an archival and purge process should be defined to remove accounting transactions at regular intervals. Since the transactions are stored mostly in a balance forward kind of environment a mechanism to move or remove transactions from accounts with a $0.00 balance would be the most economical to create. Issues involved include:
  Should accounts that have a balance be archived and purged?
  Should entries be moved or deleted?
  How are the moved entries accessed by the system?
  
  
  
  
  
  

  ---

  Add note about this particular page
  
  
  

  Date Created:	03-06-1999
  Date Modified:	03-06-1999
  Date Freshened:	06-19-2000

  
  Return to Object Models