RHODES UNIVERSITY

AUDITING 3
APPLICATION CONTROLS

Source: Auditing Notes Chapter 8 (pg. 40 – 54)

(We will come back to Page 55 to 72 once we have looked at audit procedures)

INTRODUCTION
Application controls are controls over the input, processing and output of financial
information to ensure that the information is Valid, Accurate and Complete. Application
controls also include controls over the maintenance of the related masterfiles or
standing data. Application controls incorporate user (manual) controls and
programmed controls. Application controls are very closely linked to the cycles that
we discussed before and a lot of the information that we will cover will be quite familiar
to you from the cycles and from Coso.

The stages through which the transactions flow through the system can be described
as follows:
➢ Input (the initiation of the transaction by loading on the computer module or
online form) – So let’s consider 2 simple examples:
▪ let’s use an easy example that most of you would be familiar with first,
if you want to do a PV calculation in excel, you will enter information such
as the interest rate, payment amount, etc. – this will be your input.
▪ If we consider the Acquisition cycle, when you place an order, you will
enter the information into the system, details of order, etc.

➢ processing (once the digital/online form has been completed, it is submitted

and the application/system processes the transaction or request or application).
So, if we take our examples further:
▪ excel will use your information and do the calculation.
▪ For the order example, the system will use the information and process
it into the system; and

➢ output (this is basically the result of what was initiated)

So, if we finish our example:
▪ For excel, the computer will give you your result, so the PV that you
calculated using the excel formula.
▪ For the ordering of goods, the output would be confirmation of order with
the supplier and maybe the notification via email or other medium of
communication that the order has been placed e.g. telephone message).
 Note that application controls can or will be described in terms of these activities
e.g. applications relating to Input of sale. But then for assessments we normally ask
them according to assertions VAC:
▪ Occurrence and Authorisation (Valid)
▪ Accuracy
▪ Completeness.

For example we would say “Identify and discuss controls that should be
implemented to ensure accuracy of sales of prepaid airtime” – The key word
here is Accuracy, which means that the candidate should focus on accuracy
controls whether they relate to input/processing or outputs.

Master Files
In addition to implementing controls over input, processing and output, controls must
also be implemented over master files.

A master file is a file that is used to store only standing information and balances for
example the debtors Masterfile will contain debtor’s names, address, contact details,
credit balances etc. The Master file is very important part of producing reliable
information and must be strictly controlled.
For example “if a salesman wants to make out an invoice for a credit sale on the
system, the first thing he will do is to enter the customer’s name or account number or
account number to see if the customer is a valid customer. The system checks the
account number (or name) against the master file and if there is no match, the
salesman cannot proceed.”

(You will also see this in the employee file in the payroll cycle (We will still cover this!).
If the cycle is computerised you will have a Masterfile for your employee which will
have similar information than the employee file, so for example the employee name,
ID, remuneration rate, job title, etc.)

PREVENTION VS DETECTION AND CORRECTION

As alluded to already, preventing errors from entering the system is better than
detecting them later on. However, nothing is perfect, so it is almost impossible to
prevent errors completely. The main focus of application controls (and any control
generally) will be to prevent errors, but a good system will also have strong detection
and correction controls.
Correction controls tend to generally be manual in nature as manual review of errors
detected is generally necessary (Think for example when you buy something at PnP
or Shoprite and the teller scans it incorrectly, to correct it, she has to call a manager
to reverse the transaction, etc).

UNDERSTANDING CONTROL ACTIVITIES IN A COMPUTERISED ACCOUNTING

APPLICATION.
Whenever dealing with Internal Controls, you always need to consider the COSO
framework and ISA315 as it describes the effective design of internal controls. We will
first discuss control activities discussed under Coso and ISA315 in the context of a
computerised application to give you a better understanding of how control techniques
and specific application controls are implemented.
It is important to remember that application controls are a combination of manual and
automated controls. Manual controls can also be referred to as “user controls”. Which
include all the controls which people carry out, for example signing a cheque,
authorising a document, performing a reconciliation, etc.

We will discuss the following control activities in the context of a computerised

application:

1. Segregation of Duties
2. Isolation of responsibility
3. Approval and Authorisation
4. Custody
5. Access Controls
6. Comparison and Reconciliation
7. Performance Review

1. Segregation of duties
• As explained before segregation of duties is achieved by assigning
incompatible duties to different individuals.
• This enables the checking of one employee’s work by another employee
and prevents an employee from covering up errors, unauthorized actions
and misappropriation.
• Also refer to logical access management controls and toxic
combinations that we discussed.
• Potentially, computerization is a danger to segregation of duties as it
takes employees out of the application and enables the control
procedures relating to authorization, executing, custody and recording
to be performed by one employee and his/her computer (So a high risk
of having one employee doing everything on his/her computer!).
• In addition, computerization enables numerous employees to gain
legitimate access to the accounting records, which means that the risk
that they may be performing incompatible functions is increased. So, for
example, the person that has the custody of physical petty cash, might
also have access to the petty cash accounting records on the computer.
This can create problems as this person now has the potential ability to
manipulate the accounting records which will be considered as poor
internal controls, unless the person is strictly denied the ability to make
Changes to the accounting records.

