Requirements – Financial Consolidation (FC)

General requirements

The system must have the facility to define at least 10 independent companies, each with their own general ledger (i.e. one for each division) for consolidation.
It must be possible for information to be consolidated across the independent general ledgers for month-end reporting purposes.
Each general ledger can, if required, use a different structure for the group chart of accounts.
Each general ledger can be held in a different currency.
There should be a facility to consolidate different ranges of accounts at varying exchange rates.

The system should facilitate the consolidation of general ledgers using different accounting periods.
Users must be able to define their own period start and end dates in the consolidation module.

All codes entered must be validated online, and the code description displayed for visual checking.
It should be possible to reproduce the chart of accounts from any of the general ledgers in the consolidation module as a basis for consolidation.
The system should provide the facility to list all valid codes and their descriptions at points when codes are required to be entered.

The system must allow for at least two sets of budgets to be held against each consolidation account:

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

It should be possible for budgets to be generated automatically from a previous year's actuals or budgets, with a percentage increase or decrease per account code range.

The system must support batch control on input, with agreement of batch controls before acceptance for posting.
Batch numbers will be system generated.
Batches should be limited to a single period.
Batches should be written to a holding file and be available for recall and modification before posting.
It should be possible for valid batches to be posted selectively by the user.
The system should provide the facility for users to define their own transaction types, eg month-end allocation journals.
It is anticipated that the following fields will be held in the batch header:

trial balance,
profit and loss account,
balance sheet,
net movement by account showing opening balance at start of the month, net transactions and closing balance,
other ad hoc reports, particularly in relation to transactions.

It is anticipated that most reports will be produced by means of an end-user report writer. Such a report writer should be able to access all data items in the database to enable a wide range of custom reports to be written.
The report writer must be able to use the following values:

sort routines,
extraction by criteria,
control level breaks,
suppression of zero prints,
ability to round reports to the nearest thousand,
automatic formatting,
on-line viewing,
variable width,
user defined columns,
user defined rows,
arithmetic calculations horizontally,
arithmetic calculations vertically.
It should support the ability to define a range of account codes, so that each each account and its description and other selected fields are automatically displayed.

It should be possible to consolidate one, several or all companies on request.
The facility for reading general ledger data from a disk should be available when producing the consolidation file to avoid unnecessarily using up disk space.
A flag should indicate the status of the consolidation system, i.e. whether the consolidation has been run, aborted, completed, etc.