Development of Accounting Information Sy

Development of Accounting Information System: Enterprise, Database
and Interface Modules!
A number of accounting software packages are available offering a variety of
features. They cost much less than what customized accounting software
would cost. However, these software packages offer only the structure for
accounting information systems. At the most, they reduce the programming
effort for accounting information systems.
The development of accounting information systems is much more than the
software for ledger posting and report formation. It also involves establishing
procedures for capturing data and distribution, as well as analysis of
accounting information.
The development of an accounting information system is explained with
special reference to the requirements of a medium to large sized business
enterprise. However, these steps would be common to most other information
systems in a business enterprise.

1. Enterprise Module:
The enterprise module of information system development involves
identification of basic entities and their interrelationships, identification of basic
activities and regrouping these activities into sub systems. Then, the priorities
are decided on the basis of cost-benefit analysis for the enterprise.

Identifying Entities:
A large number of entities exist in a business enterprise and the list is as
varied as the business activities are. However, at this stage, the primary
concern is to identify the broad entities, each of them containing a group of

elementary entities. Kerner5 points out six basic entities in a business
enterprise.
They are customers, products, vendors, personnel, facilities and money. In an
accounting information system, there are three basic entities, namely,
transactions, account and processing period. The interrelationships between
these entities can be expressed using the E-R diagrams as shown Fig. 8.2.

The transactions shall be of different kinds, such as receipts, payments, sales,
purchase, acquisition of assets or repayment of liabilities, etc. and each of
them can be called a lower level entity. Similarly, accounts can be of different
kinds, such as assets, liabilities, revenue and expense.
Each of these heads can have lower level entities such as fixed assets and
current assets. These entities can be further split into still lower level entities
such as land and building, plant and machinery, etc. However, at this stage,
the broad entities need to be identified. The details are worked out at the time

of designing the databases.

The entities are identified in the light of and with a view to defining the scope
and focus of the information system. For example, if the information system is
being viewed as a strategic information system, the broad entities shall be
identified in the light of the strategic thrusts that the enterprise plans to give to
its activities with the help of the information system.
These thrusts could be cost minimisation, customer service, product
differentiation and strategic alliances. The basic entities in such a case would
be customers, channels, competing enterprises, products, etc.
Activity Analysis:
Another important aspect of enterprise module is identification of activities
associated with the entities. These activities are broadly identified in the form
of relationships in the E-R diagrams. However, details are obtained with the
help of activity analysis. The existing organisation structure is an important
source of information regarding the broad activities undertaken by the
enterprise.
But, in order to develop information systems that are independent of the
current organisation structure, it is essential to base the activity analysis on
the basic entities already identified above. The next level of activity analysis

involves identification of the life-cycle activities. In the case of ‘transactions’
being one of the basic entities in an accounting information system, there are
four broad life-cycle activities, namely:
1. Purchasing life cycle
2. Production life cycle

3. Revenue life cycle
4. Investments life cycle
Similarly, the processing period has two basic life cycle activities, namely:
a. Planning and control life cycle
b. Internal and external reporting life cycle
These life cycle activities are on-going activities and are performed
continuously. Each of these activities may be sequentially related to some
other activities. The third level of activity analysis involves splitting of the lifecycle activities into functions.
For example, each type of transaction must be initiated and recognised; then
the data regarding the transaction must be captured, coded for future classification, classified, summarised and reported. These functions are to be
performed differently for different types of transactions. The process of
defining the functions focuses only on those activities that create, update or
use information in the database of the enterprise.
At this level of activity analysis, the activities are self contained, have clearly

defined starting and ending events or nodes and an identifiable person or a
group of persons responsible for performing the function.
These functions can then be divided into sub-functions until the functions are
specific enough to define the module for computer programs. The splitting of
life-cycle activities into functions and sub-functions helps in identification of
functions that are repeated in more than one life-cycle activity.