• How can we achieve segregation of duties in a computerized

environment?
o It can be achieved primarily by controlling access which
employees have to the system itself, the applications on it and the
modules or functions within the application. The above is
achieved by setting up user profiles on the system for each
employee which detail exactly what that employee must be given
access to and what he can do e.g. write access or read access.
This is basically the principle of least privilege.
2. Isolation of responsibilities
• In a manual system, isolation of responsibilities is usually achieved by
making a specific employee(s) responsible for each function or
procedure and requiring that the employee sign the document relevant
to the procedure he is performing, to acknowledge (take responsibility
for) having carried out the procedure.
• A computerized system can enhance isolation of responsibilities by
programming the computer to produce a log of who did what and when
it was done (logging).
• If the log is properly followed up, it becomes an effective way of isolating
responsibility. For example, a company that has five receiving clerks
recording deliveries of goods with the suppliers with only two PC’s
available in the receiving bay can, by requiring the use of unique user
IDs and passwords, record the identity of the receiving clerk through a
log. The log will record who received the goods by recording the user
ID. Obviously with this you need to implement strong controls over your
user ID etc. For example, if everyone knows the one person’s password,
it would be easy to just enter that person’s ID and password and the
computer will then log that person as having accessed the system even
though it was another person, which defeats the purpose of the log!

3. Approval and authorization

• Approval and authorization can be a (manual) user procedure, for
example signing a document, or an automated (programmed) control.
• In a computerized system the authorization and approval of a transaction
can be carried out far more effectively and efficiently than in a manual
system.
• The system can be programmed not to proceed if certain conditions or
controls have not been satisfied for example:
o An order clerk who wants to place a purchase with the suppler,
who is not approved by the company will be prevented from doing
so because the system will not allow an order to be initiated on
the system if the supplier is not on the approved supplier master
file. Approval is given by the fact that the supplier is on the master
file.
o The system may be programmed to allow a salesperson to give a
discount of up to 20% to a customer to secure a sale. If the
salesperson tries to give a discount above 20%, the system will
not allow him to proceed to generate the invoice (sale not
approved)
• The point is that a computerized system is very effective at preventing
unauthorized transactions from taking place.
• Of course, these types of controls can be overridden (which is
sometimes necessary, but there should be strict controls over whom can
override the general controls in valid circumstances), but overrides will
be logged by the computer and should be followed up.
• Logging and following up is a detective manual control.
• The system may also be programmed to enable authorisation/approval
to be given on screen (on the system) by another person. How this is
done may vary, but the principle is generally that Employee 1 selects the
 send option and his computer then transmits a message to employee 2’s
computer, alerting him to the fact that the file is ready for authorisation.
Employee 2 accesses the file, carries out the necessary checking
procedures and, if satisfied selects the approve option on the screen.
Once the approve function has been selected, the computer will prevent
any further changes to the file. Another control that can strengthen this
process is that employee 2 should have only read access to the file so
that he can ONLY approve and NOT make any changes! This enables
segregation of duties and Isolation of Responsibility.

4. Custody
• Application controls play an important role in the custody of company’s
assets, particularly the company cash and bank and other assets held in
an electronic form such as the debtor’s master file.
• In reality, all the information on the database should be considered as
an “asset” that need to be strictly controlled as without its information, a
company is in serious trouble.
• Should the company not have effective application controls in place to
prevent and detect certain invalid actions, the asset is under serious
threat
o E.g. in the case of cash in the bank, the company does not have
physical controls over cash, but must control access to tye
company’s bank account and controls to prevent unauthorized
transactions and approvals. Strong controls over EFT’s
(discussed later) is also necessary.
o In the case of debtors it is a matter of protecting information about
the debtor held in the master file, transaction file and supporting
documentation. If the electronic information is corrupted or
destroyed, the company is going to find it difficult to reconstruct
its records
o In addition it may affect the company accuracy of the information,
e.g. not having information that is up to date.
• To conclude, in a computerized system, the electronic data will be
protected by a combination of general and automated application
controls. Whilst hardcopy documentation will be physically protected
(general physical controls), electronic files will be protected by a range
of different controls, including controlling unauthorised access to the
system as well as adequate continuity of operations (physical controls
and disaster recovery).

