GLOSSARY OF ACRONYMS AND TERMS
Page 1
AO
Assessing Officer
AIR
Annual Information Return
AIS
Assessee Information System; a module of the ITD Applications consisting of the database of Permanent Account
Numbers (PAN) allocated to assessees
AR
Audit Report
Arrear DCR
Arrear Demand and Collection Register
AST
Blue Book
Assessment Information System, a module of the ITD Applications
A Register maintained by the Assessing Officer for all the
assessees in his jurisdiction with details of name, address,
returns filed and returned income for three years
C&AG
Comptroller and Auditor General Of India
CASS
Computer Aided Selection for Scrutiny
CBDT
Central Board of Direct Taxes
CCIT
Chief Commissioner of Income Tax
CCP
CD
Comprehensive Computerisation Programme of the Income tax Department
Compact Disc
CIT (CO)
Commissioner of Income Tax (Computer Operations)
CoBiT
Control Objectives in Information Technology
Current DCR
Current Demand and Collection Register
DBA
Data Base Administrator
DIT (Systems)
Director of Income Tax (Systems), the co-ordinating officer for systems of the Income Tax Department in/
Directorate of Income tax (Systems)
DP
Data Processing
E-TDS
Electronic-Tax Deducted at Source, a modified version of
the TDS module
GLOSSARY OF ACRONYMS AND TERMS
Page 2
IRLA
IT
Individual Running Ledger Account, a module of ITD
Applications containing snapshots of each assessees
demand/ refund position
Information Systems
IT Act
Income Tax Act
ITD Applications
Income Tax Department Applications i.e. the software
developed for different business processes of the Department contained in 10 different modules.
JCIT
Joint Commissioner of Income Tax
LBS
Local Building Server
LTCG
Long Term Capital Gains
MAT
Minimum Alternate Tax
MIS
Management Information System
MSTU
Ministerial Staff Training Unit
NADT
National Academy of Direct Taxes
NCC
National Computing Centre
NIIT, SSI
Vendors for hardware, software and IT training
NRI
Non Resident Indian
OLTAS
PAN
Online Tax Accounting System, a modified version of
the TAS module
Permanent Account Number
PC
Personal Computer
PIP
Persons in Position
PVCS
A version control software
RCC
Regional Computer Centre (Where backend database
servers reside; 36 such centers exist in the entire department)
Relational Data Base Management System
RDBMS
GLOSSARY OF ACRONYMS AND TERMS
Page 3
RKU
RRR
RTI
Record Keeping Unit
Returns Receipt Register
Regional Training Institute
RTS
Return transcription software
SDD
System Design Document
SLA
Service Level Agreement
SQL
Structured Query Language
SRS
System Requirement Specifications
STCG
Short Term Capital Gains
TAS
Tax Accounting System ,an original module of the ITD
Applications
TCS
Tata Consultancy Services
TDS
Tax Deduction at Source, an original module of the ITD
Applications
TMS
Tax Management System , the software used for processing cases u/s 143 (1) at non networked stations
UAT
User Acceptance Testing
VPN
Virtual Private Network
WAN
Wide Area Network
EXECUTIVE SUMMARY
Page 5
Performance Audit of AST System using the CoBiT Framework
The AST module, a part of ITD Applications, was conceptualized as an on-line, menu
driven software capable of carrying out all assessment and related functions. The objective of
AST is to “assist the assessing officer in doing assessments and related proceedings”. The system
was to also monitor the progress and results of a case at various stages viz. assessments, reassessments, appeal, revision, rectification, penalty, waiver, settlement commission, penalty
proceedings as well as prosecutions and audit objections. In practice, however, the software is
being used for processing Income Tax returns under section 143 (1) and rectification under
section 154. This system was conceptualized in 1994 and development was completed in 1997.
Audit evaluation focused on the activities and performance of the system from 2001-02 to 200405.
AST is currently operational at 60 stations of a total of 514 stations in the country. In terms
of number of assessing officers 2571 out of 4436 are using the system. An in-house application
called TMS is used at the other stations. Twelve out of these 60 stations, where AST is currently
operational, were selected for audit. The selection covers approximately 50% of the total number
of assessing officers using AST.
Methodology
The Audit of the AST system was conducted using the CoBiT framework of the IT
Governance Institute, which has been adopted by the Comptroller and Auditor General of India
as the framework for conducting Information Technology Audits. The Management was
familiarized with the methodology used through an entry conference.
SQL Query:
The errors in the output thrown up in the sample selected, which were systemic in nature,
were sought to be further validated by running queries on the entire data at the concerned RCCs.
SQL queries were accordingly designed to substantiate systemic issues.
Major Audit Conclusions
Inadequate technical feasibility study of AST system has limited the usefulness of the
system and also delayed its implementation as AST is dependent on network connectivity and
stabilization of PAN. The dependence of AST on network connectivity has affected its
implementation as well as use as the system is not fully available to users on a 24/7 basis. All
stations are yet to be brought on the network although eight years have passed since its
commencement in 1997.
EXECUTIVE SUMMARY
Page 6
In the absence of measurable parameters for benefits from the system and details of the cost
of the project the economic feasibility of AST could not be assessed.
The envisaged benefits of AST system in terms of increased efficiency have apparently not
accrued as the country wide pendency has increased and the number of cases processed on the
system had actually declined at two of the selected stations due to both problems of
communication links and links with other modules
AST application has been designed and developed without proper synchronization with the
enterprise data model, which has a centralized data base of PAN (AIS) functioning as the index
key between decentralized ITD applications like OLTAS, TDS and AST. This has led to
problems in their implementation as inputs from OLTAS and e-TDS are not reaching AST.
The heavy unreconciled balances in the OLTAS system indicated that the bank validated
input regarding the payment of tax, is not available at the time of processing returns. The
assessing officer cannot verify through the AST system whether the amount claimed to be paid
by the assessee has actually been paid. A similar situation exists for tax deduction at source. Prior
period data in respect of arrear demand is also unreliable. This entails a risk of loss of critical
information relating to revenue due to the government. Inputs from OLTAS and e-TDS are not
reaching AST through IRLA due to problems in the working of this index key of PAN, affecting
the processing integrity of the system.
Audit found that although the manual Blue Book and other Registers had been replicated in
the AST Module they were not reengineered to take advantage of the information available in the
systems environment. The functionalities of these registers were also not in general use leading to
controls which had existed in the manual environment being discontinued in the systems
environment.
Input form design was not adequate to ensure integrity and completeness of data. The input
form does not capture all the data which is required for processing of a return under
section 143 (1).
There is no system in the AST software to ensure that all the returns received are being
included in the bundles and processed. Field audit reports indicate input controls are inadequate
and issues relating to authorization are not adequately addressed.
The control over data entry process was inadequate to detect errors indicating that the
necessary verifications of input data were not being done. There was no check box for validation
of the mandatory enclosures with a return of income .
There may be data processing errors in the system as indicated by the SQL query run on the
EXECUTIVE SUMMARY
Page 7
data. Data processing errors are also occurring due to the failure of linkages between modules
and incorrect interfaces between modules. Data Processing Integrity was not ensured in the
system as illustrated by errors thrown up by the control totals calculated by Audit. The results
included cases which would need verification and manual rectification, if necessary. The process
of verifying the data processing by running control totals was not in place. Mistakes in the
processed returns were being rectified subsequently, on being pointed out either by the assessee
or noticed by the department at the time of scrutiny assessment. The system does not evaluate the
integrity of the output data by any other check.
A review of the changes carried out in AST revealed that majority of the changes were in
the nature of rectifying design deficiencies. The fact that the system has required so many
changes is indicative of the fact that there were weaknesses in communicating the User
Requirements to the developer; inadequate scrutiny before acceptance of design; and incomplete
User Acceptance Testing.
No systematic/inbuilt monitoring in respect of time taken to execute changes by RCCs is
available. This could lead to errors remaining un-rectified in the system with risk of loss of
revenue. There is no method of impact assessment for the changes carried out in the system.
In the absence of a system of categorization and prioritization of problems, there was a risk
that problems of a critical nature, which may even have an impact on the core objectives of the
department, may remain unresolved, or may be resolved symptomatically without addressing the
cause.
Although user manuals were prepared, these were not available to all the users. The user
awareness of the system features was also limited. This resulted in the suboptimal utilization of
the features of the software. The process of updating the manuals, as changes take place in
computer systems due to changes in the business rules was not in place.
The absence of an operating manual points to incomplete inputs given to operating
personnel and a consequent lack of knowledge of procedures.
The process of “Training Needs Identification” was weak. The users were generally not
satisfied with the training and wanted more exposure to the features of the AST System. As a
result, in most of the instances the full features of the AST software were not being used.
Multiplicity of agencies in training organization led to a blurring of efforts and lack of focus.
There was no coherent policy regarding identification of the areas where third party service
providers should interface with the organization. There was no uniformity or clarity on the issue
of third party contracts. The relationship with the third party service provider was not adequately
safeguarded, with reference to security and confidentiality issues, by appropriate provisions in
EXECUTIVE SUMMARY
Page 8
the contract and supporting processes in a standardized manner.
Major Recommendations
Department should institute a process of conducting specific and detailed technological
feasibility studies of projects before taking them up. The existing information architecture with
reference to the communication links and AIS as an index key requirement of the ITD
Applications needs to be reviewed.
Guidelines need to be laid down for assessing economic feasibility of IT projects. Cost
benefit analysis of the AST application development and implementation needs to be carried out.
Cost data for each module of the ITD Applications including AST should be separately
maintained.
A valid enterprise data model for ITD applications and feasible information architecture to
synergize the IT efforts needs to be defined. The linkages should be improved or be made less
critical to the functioning of the system. A national database of information in ITD applications is
desirable to enable better and efficient MIS reporting and reconciliation of data from different
applications. A time bound action plan to link the arrear demand data to AST system is required
to ensure that no revenue due to government is lost sight of.
Since availability of the application to the users, is and remains a crucial factor, it is
recommended that the Department may consider solutions for connectivity including virtual
private networks with the appropriate technology.
A control register of the basic source data which has all necessary pieces of information
should be designed within the AST System with inputs as necessary from all the information
available in all the modules of ITD Applications. This could be a reengineered format of the
Blue Book.
Department may review the source document formats and ensure that they provide for all
the information that is necessary for processing of a return. The acceptance of returns and giving
of acknowledgement numbers should be made a part of the AST module. Data from the Annual
Information Returns should be linked and entered. Crucial information from the Profit & Loss
Account and Balance Sheet could also be captured to increase the efficiency of picking up cases
for scrutiny through CASS.
Department may institute procedures to ensure that all the returns are entered into the
system, in the proper order and all the returns entered are processed in the proper order, by
devising reports such as gap-analysis at various stages.
EXECUTIVE SUMMARY
Page 9
Guidelines for authorization of data before it is entered in the system, for cases when it is
done by outside parties etc. need to be laid down. Assessing officers should be issued strict
guidelines for verifying the entries made and supervisory authorities should ensure adherence.
A process to check correctness of data entry needs to be instituted. Checks like Control
totals of source data and data as input should be devised. A procedure may be considered for
detection of data entry error and resubmission under proper authorisation. Department should
devise methods for ensuring DP Integrity through an adequate use of control totals run as checks.
The department may consider automatic generation of mismatch report and its reconciliation
being made a prerequisite for processing.
A method of minimising DP errors and setting benchmarks for acceptable levels of errors
must be done. The software may be reviewed with respect to such benchmarks. Procedures for
controlling errors and establishing accuracy of outputs have to be put in place and enforced.
The evaluation of data processing, as done by Audit through SQL queries, needs to be done
at regular intervals by the department itself. The PAN database in the AIS module needs to be
made error free expeditiously since none of the modules including AST can function if the PAN
database is faulty.
User Acceptance Testing should be reviewed. The contracts for changes in the software
should be given after following the due procedure.
An impact assessment feature should be built into the software and used after the
incorporation of changes. A monitoring system for recording and tracking changes should be
built into the software.
The user manuals of the system need to be made available to all the users of the system
through a process of dissemination and monitoring. All the features of the system may be taught
to the users so that all the functionalities of AST are put to use. User manuals of AST should be
updated to reflect all the changes carried out in the software.
A separate Operational Manual may be prepared and issued to the personnel at the RCC so
that they are helped in the proper upkeep and maintenance of the database.
The department should carry out training needs analysis for various categories of users of
the system. Training modules may accordingly be prepared including refresher trainings; when
buying off the shelf trainings, the linkage between the training and actual job requirement should
be clearly established.
A policy document on nature and kind of services that can be outsourced to third parties
should be prepared. Guidelines regarding hiring of third party services and a model contract
EXECUTIVE SUMMARY
Page 10
should be worked out incorporating all the concerns that need to be considered while outsourcing
activities. Security and confidentiality issues should be identified, explicitly stated and agreed to.
An exit conference was held with the CBDT on 12th January 2006 where the major
recommendations were discussed. Department stated that they would look into the issues raised
by audit. They also stated that some of the issues raised by audit were expected to be addressed in
Phase III of the computerization programme as also during the Business Process Reengineering
programme expected to commence shortly which could include re writing of the software.
AUDIT APPROACH
Page 11
1. Introduction
AST or Assessment Information System is one of the important modules in the Income Tax
Department (ITD) Applications. The Government approved the Comprehensive Computerization
Programme with ITD Applications for all the important functions of the Income tax Department
in 1993. This included the AST module and is currently in its third phase.
The AST module was conceptualized as an online, menu driven software capable of
carrying out all assessment and related functions. This system was conceptualized in 1994 and
development was completed in 1997. The objective of AST is to “assist the assessing officer in
doing assessments and related proceedings”1. The system was to also monitor progress and
results of a case at various stages viz. assessments, re-assessments, appeal, revision, rectification,
penalty, waiver, settlement commission, penalty proceedings as well as prosecutions and audit
objections. In practice however the software is being used for only processing income tax returns
under section 143 (1) and rectification u/s 154.
There are some other important modules of the ITD Applications, which are critical for the
working of the AST module. They are
•
The TAS module now renamed OLTAS;
•
The TDS module now renamed as e-TDS; and
•
The AIS (PAN Database) module
•
The IRLA module
Tax payments by the subscribers to government account, by way of Advance Tax, Self
Assessment tax etc., through the authorized banks, are credited and accounted for by the banks in
the OLTAS system.
Tax deducted or collected at source by entities making payments to assessees, where
required to be done, is accounted for in the e-TDS System.
Using the unique assessee identification number, Permanent Account Number (PAN)
which is available in the AIS module of the ITD Applications, these receipts are to be routed
through IRLA and then sent to the AST module to be credited to the correct assessee. The AST
1
AST User Manual Section 1.1
AUDIT APPROACH
Page 12
module calculates the tax due, adjusts the credits as afforded from these two systems and arrives
at the net tax or refund due which is then uploaded back to IRLA, providing a snapshot of the tax
payer entity’s account with the department. The net tax effect appearing in the IRLA with the
amount due from or to the assessee is expected to be available online to the assessee.
The following diagram shows these linkages.
Figure 1 : AST in context of other ITD Applications
The information regarding Advance Tax, Self Assessment Tax, surcharge and TDS
is uploaded to IRLA through OLTAS and e-TDS and demands/refunds from AST to IRLA
using the PAN for identification of assessees.
AUDIT APPROACH
Page 13
2. Audit Scope and Sampling
AST has been implemented at different stations at different points of time. Audit evaluation
of the performance of the system was made for the years 2001-02 to 2004-05 taking into account
the actual date of implementation at the selected stations.
AST is currently operational at 60 stations of a total of 514 stations in the country. In terms
of number of assessing officers 2571 out of 4436 are using the system. An in-house application
called TMS is used at the other stations.
Twelve out of these 60 stations were selected for audit, keeping in mind the coverage in
terms of revenue and number of assessees and the need to arrive at a judicious mixture of the
large, medium and small stations so as to present a representative picture of the country as a
whole. The selection covers approximately 50% of the total number of assessing officers using
AST. The sample was chosen for the 12 selected stations listed in the table as detailed below:
Table 1 : Audit Sample
Serial No./Station
Sample size for Assessing Officers
Units
Sample size for Returns
1.Mumbai
2%
2%
2.Delhi
2%
2%
3.Kolkata
2%
2%
4.Chennai
2%
2%
5.Bangalore
2%
2%
6.Hyderabad
2%
2%
7.Chandigarh
5%
5%
8.Simla
5%
5%
9.Rajkot
5%
5%
10.Lucknow
5%
5%
11.Jaipur
5%
5%
12.Ranchi
5%
5%
AUDIT APPROACH
Page 14
3. Audit Objectives and Methodology
The Audit of AST system was conducted using the CoBiT framework of the IT
Governance Institute, which has been adopted by the Comptroller and Auditor General of India
as the framework for conducting information technology audits. The framework provides a set of
internationally accepted benchmarks against which the information technology activities of an
organization can be evaluated.
The four high level domains of the CoBiT framework consist of macro level statements of
desired state of processes. Each of the domains is further broken down into high-level control
objectives and detailed control objectives.
Two domains and eight high-level control objectives were selected in concordance with the
audit objectives. The audit guidelines of the CoBiT framework were suitably adapted to the
functioning of the AST system.
The audit objectives were mapped to the CoBiT framework and the following high level
control objectives were selected for evaluation.
Table 2 : Selected CoBiT Domains and High Level Control Objectives
Domain
High Level CoBiT Control Objectives
Acquisition and Implementation
Identify Automated Solution
Acquire and Maintain Application Software
Develop and Maintain Procedures
Manage Changes
Delivery and Support
Manage Third Party Services
Educate and Train Users
Manage Problems and Incidents
Manage Data
A uniform approach to audit all over the country was adopted by issuing:
•
•
The relevant CoBiT guidelines;
Questionnaires for the three different levels of the National Computer Centre, the
Regional Computer Centers and the Assessing Officers; and
AUDIT APPROACH
Page 15
•
A detailed Audit Work Programme.
A random sample of all assessing officers units at the concerned stations was selected as
per the sampling table given above. Separate questionnaires were issued to the National
Computer Centre and the Regional Computer Centres, if any, at the selected stations, and the
selected assessing officer units. For each Assessing Officer Unit a random selection of 2% or 5%
of the Returns filed were taken as per the sampling table given above. The detailed audit checks
in the Audit Work Programme were applied as follows:
Table 3: Audit Checks at different points
Audit check
RCC
Randomly selected AO Randomly selected ReUnit
turns
1.Receipt and preliminary Not Applicable
checking of returns
Applicable
Not Applicable
2.Making of Bundles
Not Applicable
Applicable
Not Applicable
3.Data entry of RRR
Not Applicable
Applicable
Not Applicable
4.Data entry of Acknowl- Not Applicable
edgement Sheet
Not Applicable
Applicable
5.Generation of Notices
Not Applicable
Applicable
Applicable
6.Allocation of Bundles
Not Applicable
Applicable
Not Applicable
7.Systemic errors
Not Applicable
Not Applicable
Applicable
8.Computation of output
Not Applicable
Not Applicable
Applicable
9.Despatch of output
Not Applicable
Not Applicable
Applicable
10.Efficiency
Applicable
Applicable
Not Applicable
11.Security
Applicable
Applicable
Applicable
12.Availability
Applicable
Applicable
Not Applicable
13.Scrutiny Assessment
Applicable
Applicable
Not Applicable
14.Outsourcing
Applicable
Applicable
Applicable
15.Miscellaneous
Applicable
Applicable
Applicable
The Management was familiarised with the methodology used through an entry conference.
At the entry conference, management stated that AST is not a separate project but a part of the
customised modules of ITD Applications which is being implemented in a phased manner. It is a
legacy system which should be examined with reference to the technology and management
AUDIT APPROACH
Page 16
practices in existence at the relevant time i.e. in the mid 1990s and the CoBiT framework was not
in existence when ITD applications were conceptualized and designed.
The concerns of the management are appreciated and have been taken into account during
the audit. Further, the criteria set out in CoBit embody a set of best practices which are
universally valid for the analysis of information systems.
SQL Query:
As per the methodology it was envisaged that the indicative errors in the system thrown up
in the sample selected and audited would further be validated by running queries based on these
errors at the concerned RCC for the entire set of data at the selected stations.
The DIT Systems was sent a detailed list of these queries after consolidation of data
received from all the 12 stations. Part of the query relating to interest calculations could not be
fully run at the stations of Mumbai and Bangalore. The data available through the queries has
been suitably incorporated in this report.
4. Audit Findings, Conclusions and Recommendations
Audit findings, conclusions and recommendations have been arranged in the order of highlevel control objectives grouped in the two selected Domains of CoBiT. The high level control
objectives further consist of detailed control objectives. The findings, conclusions and
recommendations have been separately set out for each of these detailed control objectives.
The audit criteria are specified as the “description” of the high level control objectives.
Audit Observations are given under the heading “control notes” and the audit conclusions are
given under the heading “assessment”. After taking into account the management response,
suitable recommendations have been framed.
IDENTIFY AUTOMATED SOLUTION
Page 17
Technological Feasibility Study
Description The organization’s system development life cycle methodology should provide for an examination of the technological feasibility of each alternative for
satisfying the business requirements established for the development of a
proposed new or modified information system project.
C o n t r o l A Working Group on computerisation was set up and its report was taken as
the basis of the tendering document and identification of the software develNotes
oper for AST, which was conceptualized and implemented as a regionally
centralized application. It was envisaged that there would be a National
Computer Centre at the apex linked through leased lines to the 36 Regional
Computer Centres which would be further linked through leased lines to the
Local Building Servers to which the assessing officers would be connected.
The AIS (PAN Database) was to serve as the index key for all the ITD Applications including AST.
Thus, for smooth implementation of this system, the existence of reliable
communication links from RCC to the users was critical as was the stabilisation of the AIS module. However the technological feasibility of having such
information architecture was not adequately carried out. The communication
links between the NCC, RCC and LBSs, are still not available in some cases
and are unreliable in others. Further, the AIS module which is the index key
unresolved issue relating to identification and migration of PAN. Eight years
after the introduction of AST only 2571 out of 4436 assessing officers all
over India i.e. 57.96% are using this application.
M a n a g e - The report of the Working group formed the basis of computerization and at
ment
Re- the time of conceptualization there was an inherent design constraint due to
which a single central database could not be made. The technical feasibility
sponse
of the hardware and communications solutions was evaluated by the Technical Evaluation Group as well as the report of the Technical Sub Committee
approved by the Working Group. The rest of the networking is being done in
Phase III and at present a standalone software called TMS is being used at
non-networked stations. AST is dependent on the stabilization of the PAN
database, therefore it could be started only in 2000 and 8 years have not
passed since its introduction.
I
IDENTIFY AUTOMATED SOLUTION
Page 18
A s s e s s - Audit found that the Working Group report referred to by the management
was based on various inputs which did not include feasibility reports. A feament
sibility study should have been carried out after the working group submitted its report in order to analyze the technical feasibility of the recommendations. The other two committees mentioned were mandated only with
evaluation of limited hardware requirements and not the technological feasibility of the proposed solutions. The fact that AST is dependent on network
connectivity and stabilization of PAN are reflections of the feasibility of the
linked model not being studied.
Absence of adequate communication links has been one of the factors due
to which the implementation as well as use of AST has remained incomplete2. Further, the fact that assessees are entitled to file their returns at any
place in India depending on their residential status makes the issue of correct jurisdiction an important one. This is the genesis of the problems of
identification and migration of PANs. This was not foreseen and built into
the application design or deliverability. Inadequate technical feasibility
study of AST system has limited the usefulness of the system and also delayed its implementation.
Recommen- 1.
dations
Department should institute a process of conducting specific and detailed technological feasibility studies of the projects before taking
them up. Such study should invariably form a part of the proposals.
2.
Department may review the existing information architecture with reference to the communication links and AIS as an index key requirement of the ITD Applications to address the shortcomings.
2In
some of the cities on the Wide Area Network (WAN) for the ITD Applications, new office
buildings were hired/constructed after the completion of Phase II of networking in 2002. These
buildings should also have been brought on the WAN but this was not done. Some buildings at the
60-networked stations do not have network connectivity. This is being provided in Phase III of
computerization
The AST Software was developed and implemented in 1997 in Delhi. Out of 354 assessing
officers in 2004-05, 89 assessing officers are still not using AST.
IDENTIFY AUTOMATED SOLUTION
Page 19
Economic Feasibility Study
Description
The organization’s system development life cycle methodology should provide,
in each proposed information systems development, implementation and
modification project, for an analysis of the costs and benefits associated with
each alternative being considered for satisfying the established business
requirements.
C o n t r o l AST is a part of ITD applications, which have been implemented in three
phases since 1993. An examination of the cost benefit analysis of the
Notes
proposal3 for Phase III revealed that the proposed outlay of Rs.251.56 crores
was given with a broad break up of activities, software products etc. The associated benefits were not quantified and the economic justification was based on
broad assumptions of rise in tax base and increase in service level to the
assessee as also tax compliance. No measurable parameters for increase in service levels or tax compliance were put forth in the proposal.
It was observed that as against the expected figure of the tax base of 5 crore
asessees by 31-3-2005 the actual tax base at the end of financial year 2005 was
only 2.71 crores (down from 2.92 crores as on 31.03.2004). Furthermore, it was
noticed that the department did not have expenditure figures of the AST project
separately and was therefore not in a position to provide details of the cost of the
project.
Management The AST module is being implemented in phases and the total cost of
developing ITD applications of which AST is one module was only Rs.72 lakhs.
Response
There has been an increase in productivity and service levels as the time limit
for processing has decreased and, as per the Kelkar committee report, all the
processing of the backlog of returns was completed in four months without any
extra man power. The number of cases processed on AST and the average
disposal per assessing officer has increased, while cost of collection has
decreased. Productivity per employee has increased and benchmark activities as
per the cabinet note as also electronic delivery of tax payer services are on track.
Assessment
In the absence of measurable parameters for benefits from the system and details
of the cost of the project, the economic feasibility of AST could not be assessed.
Further, the envisaged benefits of AST system in terms of increased efficiency
have apparently not accrued as the country wide pendency has increased4 and
the number of cases processed on the system were seen to have declined at two
of the selected stations due to both problems of communication links and links
with other modules5.
3The
sanctions for Phase I and Phase II of the computerization programme have been covered in the AR
12 of 2000
IDENTIFY AUTOMATED SOLUTION
Page 20
Assessment
Data entry work for processing of returns was through outsourced man
power6 and cost of collection in absolute terms as well as per assessee has
increased.7
Audit found that the method used for arriving at the figure of Rs.72 lakhs
took into account only the amount paid to the software developer for the
designing. The other costs relating to hardware, system software, application
software, implementation, operations, infrastructure and maintenance thereof
have not been included. The department has also not allocated costs to
individual modules of ITD applications to arrive at a cost benefit analysis for
each module.
R e c o m m e n - 3.
dation
The Income Tax department should carry out a cost benefit analysis of
the AST application development and implementation.
4.
Guidelines be laid down for assessing economic feasibility of such IT
projects. The guidelines should include measurable parameters of
benefits against which a subsequent evaluation of the project should be
possible.
5.
The department maintain the cost data separately for each module of
the ITD Applications including AST.
4
As per figures provided by DIT Systems the all-India pendency went up from 38.33 lakh (02-03) to
56.05 lakh (03-04) and 70.68 lakh (04-05); 17%, 25% and 30% respectively of the total returns filed
5
Delhi:
The pendency of summary assessment has increased from 4.71% (2002-03) to 42.48 % (2004-05).
Despite increase in number of assessing officers using AST from 248 (2003-04) to 265 (2004-05), the
average number of summary assessments completed using AST by assessing officers has declined
from 3120.29 to 3081.90. The average number of summary assessments completed (both manually &
using AST) has declined from 8479.35 (2002-03) to 3346.15 (2004-05) even though the number of
assessing officers has increased from 312 to 354. The decline is by 60% (approx.).
The reasons for pendency were mainly problems associated with PAN (See Appendix A for PAN
Problems in processing) and problems with the communication links established.
Himachal Pradesh:
During the year 2001-02 and 2002-03 when the returns were processed manually, there was no pendency at the close of the year but with the introduction of AST system w.e.f.13.08.2003 it was noticed
that 4411 returns out of 12735 and 3853 out of 13457 returns were pending for processing at the close
of the year 2003-04 and 2004-05 respectively. Pendency of returns at the close of the year was due to
problems with the communication links established as well as issues relating to PAN.
6
Please see section on Manage Third Party Services
7
Please see footnote 4 and table 2.24 of Report no. 8 of 2006 (Direct Taxes) of the C&AG
IDENTIFY AUTOMATED SOLUTION
Page 21
Information Architecture
Description
Management should ensure that attention is paid to the enterprise data model
while solutions are being identified and analyzed for feasibility.
Control Notes AST is a regionally centralized application at 36 locations. The system,
therefore, consists of 36 databases in as many locations running a single
common application. The users are connected to their respective RCCs
through leased lines.
The enterprise data model existing at the time of the current phase of IT
initiative, of which AST is a major part, centered on the PAN database. The
PAN database, whose objective is to uniquely identify every assessee in the
country, was a centralized database. The centralized nature is a business
requirement to achieve the integrity constraint of uniqueness. However, the
system envisaged that credits would be available from OLTAS for advance
tax and self-assessment tax and e-TDS for the tax deducted at source. These
were to be credited against the demand worked out in the AST module using
PAN as the linking key, and the refund/demand as worked out was to be
updated in the IRLA system.
Due to problems in the implementation of OLTAS the credits for self assessment and advance tax are not correctly available from the system.8 Credits
from the TDS module named e-TDS can also not be linked to the AST
module data as e-TDS is in the process of implementation.
The issue is further compounded by cases of non-allocation and nonmigration of PAN.
8
AST Instruction No 16 details the procedure to correct the wrong data posted to IRLA from the erstwhile TAS System.
AST Instruction No. 34 details the list of the problems in the modified version called OLTAS which
includes wrong information of challans posted from OLTAS to IRLA, non availability of information
on paid challans in posted records in OLTAS, minor head mismatch in AST and OLTAS, challan
lying in suspense in OLTAS, Challan Identification Number of challan entered in AST not available
in OLTAS, PAN mismatch in AST and OLTAS and existence of non posted records from AST.
AST Instruction No 18 details the method of correction of wrong TDS entries made through AST and
posted to IRLA.
IDENTIFY AUTOMATED SOLUTION
Page 22
Control Notes The “Individual Running Ledger Account” (IRLA) maintains the details of
all the transactions of assessees with the department. However, IRLA does
not have the correct details of arrear demand.
Manual uploading of the prior period data has also not been effective since
assesses with arrear demands outstanding do not all have PANs and therefore cannot be linked with the IRLA data.
The NCC has a link with all the 36 RCCs. However, the department has
not created any national database of the information available in the 36
databases. In the absence of such a database the ability of the department
to use AST at the national level for important MIS needs is limited.9
Management The conceptual design of ITD Applications is an interlinked one with data
from the AIS, TAS and TDS module. The modified OLTAS and e-TDS
Response
are in the process of stabilization; though the linkages exist and are
functional, quoting of PAN is not accurate therefore automated credits are
not being given and credits are routed through a verification routine by the
assessing officer. The entire data model is of regionally centralized
databases at RCCs. Only five out of 14 parameters of the PAN Database
are stored at NCC which does not change its architecture into a centralized
one. OLTAS data is available to the assessing officers who have been
given a functionality to locate challans to avoid wrong posting of data to
IRLA. OLTAS has deductor wise data for TDS which cannot be directly
posted into AST therefore credit is given on the basis of TDS certificates
enclosed with the return. MIS can be generated regionally since the architecture is regionally centralized. A single National Database is being set up
in Phase III of the Comprehensive Computerization Programme by consolidation of 36 regional databases.
9
Generating MIS information necessitates changing the forms of AST, making it as a patch and then
getting RCCs to run the query and fax the reports to NCC. (AST Instruction No 25 dated 3.12.2003.)
IDENTIFY AUTOMATED SOLUTION
Page 23
Assessment
AST application has been developed without ensuring proper synchronization with
the enterprise data model which has a centralized data base of PAN on one side
and OLTAS and TDS on the other which at the time of data capture cannot
validate the data against PAN. The conceptual plan document of AIS data base
described the system as centralized for processing and decentralized in terms of
data input and output.
This disparate data model has led to serious issues. The heavy un-reconciled
balances10 in the OLTAS system mean that the bank validated input regarding the
actual payment of the tax challan into the government accounts cannot be given to
the assessing officer who is using the AST system for processing. The assessing
officer therefore cannot verify through the AST system whether the tax claimed to
be paid by the assessee has actually been paid. Tax deduction at source is also
unverifiable through the AST system.
Online information regarding the assessee’s tax liability or refund due which was
expected to be provided through the output from the AST system to the IRLA is
not operational. The digitization of arrear demand also suffers from operational
problems due to which prior period data in respect of arrear demand is unreliable.
This entails a risk of loss of critical information relating to revenue due to the
government. Generation of all India level MIS cannot be done due to the
inadequate considerations to information architecture.11
Use of AIS as the index key to ITD application systems led to problems in
implementation as already pointed out in AR 12 of 2000 by the C&AG. Since the
Income tax Department is highly decentralised in terms of operation, the AIS
system design which was centralised was found to be weak in implementation,
thereby affecting the functioning of AST12.
R e c o m m e n - 6.
dation
It is recommended that the income tax department define an enterprise data
model for its application resulting in adequate information architecture so
that the IT efforts of the department are synergized.
7.
Department may consider developing a national database of information in
ITD applications to enable better and efficient MIS reporting and
reconciliation of data from different applications.
8.
Department may prepare a time bound action plan to link the arrear demand
data to AST system to ensure that no revenue due to government is lost sight
of.
10
Rs.1526 crores are lying in suspense in OLTAS in Delhi
11
Please see the section on the SQL Query and Appendix C and footnote
12
Please Para 3.2.10 (b) of AR 12 of 2000
ACQUIRE AND MAINTAIN APPLICATION SOFTWARE
Page 25
Source Data Collection Design
Description
The organization’s system development life cycle methodology should
require that adequate mechanisms for the collection and entry of data be
specified for each information system development or modification
project.
Control Notes
AST is used for assessment of income tax returns of assessees. The
process starts with entering the returns received from assessees into the
system. Audit found13 that the returns received were being entered in
the system and a return receipt register generated which was not linked
to the AST system and was not correlated with the “Blue Book” by
updating it. In these nine states Blue Books were not being maintained
through the system. The Blue Book which is the main control register of
the Income Tax Department for its assessment functions contains details
of returns filed, assessments done and demand raised for the last three
years. However, this is not being generated/updated in the computerized
environment. As a result, lists of non filers, stop filers, jurisdiction
change list and list of cases where notices u/s 142(1) are to be sent are
also not being generated in these States.
Management Re- AST has the functionality of generating the Blue Book and the form is
the same as existed in the manual environment. AST generates all the
sponse
registers which were in use in the manual environment. It also allows
generation of lists such as those of non filers, transfer cases, and cases
selected for scrutiny. Monthly Telegraphic Report can also be
generated. These can be generated in the AST Module and are linked to
PAN.
Assessment
Audit found that although the manual Blue Book and other Registers
had been replicated in the AST Module they were not re engineered to
take advantage of the information available in the systems environment.
The functionalities of the registers which were available were also not
in general use leading to controls which had existed in the manual
environment being discontinued in the systems environment.
This was found in the states of Delhi, Maharashtra (Mumbai), West Bengal, Tamil Nadu, Karnataka, Gujarat, Punjab, Himachal Pradesh and Uttar Pradesh.
13
This was seen in the states of Delhi, Maharashtra (Mumbai), West Bengal, Tamil Nadu, Karrnataka,
Gujarat, Punjab, Himachal Pradesh and Uttar Pradesh.
ACQUIRE AND MAINTAIN APPLICATION SOFTWARE
Page 26
R e c o m m e n - 9.
dation
A control register of the basic source data which has all necessary pieces
of information should be designed within the AST System with inputs as
necessary from the information available in other modules of ITD
Applications, which gives details of filing of returns, assessments,
demand creation and payment for the past three years. This could be a re
engineered format of the Blue Book so that data relating to demand and
collection is also available in this Control Register. Data from the other
modules of OLTAS and e-TDS could also be linked to this.
10.
It should be ensured that the functionalities of lists and registers available
currently are actually being used.
Availability as a Key Design Factor
Description
The organization’s system development life cycle methodology should
provide that availability is considered in the design process for new or
modified information systems at the earliest possible stage. Availability
should be analyzed and, if necessary, increased through maintainability and
reliability improvements.
Control Notes
The AST system’s back end (data base server) is located in 36 RCCs. The
database server used was Oracle, with front end in Developer, in two-tier
architecture.14 The use of two-tier architecture meant that only way of making
the system available to the users in remote locations was by having dedicated
communication links.
DIT Systems stated that implementation of AST required certain prerequisites
which were stabilisation of network connectivity and the AIS Module, and
training of personnel.15
A large proportion of users have not been brought onto the system.16
Problems of connectivity have meant that a large number of users on the
WAN could not use the system fully.
ACQUIRE AND MAINTAIN APPLICATION SOFTWARE
Page 27
M a n a g e m e n t The system was conceptualised on the technology available in 1993-94 as per
the recommendation of the Working group. Bandwidth has been augmented for
Response
users in the 60 stations of Phase I and Phase II and the rest of the cities will be
connected in Phase III. Simultaneous country wide implementation was not
possible.
Assessment
The dependence of AST on network connectivity has affected its
implementation as well as use as the system is not fully available to users on a
24/7 basis. All stations are yet to be brought on the network although eight
years have passed since its commencement in 1997.
Recommenda- 11. Since availability is and remains a crucial factor it is recommended that
the Department may consider solutions for this including virtual private
tion
networks with the appropriate technology.
14
The operating system and RDBMS software have multi user licenses. The operating system originally
installed was AIX version 4.1, which was upgraded to version 11i. The RDBMS originally provided was
upgraded to 7.3.4. The current HP server provided has Oracle 8i. The system is being migrated to 9i and
quasi 3 tier architecture as part of Phase III of comprehensive computerisation plan.
15
AIS and Training have been separately discussed in “Identify Automated Solutions” and “Educate
and Train Users” respectively.
16
AST was installed for initial Acceptance on 15.11.1996 and approved on 22.7.1997. Only 2571 Assessing officers were using AST at 60 stations against the total number of 4436 Assessing officers till
31.3.2005. Partial implementation was found in Delhi, Andhra Pradesh, Uttar Pradesh, Jharkhand, Gujarat,
Maharashtra, West Bengal, Tamil Nadu.
ACQUIRE AND MAINTAIN APPLICATION SOFTWARE
Page 28
IT Integrity Provisions in Application Program Software
Description
The organization should establish procedures to assure, where applicable, that
application programmers contain provisions which routinely verify the tasks
performed by the software to help assure data integrity, and which provide in
the restoration of the integrity through rollback or other means.
Control Notes The AST software is required to work in conjunction with other ITD applica-
tions. Implementation of PAN database was a pre-requisite for the processing
integrity of AST. Similarly the processing integrity of AST requires that its
interfaces with TDS, OLTAS, and IRLA etc. are properly defined and are
working. However, it was observed in audit that links of AST with a key
system, OLTAS, were not working adequately leading to as much as Rs.
1526.18 crores lying in suspense at only one station namely Delhi.17 TDS
credits are also not being received from the e-TDS module. Correct data
relating to the demand outstanding or refund due is also not uploaded from
AST to IRLA.18
Management The ITD Application is an integrated one with inbuilt linkages between
appropriate modules. In the initial stages of implementation of OLTAS, PAN
Response
was not properly quoted by assessees and so the tax credits could not be
posted to the IRLA of the concerned assessee. These are stabilization issues
and are not connected with the working of the linkages. The reconciliation
between tax collected by banks and the amount transferred to government
account is a separate process being appropriately monitored and there is no
suspense amount in this regard. Suspense is of the amount which has been
received and remains un-posted to IRLA. There is no deficiency in the
AIS-AST interface.
17
18
Pl see section on Information Architecture with special reference to FN 8.
It has been observed at all the 12 selected stations that Assessing officers are using only the functionalities relating to processing and rectification. All the other functionalities of AST i.e. scrutiny,
reassessment, appeal, revision penalty, waiver, settlement commission, prosecution, audit objections
were not used. As a result issues of orders/notices/demands relating to these were not being generated through AST. Therefore, IRLA is not being accurately being updated through AST.
The functioning of other modules of software in ITD i.e. AIS, OLTAS, e-TDS and IRLA, have to be
reviewed for smooth functioning of AST.
ACQUIRE AND MAINTAIN APPLICATION SOFTWARE
Page 29
Assessment
The AIS Module is the pivot on which the system of linkages works. Due to
various inherent and operational problems19 AIS has not been able to
perform efficiently thus affecting the processing integrity of AST. In the
absence of the linkage with OLTAS and e-TDS working properly there was
no assurance that tax paid as per orders passed by the assessing officers was
actually received by the government. This lack of integrity in the system
means that the income tax department cannot validate that tax collected has
been credited to the correct assessee. The snapshot of the assessee’s demand
and collection position to be provided by the IRLA Module is therefore not
accurate.
Audit found that AIS was the main index key for the working of the ITD
Applications.20 As a result of this, AST cannot work the way it was
conceptualized as the necessary inputs from the other modules are not
available. As inputs from OLTAS and e-TDS do not reach AST through
IRLA affecting the processing integrity of the system, various manual
interventions for entering the correct advance tax, self assessment tax, TDS
and surcharge paid by assessees are being done.21 Further, errors in the AIS
data are reflected in the AST module as for example in the case of wrong
addresses of assessees generated in AST due to inaccuracies in AIS.
Recommendation
12. A review of the use of AIS as a link should be carried out so that the
integrity of the AST system can be established and maintained.
19
Please see AR 12 of 2000 of the C& AG ;Para 3.2.10.2 (b)(i) and (ii).
20
Pl see the section on Identify Automated Solutions.
21
Pl see Control Notes of section on Output Review and Error Handling (with special reference to Foot
Notes 24 and 27) and also Appendix A Table 4 for number of manual interventions into the system.
MANAGE DATA
Page 31
Data Preparation Procedures
Description
Management should establish data preparation procedures to be followed by
user departments. In this context, input form design should help to assure that
errors and omissions are minimized. Error handling procedures during data
origination should reasonably ensure that errors and irregularities are detected,
reported and corrected.
Control
Notes
The source documents from which data was entered in the system were found
inadequate, as they were not capturing certain crucial information. Majority of
the users commented that the fields available in the Acknowledgement Sheet
were not sufficient for entering data.
Certain information such as details of challans, capital gains, exempt income,
brought forward loss and set off of brought forward loss, amount of book profit
(for 115JA/115JB), investment u/s 88, income from other sources, income
clubbed under Section 64 was not captured in the input form design. The
system also needs inclusion of parameters to populate the due dates in respect
of Form Nos 1, 2 and 3. There is no provision for entering advance tax more
than Rs 100 crores.
The acceptance of returns and giving of acknowledgement numbers is not a part
of AST.
Management Source documents are statutory, therefore there are inherent limitations outside
the scope of computerization. Automatic population of due dates cannot be proResponse
vided as they often change. Entry of Advance Tax more than Rs. 100 crore can
be done through search and claim from OLTAS/AST has the functionality for
computerized receipt of returns in its RRR sub-module. Due to practical problems it is difficult to enter returns in the RRR sub module. AST has provisions
for trapping data entry errors with alert messages.
Assessment
Input form design was not sufficient to ensure integrity and completeness of
data.
Computerization efforts have to be in synergy with the business requirements
and statutory provisions of the Department; these issues would need to be dealt
with within the purview of the overall computerization effort.
MANAGE DATA
Page 32
R e c o m m e n d a - 13. The department should review the source document formats and ensure that
they provide for all the information that is necessary for processing of a return.
tion
Procedures should be set down to trap errors in the acknowledgement sheets and
that to detect and correct these in a timely manner. The acceptance of returns and
giving of acknowledgement numbers should be made a part of the AST module.
Data from the Annual Information Returns should be linked and entered. Crucial
information from the P&L Account and Balance Sheet could also be captured to
increase the efficiency of picking up cases for scrutiny through CASS.
Source Document Authorization Procedures
Description
Management should ensure that source documents are properly prepared by
authorized personnel who are acting within their authority and that an adequate
segregation of duties is in place regarding the origination and approval of source
documents.
Control Notes
Returns received from the assessee in the receipt section of the range office are
made into bundles according to the convenience of the concerned assessing
officers. Bundles should be prepared by the Range JCIT and allocated to the
different assessing officers which is not being done.
Bundles do not contain all the returns sequentially based on the acknowledgement
numbers. Further, the returns received are made into bundles consisting of “Nil
Demand”, “Refund” and “Demand”. The assessing officer/assessing officer Staff
generates the bundle number sequentially in the AST software.
No check is exercised to ensure that all the returns received are included in the
bundles.
Management
Response
JCITs allocate bundles only in pilot ranges and not in normal ranges. Returns need
to be segregated to process refund returns on priority. The seasonal rush of returns
makes it impractical to issue sequential acknowledgement numbers but physical
control is exercised by assessing officers and JCITs.
MANAGE DATA
Page 33
Assessment
The segregation of duties between origination of source document (tapal
section) and authorization in the assessing officers section was adequate.
The concept of pilot ranges and normal ranges has now been discontinued
according to the new system of record keeping units (RKUs), all records are
centralized with the range JC who is to allocate returns to all the assessing
officers in the jurisdiction.
However, the system allowed for the authorized returns to be entered in the
system in any order which is in contravention of the business rule of
following the order of acknowledgement number.
There is no system in the AST software to ensure that all the returns
received are being included in the bundles and processed.
Audit found that the issue of sequential acknowledgement numbers was
feasible and desirable in order to requisitely control and monitor the processing of returns.
R e c o m m e n - 14. The department should institute procedures to ensure that
dation
(a) All the returns are entered into the system sequentially.
(b) All the returns entered are processed sequentially, by devising reports
such as gap-analysis at various stages.
MANAGE DATA
Page 34
Data Input Authorization Procedures
Description
The organisation should establish appropriate procedures to ensure that only
authorized staff performs data input.
Control Notes The entries made by the staff into the system are to be validated by the
assessing officer but this process is not satisfactory in all the states selected
for audit.
It was found that outsourcing was being done in Tamil Nadu, Karnataka,
Mumbai, Uttar Pradesh and Himachal Pradesh for data entry of returns. The
process was not being controlled and monitored to ensure that data entry
was mandatorily authorized by the assessing officer.
Data already entered by the staff in one State was accessible to the
outsourcing agents who had the user Id and password of the departmental
officers.
Management The roles available in the AST module allow the assessing officer and the
staff to make entries but only the assessing officer can process the
Response
entries .Outsourcing is done according to a scheme which has the necessary
guidelines and operates in a limited manner. Data already entered was not
available to the outsourcing agents as the work was done under the
supervision of the officers of the department. Assessing officers are
involved in verification of data entry.
Assessment
Field audit reports indicate that input controls are inadequate and issues
relating to authorization are not adequately addressed.
As far as data entry by third party service providers is concerned, in the
absence of an adequate contract taking into account various aspects of
security and authorization there are possibilities of security lapses, which
would compromise and vitiate the data in the system.
The assessing officer has the final responsibility for the returns filed and
processed including the accuracy of the inputs and outputs of the system.
Therefore final authorization of the input data should be done by the
assessing officers. However, audit found that this was not strictly followed
in several cases in all selected states.
Tamilnadu
MANAGE DATA
Page 35
The assessing officers should be issued stricter guidelines for
R e c o m m e n - 15.
verifying the entries made and that supervisory authorities check this
dation
validation.
16
The department should lay down guidelines for authorization of data
before it is entered in the system, for cases when it is done by outside parties
etc. Such data should not be entered directly into the system and instead the
policy should provide for an authorization procedure, including due checks
before its entry into the AST system.
17
The user identities and passwords of departmental officers should
not be available to third parties.
Accuracy, Completeness and Authorization Checks
Description
Transaction data entered for processing (people-generated, systemgenerated or interfaced inputs) should be subject to a variety of controls to
check for accuracy, completeness and validity. Procedures should also be
established to assure that input data is validated and edited as close to the
point of origination as possible.
C o n t r o l The computation sheet enclosed along with the return was not verified to
ensure correctness of the data furnished in the Acknowledgement sheet
Notes
Section 139 of the IT Act sets down certain mandatory enclosures to be
appended to the return without which the return is to be treated as defective.
As there is no field in the system regarding the completeness of the
mandatory enclosures, the completeness of returns furnished could not be
ensured through the system. There was no check to confirm that
acknowledgement sheet was correctly filled in.
MANAGE DATA
Page 36
Management Computation sheets are non statutory and non standard and cannot be
used for data entry. Particulars of mandatory enclosures are verified at
Response
the time of filing of returns. Data is entered by staff and can be
processed only by the assessment officer. AST has inbuilt checks to
verify control totals and issue alerts.
Assessment
The controls over data entry process at the input level were not sufficient to detect errors and could lead to incorrect refund/demand. Audit
found that all the necessary verifications of input data some of which
were dependent on the computation sheets were not being done.
There is no check box for validation of the mandatory enclosures with a
return of income does not exist. Alerts exist in the system but are
Department should institute a process to check correctness of
R e c o m m e n - 18
data entry. Checks like control totals of source data and data as input
dation
should be devised and the two should be compared to identify the
errors.
MANAGE DATA
Page 37
Data Input Error Handling
Description
The organisation should establish procedures for the correction and
resubmission of data, which was erroneously input.
Control Notes We found that
•
Data once saved in the system could not be corrected and resubmitted
even if it had not been processed by the assessment officer.
•
Assessment years, date of filing of returns etc. are wrongly entered in
the system.
•
Non-verification of records before entry into the system led to
subsequent manual rectification.
•
Several data entry errors were noticed at all the stations.
•
Input controls were not adequate since entry was not being adequately
verified by the assessment officers.
Management Data entry can be corrected up to the stage of processing. Due dates are centrally entered by NCC. Initial data entry by staff and checking by assessment
Response
officer provide two levels of check with the final responsibility being the
assessment officers. For errors detected after processing, order u/s 154 is the
only legal recourse.
Assessment
The final verification of the data entered in the system by the assessing officer is not being done properly, leading to input errors being perpetuated in
the system. The only way of correction is through a separate order under
section 154.
Department may consider devising a procedure for detection of data
R e c o m m e n - 19.
entry error and resubmission under proper authorization.
dation
MANAGE DATA
Page 38
DP Integrity
Description
The organisation should establish procedures for the processing of data that
ensure separation of duties is maintained and that work performed is
routinely verified. The procedures should ensure adequate update controls
such as run-to-run control totals and master file update controls are in place.
Control Notes Certain control totals were run as an SQL query on the system.22
•
Section wise Chapter VIA deductions should be equal to total
deductions;
•
Returned Income should be equal to Gross Total Income less deductions;
•
Returned Income should be equal to Income taxed at normal rates
plus Income taxed at special rates.; and
•
Total of all heads of income should be equal to the total income.
The results of these runs threw up cases which would need verification and
rectification if necessary.
Ma n a g e m e n t AST has the necessary checks for control totals which are also available to
the assessing officer as alerts. The observations of audit are based on the
Response
results of the SQL query run which had certain limitations thus the mistake
is in the query and not the program. The results of the queries have been
examined in detail and discrepancies reconciled.
Assessment
The process of running control totals is a necessary check on data
processing integrity as it reveals the possibility of the existence of errors in
the system. The basic control total runs done by audit threw up several
cases for verification with the possibilities of error.
As the control totals were run by audit merely as indicators, cases thrown
up through running such control totals or any control totals devised by the
Department need to be rechecked for accuracy as a part of checking the
data processing integrity. This process is not in place as the checks for
control totals which are issued as alerts to the assessing officer are for guidance during processing of inputs. The control totals being considered here
are for verification of outputs at the system level to be run by the database
administrator.
22
See Appendix ‘B’
MANAGE DATA
Page 39
Recommendation 20.
The department should devise methods for ensuring DP integrity
through an adequate use of control totals run as checks.
DP Validation and Editing
Description
The organisation should establish procedures to ensure that data
processing validation, authentication and editing are performed as close to
the point of origination as possible.
Control Notes Mistakes in the processed returns are rectified subsequently on being
pointed out either by the assessee or noticed by the department at the time
of scrutiny assessment of the selected cases. The department has not
evaluated the integrity of the output data by any other checks.
The existence of the tool of the mismatch report to ensure that the data
generated by the system corresponds to the data entered was not generally
known. Differences were seen in data entered and data shown in the output, for example, in the fields of returned income, assessed income tax,
book profit etc.
Management Mismatch reports are automatically generated for enabling assessment
officers to correct data entry errors.
Response
Assessment
Not using the mismatch report was a weakness in the data processing. It
could lead to incorrect data being processed and going undetected. Before
processing of a return mismatch reports generated by this system and the
data entered should be verified against the output generated.
The mechanism of detecting/correcting the errors only after being pointed
out by agencies external to the system was a weakness in the process .
MANAGE DATA
Page 40
Recommen- 21.
dation
The department may consider reconciliation of mismatch reports being
made a prerequisite for processing.
22.
There should be a mechanism for running a check on the data processing.
DP Error Handling
The organisation should establish data processing error handling
procedures that enable erroneous transactions to be identified without
being processed and without undue disruption of the processing of other
valid transactions.
C o n t r o l A test check revealed the following shortcomings23
•
AST does not automatically adjust the refunds of current assessment
Notes
year against the demand of the previous assessment year. Such
adjustments were made manually on the output sheet.
•
Due date of filing of return was found incorrectly entered in the
output sheet.
•
There were mistakes in gross taxable income generated on the output
sheet.
•
The system is not correctly adding minus items.
•
Non allowance of credit of advance tax.
•
Incomplete processing of returns due to cancellation of vouchers of
refund.
•
Incorrect calculation of deduction u/s 80D, 80G.
•
Incorrect calculation of rebates under section 88, 88B, 88C.
•
Mistakes in calculation of taxable income and tax u/s 115JB. Manual
overrides are used to fill in the tax amount.
Description
23
The errors listed have been found and collated from all the 12 States selected for the audit. See
Appendix C for details of certain results of an SQL query on the AST data relating to some of these
errors.
MANAGE DATA
Page 41
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Mistakes in calculation of interest under sections 234A, 234B, 234C
and 244A due to differences in both rate and period for which
interest has to be charged.
Mistakes in calculation of tax due to excess credit of TDS by AST.
Mistakes in calculation of royalty income in the case of NRIs.
Mistakes in calculation of house property income.
Mistakes in calculation of tax on LTCG. In fact LTCG and STCG
details are not available and are not taken into account by the
system while computing tax. The tax on LTCG is separately calculated by the assessing officer and entered into the system.
Mistakes in giving credit for dividend tax under section 115 O and
115P as there is no field for their entry.
Mistakes in carry forward of short term capital loss.
Mistakes in calculation of refunds.
Mistakes in calculation of set off of long term capital loss against
business income.
Education cess not incorporated in the system.
Differential tax rate for winning from lotteries not accepted by the
system.
MAT cases cannot be distinguished by the system.
No check for correct calculation of income under section 24 i.e.
house property income.
PAN problems in processing; non-migration, non-allotment,
duplicate allotment, invalid PAN etc. There are unprocessed returns
also because the returns have been barred by limitation.
Revised returns have been processed after the processing of the
original return.
Incorrect inputs were noticed from OLTAS and e-TDS regarding
credit of taxes paid.
MANAGE DATA
Page 42
Management The data processing errors listed have been examined in detail .They have
arisen for one of the following reasons:
Response
Assessment
•
Certain legal provisions of the Income Tax Act impose restraints on
system functionalities. Other than these legal provisions are strictly
reflected in the AST system.
•
The query results have thrown up errors because of errors in framing
the SQL query, either due to incomplete logic or because of amounts
being compared between wrong tables/fields of the database.
•
Cases where incorrect interest was found computed by the system
had actually been modified by the assessing officer using overriding
functions.
The audit comments have been made based on inputs from field audit and
test check of manual records based on which the queries were designed in
consultation with the department and through a patch released by the DIT
(Systems). A detailed analysis of the issues thrown up through the queries
has been provided by the department supported by data which has, however, not been validated by audit. However, the explanations offered by the
department have been examined and it is felt that certain errors may be
contained in the system, specially in sensitive interest calculating sections.
Manual interventions by assessing offices have a serious risk of compromising the controls since neither the system processing nor the assessing
office is completely accountable in this mixed environment.
There may be data processing errors in the system due to algorithm
mistakes in setting down the business rules of certain sections in the Act.
As has been seen from a study of the patches issued by the DIT Systems
the same problems tend to recur.
Data processing errors are also occurring due to the failure of linkages
between modules and incorrect outputs of other modules being sent as
inputs into AST.
The functioning of other modules of software in ITD viz. AIS, TAS, TDS
and IRLA, have to be reviewed for smooth functioning of AST.
MANAGE DATA
Page 43
R e c o m m e n d a - 23.
tion
A method of minimising DP errors and setting benchmarks for
acceptable levels of errors must be done. The software may be
reviewed as the errors pointed out above are only indicative in nature
and taken from a sample of the cases processed through AST.
24.
The query run by audit and results thereof are an important part of the
process of validation of data processing which requires to be done at
regular intervals by the department itself.
25.
The PAN database in the AIS module has to be made error free
urgently since it affects the functioning of other modules including
AST.
Output Review and Error Handling
Description
The organization’s management should establish procedures for assuring that the
provider and the relevant users review the accuracy of output reports.
Procedures should also be in place for controlling errors contained in the
output.
C o n t r o l Test checks revealed that the assessing officers were not generating the list of
non-filers and also not issuing notice u/s 142(1) to them.
Notes
Test checks revealed that the assessing officers were taking prints of orders/
notices relating to assessments u/s 143(1) only. The prints of orders/notices required under other provisions under the Income Tax Act for which the
functionalities exist in the system were not taken out.
Intimation sheet and refund orders are only generated through the system.
Demand notice, challans and Registers for matters relating to penalty,
prosecution, appeal, rectification, demand and collection are not generated/
maintained by the systems.
MANAGE DATA
Page 44
C o n t r o l All necessary outputs such as reports routinely sent to the CBDT by all field
formations such as those relating to the Central Action Plan as well as other
Notes
statistical reports are not there as required in the AST module.
Mistakes in the processed returns are rectified subsequently; either on being
pointed out by assesses or noticed by the department during scrutiny. Integrity
of output is not evaluated by any set down routine procedures.
There are mistakes in outputs of other modules used as inputs in AST such as
name and address of the assessee24 and credits for taxes paid due to errors in
linked systems25.
There are systems errors in processing of returns which are taken care of by
manual overrides26 or by unnecessary orders under Section 154. Compensating
entries are also made to negate mistakes in data entry or processing27 specially
instances relating to TDS credits.
Refunds have also been given manually, previous years demand of the assessee
is adjusted against the current years refund manually.
Status reports on returns due and received, assessed in summary and scrutiny
and cases to be transferred are not generated.
Management Functionalities for generating notices, lists and registers etc. relating to non filers, processing outputs (intimation sheets, refund cheques, demand notices etc.)
Response
and appeal/prosecution etc. are available either in the AST or the IRLA module. However, since computerization of post processing functions is being done
only now as per the recommendations of the Working Group on computerization, certain registers etc. may not be in use. There are no mistakes due to errors in linked modules and system errors for processing are not taken care of by
manual overrides.
24
This was noted during the audit in Delhi ,Rajasthan and Gujarat
See section on IT Integrity Provisions in Application Program Software
26
See Appendix A Table 4
27
Rajasthan
25
MANAGE DATA
Page 45
Assessment
The list of non-filers was not being generated by the assessing
officers as a result of which the possibility of assessees with income
escaping the tax net cannot be ruled out. All functionalities and their
outputs were not being used, and several statistical reports were being
prepared manually. Further several cases of manual overrides have
been noticed.
Lack of correct data in linked modules affects the outputs of AST.
Audit found that the working group report which has been taken as the
basis of computerisation efforts did not talk of phasing the rollout of
the plan functionality wise. There was no recommendation to
operationalise only two functionalities of AST and ignore the rest. The
recommendation was to implement the critical modules of AIS, AST,
TAS and TDS before the other less crucial modules. The phased plan
is also as per geographical location and not functionality.
Recommendation 26.
Procedures for controlling errors and establishing accuracy of
outputs have to be put in place and enforced.
MANAGE CHANGES
Page 47
Change Request Initiation and Control
Description
Management should ensure that all requests for changes, system
maintenance and supplier maintenance are standardized and are subject
to formal change management procedures. Changes should be
categorized and prioritized and specific procedures should be in place to
handle urgent matters. Change requestors should be kept informed about
the status of their request.
IT management should ensure that change management, and software
control and distribution are properly integrated with a comprehensive
configuration management system.
The change process should ensure that whenever system changes are
implemented, the associated documentation and procedures are updated
accordingly.
IT management should ensure that the release of software is governed
by formal procedures ensuring sign-off, packaging, regression testing,
handover, etc.
Specific internal control measures should be established to ensure
distribution of the correct software element to the right place, with
integrity, and in a timely manner with adequate audit trails.
Control Notes
There is a formal procedure for changes right from problem report and
change request till its solution. Operational documents are also prepared
for changes. The changes are also approved and accounted for.
The system developed and implemented in 1997 did not completely
fulfill all the business requirements. Changes have been necessitated not
only due to changes in the Annual Finance Act and changing technology
from time to time but also due to shortcomings in the system as pointed
out by the assessing officers/users.
The charges for development of any additional query/report
programmes or to undertake substantial modifications/changes are
negotiated separately. The work has been awarded to Tata Consultancy
Services without inviting tenders from other prospective contractors.
Rs. 83.78 lakhs have been paid to TCS during 2000 to 2005 for carrying
out changes to the AST software.
MANAGE CHANGES
Page 48
Management
Response
There have been only 32 changes to the AST Software since its
inception and most of them have been because of changes in the IT Act.
The work has been awarded to TCS through an open tender. Since these
systems were being set up for the first time there were no live databases
and testing had to be done in a simulated environment.
Assessment
A review of the changes carried out in AST revealed that majority of the
changes were not because of external reasons such as amendments to
the Finance Act etc. and were in the nature of design deficiencies. The
fact the system has required so many changes is indicative of the fact
that there were weaknesses in
•
Communicating the User Requirements to the developer;
•
Inadequate scrutiny before acceptance of design; and
•
Incomplete User Acceptance Testing.
User Acceptance Testing was done on a very limited scale and only in a
simulated and not real field environment.
Open tender process was not followed while awarding the contracts for
changes to the system.
Recommendation
27.
User Acceptance Testing should be reviewed. The contract for
changes in the software should be given after due procedure.
MANAGE CHANGES
Page 49
Impact Assessment
Description
A procedure should be in place to ensure that all requests for change are
assessed in a structured way for all possible impacts on the operational system
and its functionality.
Control Notes
Whenever the software is modified through patches by DIT (System), the
system does not have any provision to identify similar type of errors/mistakes
that occurred in the processed data (by raising queries or reports) and to rectify
the same. Directions for manual checking for errors are sent by the DIT
(Systems).
No impact assessment study is undertaken and no queries are run to identify the
errors in the system so that they may be rectified. Instances have been noticed
where users have pointed out invalid rates, dates etc. in the system. While these
have been rectified later, impact assessment of the time lag has not been carried
out in the system. Appendix B details an attempt at a limited impact
assessment.
Management
Response
Assessment
Impact assessment is carried out before incorporating any changes in the
application modules; the modification is fully tested by the developer and the
module incharge before release. AST Instruction 21 through which directions
for manual checking were sent was due to a one off situation, due to a specific
ordinance being effective from the date of its promulgation.
There is no method of impact assessment for the changes carried out in the
system. This could lead to errors remaining un-rectified in the system with risk
of loss of revenue.
Audit found that though change impact assessment is being done through testing
of patches the impact in terms of the business requirement of calculation of tax/
interest/refund is not being done or being asked to be checked manually.
Recommenda- 28.
tion
An impact assessment feature should be built into the software and used
after the incorporation of changes.
MANAGE CHANGES
Page 50
Control of Changes
Description
IT management should ensure that change management, and software
control and distribution are properly integrated with a comprehensive
configuration management system. The system used to monitor changes to
application systems should be automated to support the recording and
tracking of changes made to large, complex information systems.
Control
Notes
Code changes, check in and check out procedures for changes exist. This is
done through PVCS version control management. The changes made were
approved and accounted for.
The patches made by TCS are sent to the RCCs for incorporation through a
separate procedure for each of them.28 There is no set down procedure to
ensure timely incorporation of patches at RCC to monitor the time taken.
Management The overall system was designed in 1994 on client server architecture
which was the best available model considering the state of technology and
Response
communication infrastructure then available in the country. In a regionally
centralized, model changes have to be implemented separately in each RCC.
Procedural safeguards are in place and AST Instruction No 19 shows that
monitoring is being done. Further computed figures of interest can be
manually corrected. In Phase III all RCC databases are being consolidated
into a single national database.
Assessment
As pointed out no systematic/inbuilt monitoring in respect of time taken to
execute changes by RCCs is available. The regionally centralized model has
led to the need for replication of efforts to deal with program changes in
AST29.
Recommendation
29.
A monitoring system for recording and tracking changes should be
built into the software.
28
AST Instruction No 19 points out irregular version updating by RCCs
29
Please see Identify Automated Solutions
MANAGE PROBLEMS AND INCIDENTS
Page 51
Problem Management System and Problem Escalation
Description Information services function management should define and implement a
problem management system to ensure that all operational events which are not
part of the standard operation (incidents, problems and errors) are recorded,
analyzed and resolved in a timely manner. Incident reports should be
established in the case of significant problems.
Management should define and implement problem escalation procedures to
ensure that identified problems are solved in the most efficient way on a timely
basis. These procedures should ensure that these priorities are appropriately set.
The procedures should also document the escalation process for the activation
of the information technology continuity plan.
Control
Notes
Whenever a problem is encountered in running of an application module at the
user level, it is first reported to DBA of the RCC. In case he is not able to
resolve it, the same is escalated for the respective module leaders at NCC who
addresses it himself and reverts back to RCC. Whenever necessary, help of
TCS is taken through problem report/change request mechanism. DBA of RCC
and module leaders at NCC depending upon the severity of the problem,
maintain first level record; complete record is maintained once a problem/
change request is given to TCS.
There is no rigid procedure for categorization of problems apart from what has
been described above. However, all problems are taken up and resolved on
their merits so as to keep the application up and running.
Before releasing the application software to the field, rigorous testing is done in
the simulated environment at NCC.
RCC has stated that there was no critical problem, which could stop
functioning of AST application.
MANAGE PROBLEMS AND INCIDENTS
Page 52
Management Response
The policy paper for categorisation of incidents is being formulated in phase
III.
Assessment The procedure for managing problems in running of the software was found to
be generally adequate but ad-hoc. The problems which were addressed and
resolved were documented. However instances of unresolved issues indicated
weaknesses in the process of managing problems and incidents.
In the absence of a system of categorization and prioritization of problems,
there was a risk that problems of critical nature, which could have an impact
on the core objectives of the department, may remain unresolved, or may be
resolved temporarily without addressing the basis of the problem.
As per the existing procedure the problems were escalated through the channel
of RCC and NCC to the software vendor. However, the process of
documentation and linking with the change management is formalized only
when the problem had to be taken up as a change request with the vendors.
Thus, there remained a possibility that even problems of critical nature, which
could be resolved at the level of RCC, would continue to exist in the version of
the system running in the other regions. Risk, therefore, existed that even
identified and rectified errors in the system in one region, with possible effect
on revenue, would continue to persist in the system.
Recommen- 30.
dation
The department should formulate a policy of categorization of problems
and incidents. The policy should inter-alia lay down the priorities for
various categories of problems, the time limits in which they should be
redressed and the procedure for escalation.
DEVELOP AND MAINTAIN PROCEDURES
Page 53
Operational Requirements and Service Levels
Description
The organization’s system development life cycle methodology should
ensure the timely definition of future operational requirements and service levels.
Control Notes
To a query whether operational requirements were determined with
historical performance statistics available, DIT System stated that
there were no automated system for assessments function prior to
implementation of AST application, historical performance statistics
were not available at time of development of AST. However,
performance tuning of AST was carried out to meet enhanced
operational requirements
All operational staff and users are not aware of performance
requirements of AST Software.
There were no service level agreements between the department and
the software developer. A technical cadre for the running of the
National Computer Centre has been formed but suffers from
shortages30 and also has to look after work of an administrative nature.
Management Response
There was no practice of entering into Service Level Agreements in
1994. Technical specifications of AST software have not been given to
the assessment officers as it is not necessary but users are aware of expected response time. Operational requirements are part of the SRS
and SDD documents which were made available to audit. The roles
and responsibilities of technical manpower are laid down in the
Computer Centre Manual. Shortage of technical manpower is due to
litigation problems and quashing of recruitment rules. The application
software is being maintained through a well defined change
management process. There has been no disruption to date and more
than 3.25 crore returns have been processed by more than 4000 users
in 60 cities.
The set of best practices embodied in SLAs were extant regardless of
the actual form given to them in terms of a formal agreement and these
need to be followed. Roles and responsibilities are not clear to users.
30
The EDP cadre Staffing Position is as follows
JD (S)
DD(S)
AD (S)
DPA (B)
DPA (A)
Sanctioned
5
26
73
55
104
PIP
0
24
29
38
20
DEVELOP AND MAINTAIN PROCEDURES
Page 54
Assessment
Users including RCCs and assessing officers were not aware of the
operational requirements. The operational requirement of the AST
software was not laid down as a part of systems development.
Resultantly we found that lack of technical expertise was felt in the
department. In the absence of service level agreements with the
vendors regarding maintenance there was a risk of business disruption
regardless of the fact that no disruption has occurred as yet.
The set of best practices embodied in SLAs were extant regardless of
the actual form given to them in terms of a formal agreement and
these need to be followed. Roles and responsibilities are not clear to
users.
Recommendation
31.
The operational requirements of AST system and ITD
applications in general should be defined and also disseminated.
The role of the technical cadre should be properly defined and
the work allocated to them accordingly. Suitable action should
be taken regarding shortages in the technical cadre.
DEVELOP AND MAINTAIN PROCEDURES
Page 55
User Procedures Manuals
Description
The organization’s system development life cycle methodology should
provide that adequate user procedures manuals and training manuals be
prepared and refreshed as part of every information system development,
implementation or modification project.
Control Notes
The user manual is generally not available with the staff and officers;
hence staff is not aware of and not able to use all the functions available in
the system.
Since the implementation of AST in Delhi in 1997, DIT System has
issued 35 instructions till date regarding several modifications in the
system. However, the revised AST manual incorporating the modifications
has not been prepared. Some of the sections under the IT Act have been
deleted/modified. The validation/range overflow checks specified in the
AST User Manual were not updated as per latest provisions of the IT Act.
For instance even after the abolition of additional tax under section 143 (1)
(a) the concept of a notional return still appears in the User manual.
Computer Based Tutorials were available to users in a limited fashion.
Management Response
Users manuals have been made available on CDs, updated manuals were
distributed on Taexpert; a self learning computer based tutorial was also
distributed. The user manuals were loaded on to the 8000 PCs supplied in
2004. At the initial stage emphasis has been given to processing of returns
so that a high volume low skill labour intensive activity could be
computerised and 3.25 crore returns have been processed.
Assessment
The preparation of user manuals for AST was undertaken as a one time
exercise.
Although user manuals were prepared these were not available to all the
users and the user awareness of the system features was also limited. This
resulted in the sub-optimal utilization of the features of the software other
than for processing and rectification.
The process of updating the manuals, as changes take place in computer
systems due to changes in the business rules, was not in place. These user
procedure manuals would eventually replace the office procedure manuals
in a fully computerised environment and would lead to errors if these were
not in consonance with the extant provisions of the Income Tax Act.
DEVELOP AND MAINTAIN PROCEDURES
Page 56
Recommendation
32.
The user manuals of the system should be made available to all
the users of the system through an adequate process of dissemination and monitoring.
33.
Steps may be taken to ensure users knowledge of the features of
the system and their linkage in the user manuals. All the features
of the system may be taught to the users so that all the functionalities of AST are put to use.
34.
The Income Tax department should update the user manuals of
AST to reflect all the changes carried out in the software due to
changes in the Income Tax Act and due to any other modifications carried out from time to time.
Operations Manual
Description
The organization’s system development life cycle methodology should
provide that an adequate operations manual be prepared and kept up-todate as part of every information system development, implementation or
modification project.
Control Notes RCC has no separate operation manuals and user manuals. RCCs stated
that they had only one user manual for all the modules of ITD applications, which is used as a user, training and operating manual. Soft copies
of all the manuals including AST are installed only on new PCs; the users working at the old PCs are assisted by a resource person.
Management
Response
There is a computer centre manual laying down the operational guidelines which was prepared in 2001. There are written down procedures for
taking back ups.
Assessment
The absence of an operating manual is a serious issue which points to
incomplete inputs given to operating personnel and a consequent lack of
knowledge of procedures. Inadequate maintenance increases the risk of
crashing of the system and puts the entire data at the 36 RCCs at a risk.
Extant data may also be at a risk of deletion.
Recommendation
35.
A separate Operational Manual may be prepared and issued to the
personnel at the RCC so that they are helped in the proper upkeep
and maintenance of the database.
EDUCATE AND TRAIN USERS
Page 57
Identification of Training Needs
Description In line with the long-range plan, management should establish and maintain
procedures for identifying and documenting the training needs of all personnel
using information services. A training curriculum for each group of employees
should be established.
Control
Notes
It was observed that the process of identification of training needs was not
evident. Training was given in areas of:
•
General Computers
•
Microsoft Windows
•
Microsoft Office
•
ITD Applications
There was no formal assessment of training needs for different categories of
users and development of focused training modules for them. Training was
imparted on Microsoft Technologies whereas the AST system is based on
Oracle Technologies.
It was found in 10 of the 12 states31 selected for the review that the users were
generally untrained/not satisfied with the training received and needed more
inputs on all the features of AST.
It was also found that training in some instances was being given on an older
version of software limiting the usefulness of training.
As a result of inadequate identification of training needs in most of the
instances the full features of the AST software were not being used. The users
of the system were reported to be learning by trial and error.
Management Response
31
Assessment of requirement of computer training was done and the scheduling
was matched with the rolling out of the applications. Training needs analysis
is continuously being done. Only the back end of ITD is on Oracle whereas
the front end is Windows 95 and training was provided on Windows for
familiarisation. Oracle training was restricted to technical manpower. A Training Steering Committee was set up to oversee these matters. It is not correct
that full features are not in use due to inadequate training or that users are
learning by trial and error. The training database is modified every year. No
off the shelf training is available for AST as it is customised; training was outsourced as Training labs were not available.
Himachal Pradesh , Delhi , Gujarat , Mumbai , Tamil Nadu , Uttar Pradesh , West Bengal , Karnataka , Jharkhand , Rajasthan.
EDUCATE AND TRAIN USERS
Page 58
Assessment
Training needs analysis needs to be a dynamic and continuing process, in context of software like AST, which is changing continuously.
The end users require a basic familiarity with computers and need to work on
the Forms/Developer interface when working on AST. Relevance of training
on “Windows” and “Office” in the context of AST could not be established.
The inadequacies in the process of identification of training needs have limited
the usefulness of the system and benefits from the system have not accrued, as
they should.
Audit found that the targets of training i.e. the users were generally not satisfied with the training and wanted more exposure to the features of the AST
System.
Recommendation
36.
The department should carry out detailed training needs analysis for
various categories of users of the system. Training modules may accordingly be got prepared including refresher trainings;
37.
When buying off the shelf trainings, the linkage between the training and
actual job requirement should be clearly established.
EDUCATE AND TRAIN USERS
Page 59
Training Organization
Description
Based on the identified needs, management should define the target groups,
identify and appoint trainers, and organize timely training sessions. Training
alternatives should also be investigated (internal or external location, in-house
trainers or third-party trainers, etc.).
Control
Notes
General training on software and application training on AST was being
conducted by the following agencies.
•
•
•
•
•
•
•
NCC
RCC
NADT
RTIs
MSTU
CIT (CO)
In house Training
There was no clear division of responsibility for imparting training by each of
these agencies/methods. The target group was not clearly defined or
categorized properly. None of these agencies could clearly specify their target
client for training.
Training on software like Microsoft Windows and Microsoft Office was
outsourced to NIIT. For training on ITD applications in general and AST in
particular, the user manuals were used as the training material. Training on ITD
application was for duration of three days. The system was being run in an adhoc trial and error method in many locations. The users often faced problems
in working with AST and solved these by contacting RCC over the telephone
or otherwise32.
It was observed that although training was imparted to the assessing officers,
their supporting staff had remained untrained. Training to the ministerial staff
has started only recently.
The software version being used for training was an older version due to several changes having been made to the software.
32
West Bengal
EDUCATE AND TRAIN USERS
Page 60
Management
Response
Initially imparting of training was the responsibility of NCC and the three
RCCs. It was then outsourced to NIIT and then to SSI. A training infrastructure
was also set up at NADT, RTIs and MSTUs for actual delivery of training.
Training was provided to all assessment officers and one staff member. Imparting of more training inputs is an ongoing process.
Assessment
The method, effect, usefulness and duration of the training on AST were not
found adequate. Most of the Assessing officers themselves felt that they needed
further training, by way of refresher courses etc. Consequently users were not
fully aware of the features of the AST software.
Training at all levels including the ministerial level were inadequate. Training
on an older version of the software has meant that the usefulness is limited.
Audit found that the multiplicity of agencies has led to a blurring of efforts and
less efficient targeting.
Recommendation
38.
Training needs should be properly identified at all levels and training
imparted in an effective, organized and useful manner.
MANAGE THIRD PARTY SERVICES
Page 61
Supplier Interfaces & Owner Relationships
Description Management should ensure that all third-party providers' services are properly
identified and that the technical and organisational interfaces with suppliers are
documented.
The customer organisation management should appoint a relationship owner
who is responsible for ensuring the quality of the relationships with third
parties.
Control
Notes
Third party services were used for the data entry of returns all over the country
in 2003 with instructions given to the Chief Commissioners of all regions to
outsource data entry so that processing of all returns was completed by the end
of the financial year. Funds were placed at the disposal of the concerned CCITs
and they were authorised to use the funds at their discretion. The letter through
which the directions were conveyed to the Chief Commissioners did not outline
the interface with supplier adequately. The relationship owner was not clearly
identified with responsibilities divided between the administrative and systems
setup.
Management Response
The time limit for processing of returns was reduced to one year by the Finance
Act of 2001, and the Kelkar Committee recommended that backlog of
processing of returns be cleared within four months. An in-house committee
was set up, and the Board decided to outsource data entry of returns for
processing to act on the recommendation of the Kelkar Committee and take
into account the shortening of the legal time limit for processing. Detailed
guidelines were laid down for the Chief Commissioners which included the
requirements for security, confidentiality and non disclosure.
Assessment
There were no coherent policy regarding identification of the areas where third
party service providers should interface with the organization. No details as to
the deliberations of an internal committee were provided to audit. The
instructions issued to Chief Commissioners’ regarding outsourcing of data
entry was inadequate and did not lay down guidelines for critical issues of
confidentiality, non disclosure, accountability etc. Funds were placed at the
disposal of the Chief Commissioners’ without detailed and specific guidelines
as to their use.
The work of the income tax department is highly sensitive in nature and
outsourcing of core departmental functions is risk factor which needs to be
recognized and controlled.
MANAGE THIRD PARTY SERVICES
Page 62
It is recommended that the Income Tax Department
Recommendation
39. Prepare a policy document on the nature and kind of services that can be
outsourced to third parties;
40.
Lay down detailed guidelines regarding hiring of third party services; and
41.
For any major outsourcing as significant as data entry of returns, have a
well-defined responsibility and accountability statement.
Third Party Contracts
Description
Management should define specific procedures to ensure that for each
relationship with a third-party service provider a formal contract is defined
and agreed upon.
Control
Notes
There was no stated specific policy regarding the contract with the third
party service provider. General conditions of contracts were not specified in
requisite detail. The letter addressed to all CCITs on the subject of
outsourcing of data entry for processing of returns, very briefly addressed
the issues of security, confidentiality and non disclosure etc. No model
contract was sent as a guidance while entering into the actual contracts.
Management The policy for outsourcing was laid down in a letter to all CCITs dated 20th
November 2002 which required agreements to be entered into with the
Response
proper clauses.
Assessment There was no uniformity or clarity on the matter of third party contracts and
there was a lack of guidelines on the specific issues to be covered in the
contracts. Sensitive matters of security, accountability as well as
ensuring correctness of data entry were not appropriately addressed. The
Chief Commissioners entered into different contracts as per their own
discretion with no standardised contract specifications set down.
Recommendation
42.
A model contract should be worked out incorporating all the
concerns of the Department that need to be considered while
outsourcing activities. The relationship owner entering into the
contract should be specified.
MANAGE THIRD PARTY SERVICES
Page 63
Security Relationships
Description
With regard to relationships with third-party service providers, management
should ensure that security agreements (e.g., non-disclosure agreements) are
identified and explicitly stated and agreed to, and conform to universal
business standards in accordance with legal and regulatory requirements,
including liabilities.
Control Notes The income tax return of an assessee is a sensitive document therefore it is
necessary for the department to ensure that the relationship with the third
party service provider is adequately safeguarded by appropriate provisions
to maintain the confidentiality of the data in the return. In the absence of
agreements entered into with the vendor, audit could not ascertain whether
all issues regarding confidentiality/security of data were clearly addressed.
In one case it was observed that the data were entered using the user-id of
the departmental staff.33 The Department did not maintain details of data
entry outsourced.
Management Clear and common guidelines were set down for outsourcing. The “Scheme
for Outsourcing of Data Entry of returns” addresses these issues.
Response
Assessment
The income tax return of an entity is confidential information in the hands
of the Income Tax department. However the department did not ensure that
the relationship with the third party service provider was adequately
safeguarded by appropriate provisions in the contract and supporting
processes in a standardized manner. The guidelines provided were sketchy
and inadequate.
Further, the use of departmental staff login as access to the system by third
party agents with the Roles and Privileges of the staff results not only in
security lapse but also in the possibility of the data already entered by the
staff being changed.
Recommendation
33Tamil
44.
Security issues should be identified, explicitly stated and agreed to.
Necessary guidelines for this should be issued.
Nadu: Data entry of returns was outsourced and the data were entered using the user-id
of the departmental staff. Details of data entry outsourced were not maintained.
CONCLUSION
Page 65
The AST system which is one of the biggest initiatives of the IT processes of the Income Tax
Department, has been found to have several process weaknesses which have considerably limited
the usefulness of the system. Although the initiative commenced in 1993 only 58% of the
intended users have been brought onto the system so far.
The planning for the system identification and acquisition was weak and feasibility studies,
whether technical or economic, were not done before undertaking the project. This lack of
planning has meant that there are integration issues with other ITD applications and prior period
data of the department. There is low user awareness about the features of the system and
consequent non utilization of functionalities other than those for processing and rectification.
The system has required several changes since inception indicating weaknesses in design, and
testing. There was no method of impact assessment for these changes. Certain controls which
were available in the manual environment are not functioning effectively in the computerized
system. There is an unacceptable level of manual overrides which affects the output integrity of
the system.
Problems were noticed in inputs, outputs and data processing integrity. The system does not
evaluate the integrity of input and output data as well as that of data processing. Lack of adequate
technical manpower affected operational efficiency.
There was no overall policy or detailed procedures to be followed on outsourcing and relations
with third parties which lead to lack of uniformity and clarity on this critical issue.
Department stated that AST was a legacy system and that technological upgradation and
extension issues would be addressed in Phase III of computerization. The Department agreed to
examine the issues raised by audit and stated that it may consider the possibility of revising the
software as part of the Business Process Reengineering effort.
New Delhi
Dated
( SUDHA KRISHNAN)
Principal Director of Receipt Audit
(Direct Taxes)
Countersigned
New Delhi
Dated
( VIJAYENDRA N. KAUL)
Comptroller and Auditor General of India
APPENDIX ‘A’
Page 67
Table 1
Stations
Cases not processed due to absence
of PAN
Number
Hyderabad
62825
Chennai
19553
Mumbai
72187
Ranchi
189
Rajkot
10458
Chandigarh
65860
Jaipur
Kolkata
Delhi
115166
621
7218
Bangalore
44818
Allahabad
39524
TOTAL
438419
APPENDIX ‘A’
Page 68
Table 2
Stations
Returns not processed as barred by
limitation u/s 153
Number
Hyderabad
16481
Chennai
24211
Mumbai
171427
Ranchi
4772
Rajkot
4521
Chandigarh
17472
Jaipur
18138
Kolkata
40808
Delhi
74378
Bangalore
28845
Allahabad
6364
TOTAL
407417
APPENDIX ‘A’
Page 69
Table 3
Stations
Hyderabad
List of Original Returns
Proessed after filing of Revised
Returns
Number
8527
Chennai
26419
Mumbai
87803
Ranchi
4091
Rajkot
5787
Chandigarh
10283
Jaipur
42452
Kolkata
24959
Delhi
71634
Bangalore
28254
Allahabad
3112
TOTAL
313321
APPENDIX ‘A’
Page 70
Table 4
Manual Over-riding of the AST
System
Station
Number
Hyderabad
51366
Chennai
68786
Mumbai
292047
Ranchi
2909
Rajkot
40141
Chandigarh
36227
Jaipur
Kolkata
Delhi
103885
56508
278644
Bangalore
48288
Allahabad
19867
TOTAL
998668
APPENDIX B
Page 71
Table 1
Station
Cases where the total of all Heads of
Income is not equal to Gross Total Income
Number
Hyderabad
169
Chennai
631
Mumbai
17848
Ranchi
87
Rajkot
16
Chandigarh
62
Jaipur
Kolkata
109
1118
Delhi
981
Bangalore
100
Allahabad
26
TOTAL
20664
APPENDIX B
Page 72
Table 2
Station
Cases where section wise Chapter VIA deduction
are not equal to Total Deductions
Number
Hyderabad
6
Chennai
1
Mumbai
56
Ranchi
10
Chandigarh
14
Jaipur
2
Kolkata
5
Delhi
51
Bangalore
39
Allahabad
12
TOTAL
196
APPENDIX B
Page 73
Table 3
Station
Cases
where
returned
Income is not equal to Gross
total Income less Deductions
Number
Hyderabad
442075
Chennai
846582
Mumbai
2491839
Ranchi
157108
Rajkot
232720
Chandigarh
428936
Jaipur
556303
Kolkatta
244283
Delhi
1493191
Banaalore
765895
Allahabad
159392
TOTAL
7818324
APPENDIX B
Page 74
Table 4
Station
Cases where returned income is not equal
to Income taxed at normal rates plus
Income taxed at special rates
Number
Hyderabad
11238
Chennai
28415
Mumbai
645292
Ranchi
1559
Rajkot
25211
Chandigarh
29006
Jaipur
16009
Kolkata
35412
Delhi
70317
Bangalore
168876
Allahabad
4191
TOTAL
1035526
APPENDIX C
Page 75
Table 1: Interest calculation u/s 234A, 234B, 234C
(figures are in crores)
State
Mistake in calculation
Hyderabad
1.36
Chennai
0.51
Ranchi
0.09
Rajkot
0.14
Chandigarh
0.20
Jaipur
0.94
Kolkata
0.24
Delhi
Allahabad
15.14
0.06
18.68
APPENDIX C
Page 76
Table 2: Interest calculation u/s 244A
State
No. of cases with mistakes
Hyderabad
172347
Chennai
342121
Ranchi
54190
Rajkot
63960
Chandigarh
Mumbai
162445
1214655
Jaipur
187764
Kolkata
446215
Delhi
831095
Bangalore
225190
Allahabad
62220
3762202
APPENDIX C
Page 77
Table 3: Calculation of tax u/s 115JB
State
No of cases with errors
Hyderabad
135
Chennai
212
Mumbai
1766
Ranchi
5
Rajkot
43
Chandigarh
56
Jaipur
64
Kolkata
Delhi
501
1213
Bangalore
169
Allahabad
5
4169