For example, the function of classification of captured data may be performed
in purchasing and marketing life cycles. Such activity analysis helps in
identifying opportunities to improve the existing design by:
1. eliminating the redundant functions
2. combining the duplicated functions
3. simplifying and improving the processing methods
The redundancy can be identified by careful analysis of the activities. The
activities that are likely to offer opportunities for improving the processing
include activities:
a. That are performed elsewhere as well
b. That can be combined with other activities
c. That can be handled by some other person as well
d. That can be performed at some other stage of the life cycle that do not add

any value to the product or service of the information system.
A word of caution here is that not all redundancies are bad. In fact, some
redundancy or duplication may be intentionally allowed to creep into the
system. This may be done in order to improve performance and reliability of
the system.
For example, some of the duplication may be necessary for ensuring
simplicity of procedures and improving the speed of processing. Elimination of
redundancy may result in ‘putting all eggs in one basket’ and thus may affect

reliability. The risk of unexpected implications and low returns from proposed
new method or procedure are other factors that deserve attention before
changes are proposed in the information system.
Grouping Activities into Sub Systems:
After the activities are defined using the top-down approach adopted above,
they are regrouped to form sub systems. An important decision to be taken at
this stage relates to the basis of grouping. There may not exist one single
objective criterion for deciding which sub system an activity belongs to.
The present organisation structure can provide one of the bases for grouping
of activities. But, the present organisation structure may undergo changes and
the usefulness of the information system may be lost.

To group the activities into sub system, we take help from the organisation
theory.One of the essential features of any good organisation structure is that
it aims at facilitating coordination of activities.
An effective system of communication is essential requisite for better
coordination. It is essential, therefore, to group activities in such a way so that
communication is facilitated within the group and the need for inter-group
communication is minimised.
For the purposes of representing and documenting the grouping of activities
into sub systems, structure charts or hierarchical block diagrams are used.
Figure 8.3 gives structure chart showing the components of the revenue cycle.

Similar structure charts can be prepared for other clusters of activities and,
finally, these sub systems are integrated with each other providing the building
blocks for an accounting information system.
The sub systems so identified by clustering of activities are serious
contenders for being entities in the organisation structure. The advantage with
the clustering method for grouping of activities is that the grouping is based on
functions and resources, and not on geographical regions.
Such a clustering on the basis of functions ensures homogeneity among the
members of the group of people associated with each of the sub systems.

Impact of information system organisation on organisation structure is not uncommon.
Often, introduction of information systems has been accompanied by changes
in the organisation structures because of the fact that new information
systems change the way people work in an organisation.

It is, therefore, all the more important that information system designers work
in active association with the organisation development people while grouping
of activities into clusters and sub system is being done. This ensures not only
that the new structure is more pragmatic but also more acceptable to people.
In such cases, the transition from old system to new one is less painful and
less expensive.
Setting priorities:
Once the sub systems have been identified and integrated as a whole, the
priorities need to be determined among the various sub systems and features
in each system. The information system would require commitment of financial
resources.
In addition, there may be implicit costs of the new system in terms of
necessary changes in the process of operations. It is, therefore, essential to
weigh the pros and cons of each sub system and sub- subsystem before they
are designed and implemented.

Each sub system is evaluated on the basis of well-defined evaluation criteria
defined in terms of the critical success factors (CSF). These factors have
already been identified in Section 8.2.
The other method is, brainstorming, wherein the relevant people in the
organisation get together to identify the factors that deserve consideration in
determining priorities. Free flow of ideas is encouraged at the first stage.
The underlying principle, here, is that no idea is silly or irrelevant at this stage.
During the second stage, the process of elimination begins and after
discussions, the suggestions are finalised.

Once the list of factors is finalised, relative weights are assigned and a
criterion’s function is defined to evaluate each component of the proposed
accounting information system.

2. Database Module:
Accounting information system processes large volume of data. Managing the
data is, thus, one of the major considerations in the process of its
development. There are two basic approaches to data design, namely:
a. The traditional, application oriented approach, and
b. The database approach.