5. Access controls
• Once a person is introduced into a system, suitable access controls must
be implemented for that terminal and employee. Access violation can
have extremely serious consequences for the business. Just like with IT
General Controls the consequences for the application could be as
follows:
o Destruction of data
o Theft of data
o Improper changes to data
o Recording of unauthorized or non-existent transactions
 • Examples of Controls to avoid the above may be the following:
o Access to particular applications can be restricted to a particular
terminals e.g. the ability to effect payment or EFT transfer can be
restricted to the terminal of the financial manager. (generally
access is restricted to certain user profiles, but as indicated it can
also be restricted to a certain physical computer!)
o Access is restricted in terms of user profiles/access tables/ least
privilege at both systems level and application level, for example:
▪ At the system level, access to a particular application may
be restricted to particular users
▪ At application level, access to a specific programme
function may be restricted to a particular user on the “Least
privilege” basis e.g. sales order entry is limited to telesales
operator
o PC timeout facilities and automatic shutdown in the face of access
violation will prevent continued attempts to access the system as
well as threat of employees leaving their terminals unattended
o Note: Physical access to computer facilities in general and
access controls at system level were covered in General
Controls.
o Once a user has been granted access to a particular application,
the least privilege principle ay be implemented in a number of
ways to restrict access:
▪ Restrictions to a module or programme function – for
example only certain persons have access to Master file
amendments
▪ Restrictions i.t.o type of access (read only, etc)
▪ Restrictions i.t.o time of day (e.g only during working
hours)
▪ Restrictions i.t.o extent of access to data (Some NB data
not visible, etc.)
o Access should be LOGGED!
o In summary, a user:
▪ Must identify himself to the system with a valid user ID (e.g
your student number)
▪ Must authenticate (prove that it is you!) himself to the
system with a valid password
▪ Will only be given assess to which he is authorised (That
is necessary for the completion of his job!)

6. Comparison and reconciliations

• A reconciliation is a comparison of two or more different records of
information or recorded information and a physical asset
• In a manual system this is done by employees painstakingly comparing
the two sets of information to identify differences
• In a computerized environment this reconciliation can be completed
accurately, comprehensively in no time at all! For example: in a manual
system an employee would reconcile the net wages paid in wage period
2 to the net wages paid in period 1 to establish if and why they are
 different. This could take long as the employee would need to consider
changes in number of employees, pay rates, deductions, etc. In a
computerised system this reconciliation can be completed accurately,
comprehensively and in no time at all by the computer which will then
produce a report for review.

7. Performance reviews
• These controls include inter alia, reviews and analysis of actual
performance versus budgets /forecasts /prior year results etc.
• In principle manual and automatic procedures do not differ. The major
advantage of a computerised system is its ability to produce various
useful reports, including comparisons, reconciliations and reasons for
differences. For example, a computer can give a detailed debtors age
analysis, it can analyse debtors in terms of what they by, how much they
spend etc.
• Modern systems also allows transactions to be tracked through the
system as they are carried out. For example a customer order will start
of in a sales order suspense file. Once ready for goods to be picked, the
computer will move it to a picking slip suspense file and then later to a
invoice file. Throughout the process a manager can access the system
and identify the progress of the order.

One major advantage of a computerised system is that it can be operated

REMOTELY. Your manager can sit at home and be able to access whatever he
needs!

CONTROL TECHNIQUES AND AUTOMATED APPLICATION CONTROLS.

Now that we have reviewed control activities in a computerised environment, we can
move on to a more detailed look at specific control techniques and automated
application controls.

For purposes of these notes we will break it down into the following:
1. Batching
a. Batch entry, processing /update
b. Online entry batch process/update
c. Online real time processing/update
2. Screen aids and related features
3. Programme controls – input and processing
a. Programme checks – input
b. Programme checks - processing
4. Output controls
5. Logs and reports

It is important to remember that these controls seek to achieve Validity,

Accuracy and Completeness (VAC)
 1. Batching
Batching is a technique that assists in controlling an activity which will be carried out
on a batch (group) of transactions with the intention of making sure that all transactions
in the batch were subjected to the activity, that the activity was carried out accurately
and that no invalid transactions were added to the batch.

Batching can be manual or automated or a combination of both.

In the context of an accounting system, batching can be used at the input, processing
and output stage. However the modern software is designed around real-time input
and processing in terms of which transactions are captured and processed almost
instantaneously (real time). Since we need up-to-date information, it is no longer a
case of accumulating for example the week’s sales invoices, entering them onto the
system on a Friday and then processing them over the weekend! If a company does
this the information on the system will be out of date and can cause a number of issues
if relied on, so for example, let’s say you have a customer that places an order on
Friday morning, one of the procedures would be to check that they haven’t exceeded
their credit limit, but your system will be out of date, because the week’s sales invoices
hasn’t been processed yet, so you run the risk that the system might show that the
customer still has credit, when in fact that customer does not, because of a sale during
the week that caused the customer to use its full credit! Which is why real-time
processing is so NB in modern days.

