Skip to end of metadata
Go to start of metadata

Major Project Modules

The project is divided in to a number of different modules over two different phases. Each phase has an epic challenge with a number of subordinate modules. Some of the modules are not modules in the truest sense of the word, rather groups of related functionality that depend on similar modules.

This functionality is very high level and based on the early meetings of schools to try and distill the overall requirements of a next generation student accounting system. These core and non-core considerations were documented in the original proposal. Detailed requirement gathering has yet to be performed.

The modules are as follows:

KSA-RM: Receivables Management[1]-- This module handles the core requirements of accounts receivable, including handling accounts, charges, payments, deferments, etc. Almost every other module in the system interacts with the KSA-RM. It includes, but is not limited to the following functions:

  • Account management and maintenance, including names, billing addresses, etc. Also certain preferences, such as refund types, preferred billing methods, etc.
  • Core accounting features, including moving payments, charges and deferments on to the SAR ledger. This will serve as an endpoint for other functionality including the cashiering hub and departmental access.
  • Calculation of summary information to send to the general ledger, including division of charges to different GL accounts.
  • Payment application, including rules for payments, payment types, payment hierarchy, etc., as well as refund management. Also track different types of payments, with different clearing methods, etc. Also includes automated payment de-application.
  • Audition of transactions.
  • Policy enforcement, including charge limits, credit limits, ability of certain users to charge certain transaction types, etc. Also enforce blocks placed on the account.
  • Generate refunds, accept unauthenticated payments.
  • A very basic CRM functionality, including both basic memos on the account, as well as automatically generated events from either student self-service, or other systems.
  • Generation of XML feed to produce billing statements.
  • A number of high-level bad-debt tracking functions, including the ability to write off bad debt proportionally back to the original GL accounts, or to a central account, depending on school policies, account flags for accounts in collections (including information on the agency to which it was sent) and assessment of late fees and other charges based on the status of the account.
  • Tracking of a number of regulatory items, including information required to produce a 1099T, and to keep track of cash posting to an account in a 12-month period.

UI For KSA-RM

Formerly, the access points to KSA-RM were conceived as modules in their own right. To emphasize the importance of UX, as well as encouraging a plug-and-play style architecture, the access modules have been drawn in to the KSA-RM module. More information on this architecture change can be found in the “KSAR to KSA” Documentation.

Staff and Departmental Account Access – This module handles interaction with the system with non-student actors. It is fundamentally a UI to provide appropriate functionality to the KSA-RM. There are also a number of features of this module that feed into the RM system. It includes the ability for counselors to view and update accounts, post transactions, etc. It also provides functionality for other departments to post transactions to the system. The following additional functionality will be provided:

  • Transformation of transactions from an external system to be uploaded to the KSA-RM system (most likely a file upload).
  • Report back failed transactions from KSA-RM.
  • Allow for detailed view of account, including fund allocations.
  • Permit overriding of automatic fund allocation.
  • Allow a “cashiering” view of the student account, permitting rudimentary account access by cashiers.

Student Access – A module devoted entirely to student interaction with the system. This module will share a number of features with counselor access, but will differ in some key ways, especially in terms of user interaction. A subclass of this module may also provide access to the account for authorized third parties (generally parents.) as with staff and departmental access, this is mostly a UI service to the appropriate parts of KSA-RM.

Administrative Access – This module provides access to the system for administrators, including the ability to change and create payment types, payment hierarchy, override certain types of transactions, change interest rates, etc.

KSA-TP: Third Party[2]-- Otherwise known as sponsorship accounts. This is a module that provides a standard way to deal with an often _ad hoc accounting practice, where third parties agree to pay for some portion of a student account. Most often, this is an employer offering some form of tuition benefit. Third-party access to bills and information is handled very differently to student access, and this module will allow that customization, as well as handle the transfer of funds from an employer payment to the student’s account. It will also handle the reversal of funds if a sponsor does not pay the bill. The module will include the following:

  • Creation of accounts for third parties (non-student actors) including some authentication ability.
  • Create and track reusable billing plans allowing customization of types of charges that can be allocated, percentage of charges that can be allocated, payment terms and billing preferences.
  • Automatic creation of reversal transactions if a third party fails to pay for their sponsored student.

KSA-PB: Planned Billing[3] – This module handles payment plans, which can be customized by the institution, adding appropriate charges to the account as defined by the institution (for example, interest, a flat fee, etc.) As with third-party billing, this module will also automatically reverse the charges to the student’s account if the conditions of the agreement are not kept.

KSA-FM: Fee Management[4] – A module in its own right, the fee assessment module will be able to calculate all fees and charges for a student given their demographic data, the course load, and other applicable variables. This will be a rules driven process that will be able to handle extremely sophisticated billing algorithms. The charges can then be posted to the account, or provided to another service (for example, in KE, a student could theoretically present their list of classes, and find out how much it would cost, and create several what-if scenarios.)

KSA-CM: Collections Management[5]

A very small number of functions that were formerly part of core have been brought into a new module, named “Collections Management”. Collections management is mostly out of scope for the purpose of the Sigma project, however, it makes more sense to create a skeleton collections management module that can be expanded at a later phase, than to embed a small amount of collections management in the KSA-RM module.


[1] Formerly Accounts Receivable Nucleus [A/R Nucleus]

[2] Formerly Third-Party Billing

[3] Formerly Installment Plans

[4] Formerly Fee Assessment

[5] Formerly fell under A/R Nucleus

  • No labels