## **Learning Outcomes**

After reading this article, you will be able to explain how user roles restrict access in a computerised accounting system, and how authorisations approve transactions before they are processed. You will be able to describe segregation of duties in a computer environment, identify common risks (errors, fraud, data misuse), and state practical controls such as maker–checker approvals, approval limits, audit trails, and periodic user access reviews.

## **ACCA Recording Financial Transactions (FA1) Syllabus**

For ACCA Recording Financial Transactions (FA1), you must understand...

- how computerised accounting systems control access to accounting records using user accounts and passwords
- why payroll information and other sensitive data must be restricted to authorised staff
- how transactions must be properly authorised, especially payments and payroll
- how errors can still occur in computer systems and how internal checks identify them
- risks to data security and the need for data protection procedures
- how accounting data is located, checked and corrected in computerised systems

## **Test Your Knowledge**

_Attempt these questions before reading this article. If you find some difficult or cannot remember the answers, remember to look more closely at that area during your revision._

1. Which control best reduces the risk of a fraudulent payment being made to a fake supplier?
   - A. Allowing all staff to create new supplier accounts
   - B. Using a shared “Accounts” login for the whole team
   - C. Separating supplier creation from payment approval (maker–checker)
   - D. Posting all uncertain items to suspense permanently

2. True or false? If a computerised system prevents unequal debits and credits, it also prevents transactions being coded to the wrong ledger account.

3. State two activities that should usually be performed by different users in a purchase-to-payment process.

4. Which of the following is the best description of “least privilege”?
   - A. Users keep their password private
   - B. Users are given the minimum system access needed to do their job
   - C. Users have access to all modules, but only managers review reports
   - D. Users can approve their own transactions if they are under a limit

## **Introduction**

Computerised accounting systems process transactions quickly and can update many records at the same time. That speed creates a risk: if the wrong person can access the wrong area (or approve their own work), errors and fraud can spread through the records fast.

For FA1, you need to know how access is controlled in practice. Two key controls are (1) user roles, which restrict what each person can do in the system, and (2) authorisations, which require approval before certain transactions (especially payments and payroll) are processed.

## User roles: controlling who can do what

A computerised accounting system should not give every user the same access. Instead, access is set up so people can only see and process what they need for their duties.

> **Key Term: user role**
> A predefined set of permissions in a computer system that matches a job function (for example, “Sales invoicing clerk” or “Payroll processor”).
>
> **Key Term: permission (access right)**
> A specific system ability granted to a user, such as viewing payroll, entering invoices, amending supplier details, or approving payments.

### Why roles matter in bookkeeping

Roles reduce the risk of:

- accidental errors (for example, an inexperienced user posting journals)
- unauthorised transactions (for example, a user creating a supplier and paying them)
- data misuse (for example, employees viewing payroll details without a work reason)

Roles also make accountability clearer because actions can be linked to individual users.

### Typical roles you might see

In exam questions, roles are often described using everyday job titles. You should be able to suggest suitable access for each.

- **Sales user**: raise sales invoices and credit notes; view customer balances; no access to supplier payments.
- **Purchases user**: enter supplier invoices and credit notes; view supplier balances; no access to release bank payments.
- **Cashier/bank postings user**: post receipts and payments based on approved documentation; no ability to set up new accounts.
- **Payroll user**: process payroll runs; limited ability to change standing data (such as pay rates).
- **Manager/approver**: approve transactions; review exception reports; may not enter the original transactions.

### Privileged access (system administrator)

A small number of users may be able to create users, change roles, or reset passwords. This access should be tightly restricted because it can bypass normal controls.

> **Key Term: privileged user**
> A user with high-level system access (for example, user administration or system settings) that could override normal processing controls.

## Authorisations: approving transactions before processing

Computerised systems often allow a transaction to be entered by one person and approved by another. Authorisation is especially important for payments, payroll, and changes to standing data (such as bank details).

> **Key Term: authorisation**
> Formal approval that a transaction or change is valid, made by a person with the right level of responsibility.

### Maker–checker control (two-person control)

A common control is that one user “makes” (enters) a transaction and another user “checks” (approves) it.

> **Key Term: maker–checker control**
> A control where one user enters a transaction and a different user approves it before it is posted or paid.

This reduces the chance of both error and fraud, because a second person must agree the transaction is correct.

### Approval limits

Many systems apply approval rules based on value. For example, an invoice might need a manager’s approval if its value is high:

- if invoice value $> £5,000$, route for senior approval
- if $≤ £5,000$, one approver may be enough