Batching does however still have a place, for example in the payroll cycle, where your
wages are done weekly, every two weeks, etc.

The following description of batching illustrates the principle of batching at the input
stage
Source documents are grouped into separate batches, say 50 and the following
control totals are manually computed:
o Financial totals: totals of any fields holding monetary amounts
o Hash totals: totals of any numeric fields (e.g invoice numbers)
o Record counts: number of records (documents) in the batch e.g. 50
records

A batch control sheet should be prepared and attached to each batch. The
batch control sheet should contain:
o A unique number, for example batch number 3 of 6
o Control total for the batch
o Identification of transaction type, for example invoices
o Spaces for signatures of all people who deal with the batch, for example
prepared by … checked by …….
A batch register should be used to record the physical movement of batches,
the register should be signed by the recipient of the batch after checking what
is being signed for.
Then the batch control system will work as follows
o The details of the batch (e.g. batch description and control totals) are
keyed into the computer to create a batch header label
 o Information of each record in the batch is keyed in and subjected to
relevant automated validation checks…… e.g. valid account number and
limit check
o When all the records have been entered, the computer calculates its own
control totals based on what has been keyed in and compares these
totals to the manually computed totals input earlier to create the header
label (off the batch control sheet)
o If the total agrees and no type of error was detected, the batch is
accepted for processing
o If not, the batch is rejected for correction
o Once control totals have been attached to a batch, they can follow the
batch throughout the process. For example if you had a batch of 50,
your computer will record whether 50 were keyed in (input), 50 were
processed and output for 50 was created.

Batching assists with the following:

▪ Identifying data transcription errors (e.g you keyed in 56 instead of 65)
▪ Detection of data captured into incorrect field location (e.g entered it in as
overtime instead of normal time)
▪ Detection of invalid or omitted transactions or records for a batch – for example,
if you entered a clock card twice, your control totals will not balance!

The following are three ways in ways which transactions can be processed, which
should clarify batching in the context of transactions flowing through the system:

Batch entry, batch process/update

o Initially the transaction data is captured on manually prepared source
documents, for example sales invoices
o These source documents are then collected into batches, usually after
manual checks have been performed and entered via keyboard with
control totals in these batches. Relevant programme checks take place
as the information is keyed in. The transaction information is converted
into machine readable form and held on a transaction file on the
computer system
o These transactions are then processed as a batch when it is
efficient/convenient to do so and the relevant master files are updated to
reflect the effect of the entire batch on affected master file balances
o This way is not common as it is particularly slow and information is not
up to date

Online entry, batch processing/update (also referred to as online entry

with delayed processing)
o Transaction data is entered via keyboard immediately as each
transaction occurs for example “sales order is placed by telephone and
the operator keys in the details as the conversation with the customer
takes place. Relevant programme check take place as information is
keyed in (for simplicity sake, assume an invoice is created immediately
and not only after goods have been dispatched)”
 o The transaction information is converted into machine readable form as
each transaction occurs and is held on a transactions file on the
computer system
o Control totals are created by the computer on the batch for the
transaction file
o The transactions are then processed as a batch and the relevant master
files are updated to reflect the effect of each transaction in the batch on
affected master file balances, for example they could be processed at
the end of each day (daily batch update)
o Entry of the transaction is efficient, but information is still not immediately
up to date. The longer the period that the batch of transactions is not
processed, the less up to date the information will be.

On-line entry, real-time processing/update

o Transaction data is entered via a keyboard, immediately as each
transaction occurs. Relevant programme checks take place as
information is keyed in
o The relevant master files are also updated immediately to reflect the
effect of each individual transaction on affected master file balances, for
example a seat booked on an aircraft will instantly update the “seats
available master file”, which is really an inventory master file for that
particular flight. This could not be done in batches done in batch mode
as the same seat could be booked numerous times before the master
file is updated.
o Entry of the transaction is efficient (access control are very important)
and information is right up to date.

2. Screen aids and related features (for input and particularly design)
Screen aids (application design) have been classified as all the features, procedures
or controls that are built into the application and software and reflected on the screen
to assist a user to capture information accurately and completely, and to link the user’s
access privilege to the screen in from of him.