Traditional approach:
The traditional approach to data design is application oriented in the sense
that for each application a separate set of data files is generated as per its
requirements. In other words, the data files are dedicated to a given
application and are in a way ‘owned’ by the application.
For example, an account receivables application shall have the customer
master data file, a sales transaction file and a receipt from customers’
transactions file. These data files are used only for the accounts receivable
application.
This approach is suitable for smaller accounting information systems because
of its simplicity. However, as the information system grows in terms of volume
of data and complexity of analysis, it gives rise to certain problems as well.

The fundamental problem with the traditional approach is that the application
programs are dependent on the data files they use and manipulate. As a
consequence, any change in the data file (in terms of addition or deletion of
data item) necessitates changes in all the programs using the data file.
This data dependency discourages changes in data files leading to inflexibility.
In the absence of any tool for performing routine type data management activities on the data, such facilities are to be included in the programs using the
data file. This complicates the program. Another problem relates to meeting

the ad hoc query.
For unexpected kind of query, special programs need to be written. Such
special programs take time to develop and have only one time use and thus,
are expensive. There is a lot of duplication in recording of data items.
For example, the data items such as customer name, invoice number, price,
etc. may be included in transaction files for sales order processing application,
as well as accounts receivable application. This causes redundancy in data.

The data redundancy results in inefficient use of storage media. It also affects
the quality of data as updating of a given data item may not take place in all
the files where that data item is stored.
Database approach:
The modern approach to data design is database approach. This approach is
based on the assumptions that several applications require data sets that
have a lot in common. It is, therefore, better to have a common repository of
data that meets the data requirements of each application in the information
system.
The common repository is called the database and is managed by a
management system called Database Management System (DBMS). The
DBMS is software specially designed to manage the data in databases

according to the requests from application programs, as well as from those
coming directly from users. The conceptual design of database environment is
shown with the help of Fig. 8.5.

The database approach takes care of the problems of the applications
approach. It ensures data independence as the DBMS takes care of the flow
of data from the database to application programs. The user application need

not bother about the location of the data in database. A data dictionary is
maintained and data can be called using the words specified in the data
dictionary.
The database approach also reduces the size and complexity of the
application programs as the routine kind of data processing operations such
as sorting is done by the DBMS. The DBMS is also used for serving the needs
of ad hoc query. The DBMS uses Structured Query Language (SQL) as the
language for communication between the user and the database.
The language is very simple and quite close to English. This ensures that the
user can get information from database as and when required. The amount of
training required by managers for making ad hoc queries is minimal and few
hours of training can provide the elementary skills for using the language.
Perhaps, the most important advantage of database approach is the reduction
in the redundancy in databases.
There are many models that are commonly used in design of databases.
However, the modern approach is to follow the E-R Model of data base
design. This approach is top-down approach and the E-R charts drawn earlier
in the Enterprise Module become the starting point.
For each entity and relationship, attributes are identified and documented in
the Extended E-R diagrams (EER diagrams). In an accounting information
system, the EER may be drawn for each entity (transaction and accounts) and
the relationship (effect) for the transaction accounts is shown in the E-R
diagram. For example, for a sales transaction, attributes may be specified and
documented as shown in Fig. 8.6.

These attributes become the data items (fields) in a record in the data file for
each entity (in this case sales transaction file). Similarly, for other entities and
relationships such Extended E-R (EER) diagrams are drawn.
Once these attributes are identified, it is likely that some of the attributes shall
be common in different EER charts. To avoid duplication of such common
attributes, normalisation of data is undertaken.

3. Interface Module:
An interface module defines the sources of data items and the formats of
input/output and dialogue screens that shall be used in the system. It also
defines the report formats and the screens for navigation from one part of the
information systems to the other.

In other words, the module is concerned with defining the interface between
the user and machine. The importance of the interface module has increased
due to increased communication between user and information systems.
Both the data entry and data query have become interactive. In many cases,
input forms are eliminated from the process and the data entry takes place
directly. The changing requirements of data query render many report forms
too rigid. Interactive report screens provide greater flexibility in data query and
permit user defined report formats for viewing and printing.
Input screens:
The input screens are defined in the light of natural process of the business
activity. Therefore, they depend primarily on the forms that are used to record
manually the data when they are first received by the enterprise. These forms,
in an accounting information system, may include invoice, purchase order,
sales order, expense voucher, etc.
Thus, in the interface module, forms are also reviewed; redesigned and input
screens are defined in the light of forms used by the enterprise. In an
accounting information system, one needs to be more careful regarding
screen design.
A minor improvement in input screen that saves data entry may result in
substantial savings because the number of times the data entry screen is
used is very large. The following factors may be kept in mind while designing
input screen:
(a) Matching with forms:

The input screen format must match with input forms. Sometimes, it pays to
adopt the same format that is used by the input form. To the extent possible,
even the colour of the background of screen may be matched with the colour
of the input form.
(b) Interactive:
The input screen should be interactive. It should point out errors in data entry
right at the time of entry and permit corrections. Each data item must have
some data validation condition and any violation of such data validation
condition should be automatically highlighted at the time of data entry.
For example, a data entry screen for entry of invoice must point out mistake in
entry of date if the date is invalid. The date may be invalid because it is
outside the accounting period or the month entered is greater than twelve.
(c) Consistency:
The input screens should be consistent in defining terms and location for
certain common types of data items. It helps in reducing the training time as it
improves familiarity; for example, date of transaction may always be placed on
the right hand corner of each of the transaction document.
(d) Simplicity:
One of the basic features of a good input screen is the simplicity. Too many
highlighted sections, blinking of values or attributes, or putting too many boxes
and underlining only add to complexity and confusion. Sometimes, beeps are
used to point out data entry errors. There should be judicious use of such
beeps and generally, these should be avoided.
(e) Flexibility:

The input screen should be amenable to modifications. It should permit users
to make modifications in terms of addition or deletion and relocation of data
item. The procedure for modification should be simple. These days, the
Screen Generators available from various software manufactures offer the
features such as drag and fix/drop any data item from the screen by using
ordinary pointing device like mouse.
(f) Custom made:
The screens must be custom made for each category of user. This would
reduce unduly long starting and entry procedures.
Report screens:
The reports may be prepared for further analysis by some other computer
program or by the user himself. The data directed for processing by computer
programs, such as spreadsheets, statistical packages, word processors, are
kept in data files.
It is better to put them in standard data format so that they can be accessed
easily. The reports meant for users are normally kept in the form of text,
tables, and graphs. Efforts should be made to ensure that the reports are
made out and communicated timely, accurately, clearly and at a low cost.
Dialogue screens:
The dialogue screens are the ones that are used for identifying and
performing the tasks in the information system. They define what can be done
with the help of the information system, how to navigate from one
task/procedure to another and how to perform various tasks that the
information system permits.

These screens should be simple and unambiguous. The simplicity can be
introduced by providing Graphic User Interface (GUI) and having limited
number of menu items in one screen. The procedure for navigation from one
menu to the other should be simple, in right sequence and easy to follow. It
should also point out mistake in exercising options and be prompt for
correcting procedure.
CASE tools for screen design:
A variety of CASE tools are available for designing forms, screens and
reports.These tools have the advantage of offering designing environment that
is flexible and simple to understand even for a new user.
Since these tools have screen prototyping facilities, it is possible to have
greater involvement of users in the process of screen designing. Of course,
such tools permit quick changes and improve productivity of programmers by
generating codes for final implementation. This results in reduced
development time.
Once the forms, input/output screens and dialog screens are ready, they
should be tested and modified accordingly. The forms and screens designed
using the CASE tools can be easily modified. Therefore, efforts must be made
to improve the acceptability of the system by proper testing and modification
of forms and screens.

4. Applications Module:
This module extends the sub systems already identified in the enterprise
module. For each sub system identified in the structure chart, detailed
processing procedures are defined in this module.