In exam scenarios, you should link the limit to risk: higher values normally require more senior authorisation.

### Payments need strong authorisation

Payments can be generated electronically (for example, automated bank transfers). Even if the system produces the payment file, a responsible person should approve the payment run, ideally someone not involved in entering invoices or maintaining supplier records.

### **Exam Warning**

Do not assume a computer “checks everything”. It may stop one-sided entries and unequal debits/credits, but it will not automatically know whether an invoice is genuine, coded correctly, or supported by evidence.

## Segregation of duties in a computerised system

You can still apply segregation of duties even when one system processes everything in real time. The aim is to split incompatible tasks between different users or different approval steps.

> **Key Term: segregation of duties**
> Splitting key tasks between different people so that one person cannot both create and conceal an error or fraud.

### Common incompatible duties (typical FA1 examples)

Good control normally separates:

- **Set up supplier** and **approve/release supplier payment**
- **Set up employee/change pay rate** and **run payroll/release net pay**
- **Enter invoice** and **approve invoice/payment**
- **Raise credit note** and **authorise credit note**
- **Post journals** and **approve journals**

If staffing is limited, an exam-safe answer is to add extra reviews (for example, manager review of exception reports and reconciliations).

## Audit trail and monitoring

Even with roles and approvals, you still need checks to detect mistakes and unusual activity.

> **Key Term: audit trail**
> A record kept by the system showing who did what and when (for example, user ID, date/time, reference numbers, and changes made).

### What you should expect the system to record

An audit trail commonly records:

- the user who entered and approved a transaction
- the date and time of entry and approval
- edits to standing data (supplier bank details, customer addresses, pay rates)
- reversals, deletions, and manual journals

### Exception reports (management checks)

Many systems can produce reports showing unusual or high-risk items, such as:

- new suppliers created this week
- changes to supplier bank account details
- payments above an approval limit
- manual journals posted directly to the general ledger
- postings to suspense

These reports help managers identify transactions that need follow-up.

### Periodic review of access

Access should be reviewed regularly:

- remove access quickly for leavers
- change roles when someone moves job
- check that privileged users are still appropriate
- confirm users do not have conflicting permissions

## Cloud access and third parties

Cloud accounting allows access from different locations, and sometimes allows limited access for external parties (for example, a payroll bureau). That increases the need to control who can log in and what they can see.

### Restricting third-party access

A third party should only be given access needed for their work. For example, a payroll bureau may need employee hours and tax codes, but not sales invoices or supplier payments.

### Data protection and confidentiality

Accounting systems hold personal data about customers and employees. Access controls (roles, permissions, strong logins, and audit trails) help prevent unauthorised access and reduce the risk of improper disclosure.

### **Revision Tip**

When you see a process question in FA1, write “enter” and “approve” above each step (sales invoices, purchase invoices, payments, payroll). Then check that the same person cannot do both for high-risk steps.

## **Worked Example 1.1**

Ayesha enters supplier invoices into the payables module. Tom approves weekly payments. Priya releases the bank payment file. The business wants to reduce the risk of paying a fake supplier.

> **Answer:**
>
> Set roles so Ayesha can enter invoices but cannot create suppliers or release payments. Set Tom as the approver for the payment run, with the system showing the invoice list and totals for review. Set Priya to release the bank payment file only after Tom’s approval, with an audit trail showing who approved and who released the payment.

### **Worked Example 1.1**

Mateo in HR updates an employee’s hourly rate. Salma runs weekly payroll. The finance manager approves the payroll totals before payment is made.

> **Answer:**
>
> Give Mateo permission to update pay rates but not to run payroll or create bank payments. Give Salma permission to run payroll but restrict pay-rate changes. Require the finance manager to authorise the payroll run (maker–checker), and use an exception report listing pay-rate changes made during the week for review before approval.

## **Key Point Checklist**

_This article has covered the following key knowledge points:_

- user roles restrict what each person can view or process in a computerised accounting system
- permissions should match job duties and be removed or changed when roles change
- authorisation means approval by an appropriate person before processing high-risk transactions
- maker–checker control reduces the risk of error and fraud by separating entry and approval
- segregation of duties is still needed in computerised systems (especially for payments and payroll)
- audit trails and exception reports support review by showing who did what and when
- privileged users (system administrators) should be very limited and monitored
- cloud access and third-party access require tight control to protect confidential data

## **Key Terms and Concepts**

- user role
- permission (access right)
- privileged user
- authorisation
- maker–checker control
- segregation of duties
- audit trail


Controls in computerised systems - User roles and authorisations