For example
“If an employee does not have the power (privilege) to approve on-screen document,
there may be no “approve” option for the document appearing on the screen. The
employee may only have the send option. Alternatively, the approve option may be on
the screen but may be shaded and will simply not react if the user clicks on it.
The example basically explains how the screen may be designed for user(s) with
certain privileges. It also highlights that the design of the application in the system is
important. The features are necessary and the privileges should be properly managed
Below are screen aids for input and the design of the screen. Note that they address
V – Validity, A – Accuracy and C – Completeness:
Screen design: The screen should be formatted in terms of what the hard copy
would look like (appropriate screen design for A- Accuracy and C –
Completeness) for example “when entering an order from a customer, the
screen should look like the sales order and should have easily recognizable
fields into which data is entered, such as a box with letters QTY (quantity above
it or numbers should indicate that only numbers required. Basically the screen
 should be formatted to receive essential data in the order in which it is required,
for example the debtors account is at the top”

Minimum keying in of information: the principle is that the less information that
has to be keyed in, the less errors ( A – Accuracy) are likely to occur and the
less time it takes (efficiency and effectiveness), for example:
o Techniques such as “drop down menu” lists should be used, which
simply require the user to “select and click” the option they require from
the options provided on the drop down list
o In a telesales for example, the customer should be required to give only
his account number or name which, when is keyed in, will automatically
retrieve all other standing details, provided the account number is valid
(proving V – validity). It thus makes it unnecessary for the person taking
the name, address etc. of the customer – although this may still be
requested from the customer and compared to the standing data to
authenticate the customer.

Screen dialogue and prompts: These are messages sent to the users to guide
him, for example a prompt may appear on the screen reminding the user to
confirm (V – Validity) or re-enter a field (completeness) or notifying that the
information entered is incorrect (A – Accuracy)

Mandatory fields: keying will not continue until a particular field or all fields have
been entered. Such fields may be highlighted in Red or identified by a Star or
there may be a prompt if the user misses that field and move onto the next field.
This is to ensure C- Completeness )

Shading of fields: these are fields which will not react if “clicked on”, for example
an on-screen sales order may have the customer’s account number and details
shaded, the user completing the sales order will not be able to change the field.
This is to highlight the least privilege principle, e.g. that you do not have rights
to complete certain field, e.g. they may be for office use only or will be
completed by a manger on his profile. Sometimes it may have pre-selected
options, for example say to book a ticket for the Grahamstown Festival, the field
for location and date may be greyed since the place of the event is only
Grahamstown and only happen on a certain date” – this could be for A -
Accuracy and V – Validity

3. Programme controls - input and processing

Programme checks are controls built into the application software, with the intention
of validating/editing information/data which is entered or processed. Validation can
take place at the input and or processing stages. Vast quantities of transactions can
be subjected to a range of programmed controls to consistently produce reliable
information (V – validity).

Errors are reduced and information is provided timeously but remember that a
computer does what it is programmed to do, so although input controls may be very
good, an error in the programming (processing) can undo these benefits and the error
will be processed over and over again
Programme checks are many and varied. We will discuss a number of common
programme checks, but the list is not exhaustive. Often checks are very similar to
others and the same check might be given different names by software providers and
users. As an auditor, you need a general understanding of what the programme check
does so that you can recognise them when you are working in business or at a client.

a) Programme checks - input

▪ Existence/validity checks (V – Validity)

Validity tests: validate data keyed in against the master file, for example a
customer’s account number will be verified against the debtors master file
Matching tests: are described in different ways, but essentially, they amount
to input being matched against data that is already in the database. Checking
input information against data on a master file is a form of matching, as is
matching a biometric characteristic of an employee (thumbprint) against the
employee master file. The company may also match the details of an invoice
received from a supplier to the corresponding GRN held in a suspense file on
the system.
Data approval /authorization tests: confirm input against a pre-set condition,
for example to make a sale on credit, a liquor store requires that a customer’s
identity number be entered on a computer generated invoice. If a customer is
under 18 (which the identity number will indicate), a sales invoice cannot be
granted (the sale is not authorized). Another example would be where the credit
limit on a debtor account can only be 30 or 60 days. An attempt to enter 120
days in the credit terms field would not be approved. The principle here is that
the loaded information is checked against the pre-existing information that is
there to ensure that the transaction is a valid transaction and pre-approved.

▪ Reasonableness and limit checks (A – Accuracy)

Limit checks: detect when a field entered does not satisfy a limit that has been
set, for example the normal hours worked by an employee in a week cannot be
entered at a quantity greater than 40 hours
Reasonableness check: for the data being entered to be accepted, it must fall
within reasonable limits when compared to other data, for example if a normal
order from a customer for an inventory item is 100 units, and a clerk enters
1000, the screen will display a message querying the entry, although there is
no limit on the quantity ordered (the computer does an “instant” check on the
quantity that the client normally orders). Of course, this type of check takes
processing resources, so will only be used if there is a real benefit

▪ Dependency checks (V – Validity)