In other words, the application module is primarily concerned with the
processes involved in converting the input data into values that shall form part
of the reports as defined in the interface module. It may be noted that only
those processes are to be defined that
(a) Change the values in the databases, or
(b) That are not parts of the database but are required in the reports defined in
the interface module.
The values that already exist in the database can be accessed using DBMS
query language as per the requirement of users without development of
programs for this purpose. Thus, the task of application module is reduced by
the work already performed in the database design and screen design.
Data flow diagram:
The role of the manager in this module is basically identifying the basic
processing procedure. The detailed algorithms are generally defined and
documented by information system professional, of course, with active help
from the manager.
The tool used for expressing the processes to be performed for converting the
input data into output is the Data Flow Diagram (DFD). It describes the flow of
data. It defines what must be done and ignores how it is to be done or how it
was being done earlier. This approach permits changes in the system and
weaknesses of the existing system can be removed following this approach.
DFD symbols:
There are four basic symbols used in DFDs. They are:

(i) Terminator:
Terminator is an external source of data flow or external sink of data. It is an
external entity or object such as customer, vendor, shareholders, etc. Since
the terminators are external entities, the communication between the terminators is excluded from the system. The terminator is symbolised by a rectangle
(generally, shadowed) and the label is placed in the rectangle.
(ii) Data flow:
Data flow carries a series of data items regarding the event that is initiated by
the terminator. It is symbolised with an arrow in DFD and the direction of the
flow is indicated by the direction of the arrow. The arrows are, generally,
labelled unless they are directed to or from data files. As pointed out earlier,
data flows between two terminators are not included in DFD and thus, data
cannot flow directly between two terminators.
(iii) Process:
Process transforms the incoming data for redirection to data store or
terminator. It is symbolised by a rectangle with rounded corners or a circle. It
is labelled with a verb, of course.
(iv) Data store:
Files are the data stores in information systems and are represented in DFDs
in form of open rectangles. Generally, they correspond to tables in databases.
A partial view of the data flow diagram for sales order processing is presented
in Fig. 8.7.

It may be noted that some supplementary symbols and minor variations in
symbols representing various components of DFD are also in use. The above
symbols are the ones most commonly used and are as per the graphic
convention suggested by Gane and Sarson.
Many a time, a manager finds drawing of DFD very difficult and frustrating
experience. Each time one draws a DFD, one finds to have ignored one or the
other aspect of the data flow. Fortunately, the CASE tools available have
facilities for creating and modifying DFDs. However, beginners are advised to
follow the following steps to overcome this problem:
(a) Identify all input data flows and output data flows separately along with
terminators, putting input data flows on left side and output data flow on right.
(b) Label the terminators using data flow noun or adjective names.
(c) Identify processes forward from input data flows and backward from output
data flows till they meet in the middle.
(d) Label the processes using verb names.
A manager must be prepared to redraw the DFD because many a time, the
data flows become clear to manager only after drawing DFD. User

involvement at this stage is very useful not only in reducing the effort on the
part of manager but also in improving the DFD.
Testing of DFD:
It is suggested that the DFD must be thoroughly tested before it is finalised.
The following are some of the common errors in DFD design:
a. The terminator label may be the name of a person or an enterprise instead
of class. For example, a terminator may be labelled as M/s. B. R. Ltd. instead
of sole vendor. Another mistake could be that the carrier is put as terminator
instead of the external entity directly associated with the data flow.
b. Data may flow directly from one terminator to another terminator.
c. No data flow may be indicated to or from a process.
d. Data flow is indicated from terminator to a data store (file) or from a file to
terminator, or between two files without processing.
e. The processes are labelled as objects, such as invoice or a noun such as
booking clerk.
After the DFDs are drawn for each sub system, future processing details may
be chalked out and described in structured English (psedo-codes). These
psedo-codes are later used for coding the applications. The manager’s role in
this process is limited only to helping the information systems professional in
identifying and understanding the algorithms involved in the processing.

5. Implementation Module:

This module is primarily concerned with testing of the system, training the
users and installation of the system.
Testing the System:
The testing of various modules is done at various stages of development
process. The golden rule to be kept in mind while testing is that the testing
should be done with a view to identifying the ways in which the system is likely
to fail. It should not be with the objective of proving that the system will work
as per the design specification. Testing of system is the process of seeking
answers to two basic questions:
1. Whether the information system serves the information needs of the
enterprise? The process that seeks answer to this question is termed by
information system professionals as system validation process.
2. Does the information system function correctly? The process of verification
seeks answer to this question.
As the nature and degree of seriousness of errors are different at different
stages of system development, different tests are administered at different
modules and at the system as a whole.
Unit test:
The tests used at module level may be called unit tests. These tests are
performed to detect errors in interfaces, databases, arithmetic operations and
control logic. They are performed by running a module of the information
system on test data specially designed for testing whether the system:
a. Accepts incorrect type of data(e.g. accepts numeric value for name);

