Requirements - General ledger (GL)

The General Ledger (GL) is the core of the accounting system and relies on data from a series of feeder systems. This data is classified and analysed by the GL.

Feeder Systems

The main feeder systems to impact the GL are the:

accounts payable,
purchase order processing,
accounts receivable,
sales order processing,
payroll and personnel,
inventory, and
fixed assets.

Feeder systems must be considered when defining the user requirement of a financial management system for two reasons, namely:

any GL system will depend for most of its data on feeder systems, and
some information needs will be more properly dealt with within the feeder systems themselves than within the GL.

GL packages are designed to deal with financial management information needs. They can also acquire, store and use non-financial data.

The modern GL is part of an integrated network of operational and management information systems and should be considered in conjunction with these other systems.

Ledger Relationships

The system will provide the facility to have multiple, independent general ledgers.
It will be possible for information to be consolidated within and across general ledgers for month end reporting purposes.
Each general ledger will be capable of supporting and be fully integrated with the sales, purchase and job costing ledgers, payroll and cash book.
Each subsidiary ledger will relate to a separate control account in the general ledger.
Postings to subsidiary ledgers will result in automatic postings to the control accounts in the general ledger.

Account coding

The system will support an account code of the following format:

three alphanumeric characters for the cost centres (departments),
five alphanumeric characters for the expense / income account codes,
3 alphanumeric characters for the analysis codes.

It will be possible for individual elements of the code to be set up separately, so obviating the need to set up every valid combination of elements.
The system will only prompt for analysis codes on those expense / income codes for which they are relevant.

Budgets

The system will allow for three sets of budgets to be held against an account:

original budget,
revised budget,
latest forecast.

The system will allow the following year's budget(s) to be set up without overwriting current year budgets.
It will possible to budget at a higher level than that at which transactions are input, eg some accounts are only budgeted at income/expense code level, others at a more detailed level.
There will be facilities for phasing an annual budget over the various accounting periods on the basis:

of equal monthly apportionment,
a specified monthly profile (of which there can be more than one).

It will be possible for budgets to be generated automatically from previous year actuals or budgets, with a percentage increase or decrease by income / expense code range.
There will be facilities for loading budgets from a micro computer based spreadsheet.

Transaction input

If transaction batching is used by the system, it will support batch control on input. Agreement of batch controls will be mandatory before batches are accepted for posting.
Batch numbers will be allocated by the user.
Batches will be limited to:

a single period,
a single transaction type.

Batches will be written to a 'holding' file, and be available for recall and modification before posting.
It will be possible for valid batches to be posted selectively by the user.
The system will provide the facility for the users to define their own transaction types, eg month end allocation journals, payroll journals etc.
It is anticipated that the following fields will be input on transactions:
Header level:

transaction type (unless input at batch level),
transaction reference,
transaction narrative (minimum 20 characters),
transaction date,
accounting period (unless automatically derived from date).

Line level :

account code,
description (minimum 20 characters),
value,
debit/credit indicator,
quantity (optional),
analysis code (see below).

Analysis codes will be available on transaction records for analysis separate from that based on the account code, eg on some transactions a staff code will be entered, to facilitate analysis of certain types of expense by staff member.
Separate tables of valid analysis codes will be maintained for validation purposes and appropriate descriptions displayed on entry of the analysis code.
The system will support the following types of journal:

accrual and prepayment journals, which automatically reverse themselves in the following period,
skeleton journals, where the bulk of the information is pre coded, only the date and amounts needing to be entered,
recurring journals, which are similar to skeleton journals but with the values pre entered, though capable of modification.

It will be possible for account codes to be looked up during data entry (on the basis of all or part of the account name).
It will be possible for trial month ends to be carried out, ie month end reports produced etc, but still allowing for further transactions for the month to be subsequently input, and reports re run.
It will be possible for bank statement information to be entered, and a bank reconciliation statement automatically produced.
The system will allow bank statement information to be entered automatically from a magnetic tape supplied by the bank.
It will be possible for specified account balances to be automatically reallocated over a range of other accounts, according to pre determined apportionment ratios, ie a number of account balances are apportioned over departments using various bases, such
The system will automatically transfer balance sheet account balances forward at the end of each financial year, and zero-ise P&L account balances.
It will be possible to keep the previous year open for at least six months while processing the next year's data.

Data stored

The general ledger will hold balances for each account code as follows:

each period,
year to date,
budgets for each period,
budgets for year to date,
budgets for year,
each period previous year,
total for previous year,
year to date last year.

The general ledger transactions will contain the following fields:

full account code
transaction type,
batch number,
transaction reference,
transaction date,
accounting period,
transaction narrative,
value,
debit/credit indicator.

Data output

Enquiries

Account level enquiry: The following information will be available on entry of account code:

net movement by period,
net movement by period compared with:

budget, and variance,
previous year, and variance.

on selection of a period it should then be possible to see all the transactions making up the net movement,

the following fields will be displayed at transaction level:

transaction type,
transaction reference,
transaction date,
transaction narrative,
transaction value,
supplier or customer code for postings derived from purchase or sales ledgers.

it will be possible to see all the other general ledger entries relating to a particular transaction on the screen, if required.

Transaction enquiry: It will be possible to enquire on the transaction file on a variety and combination of different fields, the system displaying all transactions which meet the defined criteria. Such criteria will include:

transaction type,
period,
range of transaction references,
range of account codes,
range of transaction values.

It will be possible for wild carding to be used in the search criteria (eg display all transactions with 04 in positions 3 and 4 of the account code).

Reporting

The following reports will be available:

trial balance,
profit and loss account at company, cost centre and analysis levels,
balance sheet,
net movement by account, showing opening balance at start of month, net transactions value (or detailed transactions) and closing balance,
current months transaction listing (by account code).

Other ad hoc reports, particularly in relation to transactions, will be required.
The report writer will be able to access all data items in the database to enable a wide range of custom reports to be written.
It is anticipated that most reports will be produced by means of a general ledger report writer. At a minimum, it will be able to report the following values:

current month actual,
current month budget,
current month last year,
current month variance,
year to date actual,
year to date budget,
year to date last year,
year to date variance.

It will support the following features:

sort routines,
extraction by criteria,
control level breaks,
suppression of zero prints,
ability to round reports to the nearest thousand,
automatic formatting,
on line view,
variable width,
user defined columns,
user defined rows,
arithmetic calculation facilities.

The user will be able to define a range of account codes, so that each account and its description and other selected fields is automatically displayed (ie no need to define each code and description individually).
It will be able to access transaction data as well as account level data.
The system will maintain an organisational structure for cost centres, but will also be able to use alternative hierarchies for reporting purposes.
It will be possible for wild-carding to be used in the selection and format criteria (eg display total values for each cost centre that has a 1 in the third position for expense/income codes that have a 0 in their first position).

Sunday, November 6, 2016