An entry in a field will only be accepted depending on what has been entered
in another field, for example the acceptability of entering a credit limit of 100k
on a debtor will depend on the status allocated to the debtor.
If the debtor credit status rating is A+ (very good, the credit limit of 100k will be
acceptable. If the status is only B+, the credit limit will not be acceptable
▪ Format checks (A – Accuracy and C – Completeness)
Alpha – numeric checks: prevent or detect numeric fields that have been
entered as alphabetic, and vice versa, for example when entering an
employee’s ID number, the system will only accepts numbers not letters or will
warn if you enter letters.
Size checks: detects when the field does not conform to pre-set size limits, for
example contact number field for SA cell number should allow 10 digits or ID
field should allow 13 digits
Mandatory field/missing data checks: detect blanks where no information
has been loaded but should be loaded or entered e.g. if the quantity is not
entered in the quantity field for the sales order, the data capture cannot continue
Sign checks and/ valid character: The letters, digits or signs entered in a field
are checked against valid characters or signs for that field, e.g. negative sign (-
) cannot be entered on the order quantity field

▪ Check digits (A – Accuracy)

A redundant (extra) character added to an account number, part number, etc.
The character is generated by manipulating the other numerical characters in
the account number. When the account number is keyed in, the computer
performs the same manipulation on the numerical characters in the account
number and if It has been entered correctly, the computer will come up with the
same check digit which was added to the account number originally. If it does
not match, the computer wends a screen message to inform the operator that
the account number has been incorrectly entered. Check digits use up
processing resources and therefore are limited to critical fields. The cannot be
used on financial data.

▪ Sequence checks (C – Completeness and A - Accuracy to lesser extent)

These checks are implemented to detect gaps or duplications in a sequence of
numbers as they are entered, for example if numbered master file amendment
forms are being keyed in, a sequence check will alert the user if there is a gap
or duplicate in the numerical sequence
Following are the controls, but note that some of them are manual controls.
Where the information is entered through the source document, the source
should be:
o Pre-printed, in a format which leaves the minimum amount of information
to be filled manually
o Pre-numbered, sequencing facilitates identification of any missing
documents
o Should be designed in a manner which is logical and simple to complete
and subsequently enter into the computer, for example key pieces of
information should have a prominent position on the document
o Designed to contain blank blocks or grids that can be used for
authorizing or approving the document
 b) Programme checks - Processing
Processing controls assist in ensuring that data is processed accurately and
completely. Processing is a combination of elements in the system, for example
master file, transaction information that has been input, programmes and the hardware
itself. All elements must be controlled if only authorized transactions, which have
actually occurred, are to be processed accurately and completely (V A C)
The user cannot “see” processing taking place, but the computer will be programmed
to carry out checks on itself and report to the user what it has done.
The user then satisfy itself that processing occurred accurately and completely.

Please note that processing will not stop if an error is discovered. The error will be
written to an exception report. Therefore the user will have to review the exception
report and follow up and do the necessary corrections.

▪ Programme Edit checks (A – Accuracy and C – Completeness to lesser

extent)
✓ Sequence tests of documents processed is inspected for gaps, for example
after processing credit notes, the computer may identify missing credit notes
numbers
✓ Arithmetic accuracy test, for example reverse multiplication (multiplication
is repeated but in reverse and answers match, 2 x 5 = 10; 10/5 = 2)
✓ Reasonableness/consistency /range tests are performed after
processing of transaction has taken place, the result is compared by the
computer itself to other information for reasonableness, for example a wage
of R5000 is not reasonable for a grade 3 employee or compared to his prior
wage period’s earnings
✓ Limit test identifies amounts that fall outside a predetermined limit after
processing, for example credit sales to a customer have pushed the debtor’s
balance owing beyond the customer’s credit limit
✓ Accuracy test is where amounts are allocated to columns and the columns
are independently cast (added up), the total columns can be cross cast
(added across) and compared to the total amount allocated, for example net
pay + PAYE +medical deductions = gross pay
✓ Matching in the context of processing is about comparing data that has
been processed against data that is already in the database, for example a
matching control may match clock cards processed with the employee
master file to identify employees for whom there was no clock card
information. The reason there is no clock card may be perfectly valid, for
example the employee was on holiday for the week, but it could also be a
processing error.

▪ Programme Reconciliation checks

The computer will also carry out reconciliations of controls and other totals in
some or other form, based on the principle that if pre-processed totals and post-
processing totals can be reconciled, one can be more confident that processing
was valid, accurate and complete. This means that reconciliations are
addressing VAC.
o Control totals, for example record counts, hash totals from inputs are
compared to record counts and hash totals after processing
 o Run-to-run totals. A final balance arrived at after processing is
compared to the opening balance and individual totals of transactions,
for example the closing balance on debtors (31 May) is compared to the
opening balance plus sales in May less total receipts
o Parity tests: a redundant bit is added to the data to make the sum of the
bits to be in the data concerned, even (even parity) or odd parity.
Changes in parity detected as a result of this test indicate that an error
has occurred in transmission or processing.
o Valid operation code: The processor checks if the instruction it is
executing is one of the valid set of instructions
o Echo test: The processor sends an activation signal to an input or output
device - that device returns a signal showing it was activated. Echo test
can also be used to detect corruption of messages in transit by bouncing
the signal back from the recipient of the message to the sender so that
the sender can compare it against the original message for any errors
that may have occurred during transmission
o Equipment test: Input/output devices are activated prior to a read/write
operation to confirm that they work correctly.