b. Accepts out of valid range data (e.g. accepts date with month greater than
12);
c. Causes incorrect jumping from a procedure to another procedure.
System test:
As the unit tests are conducted in isolation, it is essential that the integration
tests should be conducted to check whether or not these units work correctly
as a group. Due to diversities of nature of errors different testing strategies are
to be followed to check validity and verify the system. Fertucksuggests three
strategies for testing the information system:
(a) Clear box testing:
In this strategy, tests are designed to establish whether the procedures
followed for processing match the requirements of the application. This may
be achieved with the help of review by fellow information system professionals
who were not directly associated at the development stage.
Alternatively, structured walkthrough method may be used. In this method, a
group of persons reviews the procedures, first having a look at error-prone
parts and identifies corrections that need to be made. Then, the group
members assess the output that the system will offer for a given type of input
and test whether the output of the system is correct or not.
(b) Black box testing:
In this strategy, the system is tested for invalid data or data that may cause
error in the functioning of the system. The output is checked to establish
whether any error has occurred. For example, data may contain negative

value for quantity ordered or a fractional value for a variable that can take only
whole value.
(c) Ticking box testing:
This strategy assumes that it is never possible to deliver a totally error-free
information system. Thus, after all testing and modifications, it is necessary to
estimate the number of errors still remaining in the system. To estimate this
number, a few errors may be deliberately introduced in the system. Then the
tests are again conducted to detect errors.
The proportion of introduced errors detected is taken as an estimate of
proportion of real errors detected during the earlier tests. Thus, if 90% of the
introduced errors were detected during the ticking box testing while a total of
450 errors were detected originally during the clear box testing and black box
testing, it means that 50 real errors continue to remain undetected in the
system.
Installation:
Installation is a process of replacing the old system with a new system.
Broadly, there are four approaches to installation. The ‘cold’ installation is
done when the old system is immediately discontinued and is replaced by a
new system.
Such an installation has the advantage of quicker psychological adjustment
with the fact that the new system is to be used. However, such an approach
may not be suitable if old data from the earlier system are valuable or the new
system has some problems. For installing accounting information systems,

this approach has not been found acceptable. The alternative approaches
include:
(a) Pilot installation:
A system may be installed for use only by a select representative user group
that tests the system by actually using it. Other users continue to use old
system. When the problems in the system are taken care of, other users also
start using the system. This approach also is not very popular for accounting
information systems because the entire accounting database must be updated
before it can be used by users.
The user’s information requirements cross the boundaries of department and
divisions in the organisation chart. However, this approach may be used for
complete accounting entities such as branch, regional office, etc. Thus, an
accounting information system may be used by selected branches. Once they
are found to be error free, they may be used by other branches as well.
(b) Phase-in installation:
Under this approach, the installation takes place in stages. These stages are
independent components of the information system. So, the revenue life cycle
of an accounting information system may be first installed and other life cycles
may follow one after the other. This approach helps in focusing on a selected
part of the system. It helps in improving the acceptability of the system among
users because it enables the user to cope up with change easily.
(c) Parallel installation:
The parallel installation means running both the old and the new system
simultaneously for a certain period until the utility of the new system is proved.

This method is most popular for accounting information system because this
is the safest of all other methods. The only difficulty, here, is the cost of
parallel run and the tendency to extend the period of parallel run by those who
resist change.
Post Implementation Review:
Each system must be reviewed after implementation is complete. Such a
review not only helps in identifying the weaknesses of the system but also
prepares an agenda for modification for future. It is, in fact, a learning process.
System audit can also be conducted to examine how successful the system
is, in terms of cost, delivery schedule, completeness and quality.