NOTE: Interruptions in processing, which could lead to errors in processing, will be

logged on activity reports and will be followed up by operations staff.

4. Output Controls
The objective of output controls is to confirm that output ( which is the product of
processing) is accurate (A) and complete (C) and that its distribution is strictly
controlled (V), for example that confidential output does not go to the wrong individuals
Output does not have to be in hard copy, it can be on the screen. The accuracy and
completeness output controls will be strongly aligned with processing control,
because, if processing has proved to be accurate and complete, the data, which turned
into reports for users, is far more likely to be accurate and complete.

▪ Controls over distribution will include preventative controls such as:

o Clear report Identification:
▪ Name of report
▪ Time and production number of report (this prevents confusion if
the report is run more than once)
▪ Processing period-covered (assists in carrying out checks against
input data)
▪ Sequenced page and “end of report” message (prevents
undetected removal of pages)
o A distribution matrix of who is to receive which output and when. This
should be aligned with the user profiles and access privileges of
employees so that individuals who do not need access to the reports do
not gain access to the system’
o If output is on hard copy, printed at a certain point and distributed to
users, its movement should be controlled by the distribution list (who
gets what and when) and an entry should be made in a register which is
signed by the authorized recipient on the receipt of the output
 o Output that is confidential should be designed to promote confidentiality,
for example salary slips in sealed envelopes or if electronic in encrypted
or password protected document (pdf)
o Confidential information emails to employees (such as payslips again)
should stipulate “confidential” in the email.
o Output that is printed, especially more sensitive information, should be
printed only in the departments that require the output and if it is
confidential under the supervision of the authorized personnel
o Output which is not required should be shredded, it should not just be
left about or thrown away as a complete document

▪ User controls will include (all detective controls)

o Review of output for completeness for example numerical sequence
check
o Reconciliation of input to output, for example foreman of each cost
centre reconciles overtime worked with his factory overtime records
o Review of output for reasonableness for example the financial manager
reviews period to period wage reconciliations (the payroll manager will
conduct detailed tests on the period to period wage reconciliation
produced by the system)
o Review and follow up of any exception reports produced during
processing, for example individual wage payment that failed the
“reasonableness test” during processing to understand and remediate
the exception

5. Logs and reports

Logs and reports do not have to be printed (but often they are). They can be
accessed on screen. Access can be restricted to read only and should be for
all logs of computer activity which form part of the audit trail.
The types of logs and reports that may be produced by a computer are virtually
unlimited. These may be used as detective or monitoring controls to provide
additional assurance that computer processing is V – Valid, A- Accurate and C
– Complete and that computer usage is authorized and productive.

It is important to be selective about the use of logs and reports as they can
affect the computer performance (slower processing and use of storage space)
They also require review and follow up, so unless personnel are allocated to do
so, the logs and reports themselves are worthless
Types of logs and reports may include:
o Audit trail, which provide listing of transactions and summaries and lists
of tables or factors used in processing
o Run-to-run balancing reports, which provides evidence that the
opening balances that have been updated by a series of transactions
have resulted in correctly calculated closing balances
o Override reports, which provides a record of computer controls that
have been overridden by employees using supervisory or management
privileges. Abuse of such privileges is a threat to the objective of validity
o Exception reports, which provides a summary listing of any activities,
conditions or transactions that fall outside the parameters that have been
set for control purposes, for example employees whose remuneration for
 the wage period fall outside of reasonableness parameters set for
employees of that grade
o Activity reports provide a record for a particular resource, of all activity
concerning that resource for example name of users, usage time and
duration of usage
o Access/access violation reports which are particularly important in
relation to sensitive applications such as EFT or payroll or unauthorized
access to any application

Please note that these are categories of reports. There are hundreds of different
reports falling into these categories may be produced in a reasonable sized business.
The report name or type will depend on the application or system presented to you in
the question

MASTERFILE AMENDMENTS (MASTERFILE MAINTENANCE)

In a computerized financial accounting system, the masterfile contain very important
data, which, if not protected from unauthorized change or access, can have very
negative results for the company. For example, unauthorized increases to employees
pay rates in the employee Masterfile or to debtor’s credit limits in the debtors Masterfile
or the addition of an unapproved supplier to the creditor’s Masterfile could all result in
losses to the company in the long run.

If the qty in the inventory master file is not protected from unauthorized amendment,
theft of inventory could be covered up by reducing the quantity field in the inventory
master file

The automated controls over Masterfile amendment are very important. The objective
will be that:
▪ Only valid amendments are made to the Masterfile
▪ The details of the amendments are captured and processed accurately and
completely
▪ Only authorized individuals will have access to the Masterfile data
▪ All master file amendments are captured and processed

The controls are based on the principles that we have discussed in chapter 8 and will
be a combination of user and programme controls, and will include both preventive
and detective and corrective controls. As usual, the focus will be on preventive.

Below are controls of master file amendments

▪ Record all Masterfile amendments on a source document
▪ Use of authorized Masterfile amendment form (MAF)
▪ Enter only authorized Masterfile amendments onto the system accurately and
completely
▪ Review Masterfile amendments to confirm that they occurred and were VAC

NOTE – When answering questions on controls over Masterfile amendments, you

would use the above procedures and then apply the rest of the chapter. See example
of debtors Masterfile amendment. It is not sufficient to just say that all Masterfile
Amendments should be recorded on a source document. You need to elaborate on
this based on what you have learnt. What is the appropriate design etc. of source
documents – for example pre-printed, sequenced, etc.

NOTE – Modern accounting packages do not allow balances in Master files to be

adjusted other than through a subroutine (subjournal). So for example, you generally
cannot go into the Masterfile and reduce a debtor’s balance. You would need to do
this through a transaction file, for example a credit note, journal entry, receipt.

NOTE – Unused MAFs and other NB supporting documents should be subject to

stationery controls as it is more difficult to create invalid Masterfile amendments
without the source documents.

NOTE – A Masterfile amendment should be carefully checked in all respects before it

is authorized.

EXAMPLE OF CONTROLS OVER DEBTORS MASTERFILE AMENDMENT

PROCEDURE APPLICATION CONTROLS AND RELATED

COMMENTS
Record all Masterfile ▪ All amendments to be recorded on hard copy
amendments on a master file amendment forms (No verbal
source document instructions!)
▪ MAFs to be preprinted, sequenced and designed
in terms of sound document design principles
Use of authorized ▪ The MAFs should be
Masterfile amendment ✓ Signed by two reasonably senior debtors
form (MAF) section personnel, for example credit
controller and senior assistant after they
have agreed on the details of the
amendment to the supporting documents,
for example the approved credit application
documentation for the addition of a new
customer.
✓ Cross-referenced to the supporting
documentation
Enter only authorized • Restrict write access to a specific number of the
Masterfile amendments debtors section by the use if user ID and
onto the system passwords
accurately and • All Masterfile amendments should be
completely automatically logged by the computer on
sequenced logs and there should be no write
access to the logs
• To enhance the accuracy and completeness of
the keying in of Masterfile amendments and to
detect invalid conditions, screen aids and
programme checks will be implemented.
• Screen aids and related features:
✓ Minimum keying in of information, for
example, when amending existing debtors
records, the user will only key in the
 debtors account number to bring up all the
details of the debtor.
✓ Screen formatting, i.e screen looks like
MAF, screen dialogue
✓ New debtors account number
automatically generated by the system
▪ Programme checks:
✓ Verification/matching checks to validate a
debtor account number against the debtors
mastersfile
✓ Alpha numeric checks
✓ Range and/or limit/data approval checks
on terms and credit limit field, for example
credit limit must be between R5000 and
R75 000(range) or cannot exceed
R75 000(limit), and terms can only be 30
days or 60 days (data approval)
✓ Field size check and mandatory/missing
data checks, for example credit limit and
terms must be entered when adding a new
debtor.
✓ Sequence check on MAFs entered
✓ Dependency check, for example the credit
limit granted may depend on the credit
terms granted, for example a debtor
granted payment terms of 90 days, may
only be granted a credit limit of R2000
Review Masterfile ▪ The logs should be reviewed regularly by a senior
amendments to confirm staff member, for example financial manager
that they occurred and ▪ The sequence of logs themselves should be
were VAC checked (for any missing logs)
▪ Each logged amendment should be checked to
confirm that it is supported by a properly
authorized MAF
▪ That the detail, for example debtors account
number, amounts, etc. are correct
▪ The MAFs themselves should be sequence
checked against the log to confirm that all MAFs
were entered.

NB! – Need to apply to the Masterfile amendment applicable. The above is just an
example, you may be required to commend on any Masterfile amendment, for
example Inventory Masterfile amendment, etc. You need to apply the principle to the
specific scenario.
APPLICATION CONTROL TABLE
Refer to the excel workbook. The tables are not extensive but provide a basis for you
which you can and should add to when dealing with application controls.
Please note: In tests and exams, it would be insufficient to merely memorise and copy
down for example, the application controls over the completeness of input. It would
need to be applied to a given scenario. Knowing the tables will only help if you have
practiced the application of them! You need to make sure that you UNDERSTAND
them and can APPLY them to a specific scenario.