Accounting Information Systems

Chapter 2
Transaction Processing and Accounting Data

Advance Diploma in Accountancy
Accounting Information Systems   •   Advance Diploma

Transaction Processing and Accounting Data

Introduction and Context

Accounting information systems (AIS) convert evidence of economic activity into information used for control, reporting, compliance, and decision-making. Every sale, purchase, receipt, payment, payroll event, loan, or adjustment begins as an economic event. It becomes accounting information only after it is identified, supported by evidence, recorded, processed, classified, summarized, and reported.

Transaction processing is therefore the operational foundation of accounting. If transactions are incomplete, inaccurately coded, duplicated, unauthorized, or posted to the wrong period, the resulting financial statements may be materially misstated even when the reporting software performs its calculations correctly. An effective AIS must connect business activities with accounting records while preserving an auditable history of what happened, who authorized it, when it occurred, and how it affected the accounts.

This chapter examines the information path from economic events to financial statements. It explains source documents, journals, ledgers, coding schemes, audit trails, master and transaction files, data validation, processing modes, internal controls, and contemporary digital practices.

Learning Objectives

By the end of this chapter, you should be able to:

  1. Explain how economic events are transformed into accounting data and financial statements.
  2. Distinguish source documents, journals, ledgers, master files, and transaction files.
  3. Explain coding schemes and select suitable codes for accounting data.
  4. Describe audit trails and the controls needed to preserve them.
  5. Compare batch, online, real-time, and hybrid processing modes.
  6. Explain validation, authorization, error correction, and exception handling.
  7. Analyze the professional, ethical, and governance implications of transaction processing.

1. From Economic Event to Financial Statement

An economic event is an occurrence that changes, or may change, the resources, obligations, equity, revenues, or expenses of an entity. Examples include delivering goods to a customer, receiving inventory, paying a supplier, borrowing money, or recording depreciation. Not every business event is immediately recognized in the accounting records. A routine telephone conversation may be operationally important but may not create a measurable accounting transaction. Accounting recognition generally requires that the event be relevant to the entity’s financial position or performance, be capable of reliable measurement, and satisfy applicable accounting requirements.

The basic processing sequence is:

Economic event → source document → transaction capture → validation → journal entry → ledger update → trial balance → adjustments → financial statements

The accounting equation provides a control framework:

Assets = Liabilities + Equity

Assets are resources controlled by the entity, liabilities are present obligations, and equity is the residual interest after liabilities are deducted from assets. Revenue and expenses affect equity through profit or loss. For a double-entry transaction, total debits must equal total credits:

Σ Debits = Σ Credits

The equality of debits and credits does not prove that a transaction is valid. A fictitious transaction can be recorded with equal debits and credits. Consequently, accounting information systems require documentary evidence, authorization, validation rules, segregation of duties, and review controls in addition to double-entry bookkeeping.

Flow from economic event to financial statements Economicevent Sourcedocument Capture andvalidation Journals andledgers Financialstatements Evidence, controls and audit trail operate across every stage Master data supplies standing information; transaction data records individual events. Processing may be batch, online, real-time, or hybrid.
Flow from an economic event to financial statements
Figure: Flow from an economic event to financial statements

Figure: The transformation of an economic event into reported accounting information.

2. Source Documents and Transaction Evidence

A source document is the original or authorized record that provides evidence of a transaction. It may be paper-based, electronic, or generated automatically by an integrated system. Examples include:

TransactionCommon source documentTypical evidence captured
Sale on creditSales invoice and dispatch recordCustomer, goods, quantity, price, tax, date
Purchase of inventoryPurchase invoice and receiving reportSupplier, items received, quantity, price
Cash receiptReceipt, bank notification, or remittance advicePayer, amount, date, reference
PayrollApproved timesheet and payroll registerEmployee, hours, rate, deductions
Asset acquisitionSupplier invoice and asset acceptance reportAsset description, cost, location, useful information
General adjustmentAuthorized journal voucherAccount affected, explanation, preparer, approval

Source documents perform several functions. They initiate data capture, support authorization, establish accountability, provide evidence for audit, and allow transactions to be reconstructed. A well-designed document contains a unique identifier, date, parties involved, description, quantities, prices or amounts, tax information where applicable, approval details, and links to related documents.

Electronic documents require controls equivalent to or stronger than paper controls. Important controls include authenticated users, electronic signatures, time stamps, document versioning, protection against unauthorized alteration, retention rules, and reliable links between the document and the recorded transaction. Scanned documents can improve accessibility, but scanning alone does not establish authenticity or completeness.

Source documents should be designed around data minimization and control. Unnecessary personal information increases privacy risk. At the same time, omitting a transaction identifier, authorization field, or tax classification can weaken the audit trail.

3. Journals and Ledgers

Journals

A journal is a chronological record of transactions, normally showing the date, accounts debited and credited, amounts, description, reference number, and posting status. The general journal records transactions that do not fit efficiently into a specialized journal. Specialized journals group recurring transactions, such as sales, purchases, cash receipts, and cash disbursements.

A journal entry for a credit sale of 1,000 currency units, assuming no tax, is:

AccountDebitCredit
Accounts receivable1,000—
Sales revenue—1,000

The entry records the customer’s obligation and the entity’s revenue. In a perpetual inventory system, a second entry may record the cost of inventory sold:

AccountDebitCredit
Cost of sales600—
Inventory—600

The amounts in this example are illustrative. The correct timing and measurement depend on the applicable accounting framework and the entity’s policies.

Ledgers

A ledger groups transactions by account rather than by transaction date alone. The general ledger contains control accounts for assets, liabilities, equity, income, and expenses. Subsidiary ledgers provide detailed records supporting a control account. For example, the accounts receivable subsidiary ledger lists balances by customer, while the general ledger contains the total accounts receivable balance.

A control relationship can be expressed as:

General ledger control balance = Σ Individual subsidiary ledger balances

This relationship applies when the subsidiary ledger is intended to contain all items represented by the control account and both records use consistent dates, classifications, and currencies. A difference signals an error, timing issue, unauthorized entry, or incomplete update requiring investigation.

The ledger supports trial balance preparation. A trial balance lists ledger account balances to test whether debit and credit totals are equal. It is not a financial statement and does not detect all errors. For example, an omitted transaction or a debit posted to the wrong expense account may leave the totals equal.

4. Coding Schemes and Chart of Accounts

Coding transforms descriptive information into structured symbols that systems can store, sort, validate, and report. A chart of accounts is the organized list of accounts used by an entity. A code may identify the account, department, location, project, product, fund, tax category, or customer.

Common coding schemes include:

SchemeDescriptionStrengthLimitation
SequentialNumbers assigned in sequenceSimple and supports completeness checksCarries little meaning
BlockRanges reserved for categoriesEasy classification and expansionMay create unused ranges
HierarchicalPositions represent levels of classificationSupports reporting structuresCan become inflexible
MnemonicLetters or symbols suggest meaningEasy for users to interpretMay be ambiguous or short
Significant-digitEach digit has a defined meaningDetailed classificationLong codes increase entry errors
Intelligent or hybridCombines meaningful and sequential elementsBalances usability and controlRequires governance

A well-designed code structure should be unique, stable, scalable, understandable to authorized users, and compatible with reporting requirements. Codes should not be changed casually because historical comparability and audit trails may be damaged. When an account must be replaced, organizations often deactivate the old code and establish a documented mapping to the new code rather than reusing it for a different purpose.

For example, a seven-character account string might be structured as:

Department–Account–Project

A code such as 04-5120-18 could represent department 04, expense account 5120, and project 18. The exact structure is organization-specific. The important principle is that each segment has a defined meaning, validation rule, and owner.

Coding errors include invalid codes, transposed digits, duplicate codes, misclassification, and obsolete codes. Automated validation should reject invalid combinations, such as a closed project code or a liability account used in a sales journal without appropriate authorization.

5. Master Files and Transaction Files

A transaction file contains records of individual events during a defined period or processing cycle. Examples include sales invoices for a day, payroll transactions for a pay period, or payments transmitted to a bank. Transaction records are generally time-sensitive and are processed into accounting records.

A master file contains relatively permanent or slowly changing information used repeatedly in processing. Examples include customer accounts, supplier accounts, inventory items, employee records, chart-of-accounts data, and fixed-asset registers. “Permanent” does not mean unchanging; it means that the record is maintained across many transaction cycles.

FeatureTransaction fileMaster file
Main purposeRecords individual eventsStores standing reference information and balances
Time patternHigh volume and frequent creationUpdated when attributes or balances change
ExampleA specific sales invoiceCustomer credit limit and address
Control concernCompleteness, duplication, sequenceUnauthorized changes and stale data
Typical relationshipUses master dataReceives authorized updates from transactions

Many systems also use reference files, history files, open-item files, and report files. A transaction may read a customer’s credit limit from the master file, create an accounts receivable transaction, and update the customer’s balance. Poor master-data governance can therefore cause widespread errors: one incorrect tax code or supplier bank account can affect many transactions.

Master-file changes require special controls. These include restricted access, independent approval, effective dates, change logs, review of unusual changes, and periodic confirmation with responsible departments. A person who can create a supplier and release a payment presents a significant segregation-of-duties risk.

6. Data Validation and Error Handling

Validation determines whether input data is acceptable before it is posted or used for processing. Verification, by contrast, checks whether data was captured or transferred accurately. Both are necessary.

Common validation tests include:

  • Completeness checks: required fields are present.
  • Validity checks: a value belongs to an authorized set, such as a valid account code.
  • Format checks: dates, currency amounts, identification numbers, and codes follow required formats.
  • Range checks: quantities or amounts fall within reasonable boundaries.
  • Reasonableness checks: a value is plausible in context, such as hours worked not exceeding a configured limit without approval.
  • Existence checks: a customer, supplier, employee, or account exists and is active.
  • Sequence checks: document numbers are accounted for and gaps are investigated.
  • Check-digit checks: a mathematically derived digit detects common transcription errors.
  • Duplicate checks: the same invoice number is not recorded twice for the same supplier.
  • Cross-field checks: related fields are consistent, such as a tax code matching the transaction jurisdiction.
  • Control-total checks: batch totals agree with the sum of individual records.

A validation failure should not simply disappear. The system should reject or suspend the item, record the reason, notify an authorized user, and preserve the original input where appropriate. Corrections should be made through controlled procedures rather than by deleting evidence. A corrected transaction should retain a link to the original error, correction reason, user identity, and time of correction.

Validation rules should be risk-based. Excessive rules can obstruct legitimate business activity and encourage users to bypass controls. Weak rules allow fraud and error. Rules should be tested when legislation, accounting policies, products, suppliers, or system configurations change.

7. Processing Modes

Batch processing

In batch processing, transactions are accumulated and processed together at a scheduled time. Payroll and periodic depreciation are common examples. Batch processing can be efficient for high-volume, repetitive activities and can simplify review through batch totals. Its limitation is delay: information may not be available until the batch is processed, and an error may affect many records before detection.

Online processing

Online processing captures transactions through an interactive system and often updates records shortly after entry. A user entering a customer order may receive immediate confirmation of inventory availability and credit status. Online access improves timeliness but increases the importance of availability, authentication, input validation, and cybersecurity.

Real-time processing

Real-time processing updates relevant records immediately or nearly immediately after an accepted transaction. A point-of-sale payment, for example, may update sales, inventory, and payment status during the customer interaction. Real-time processing is useful where current information is essential, but it requires resilient infrastructure and careful handling of failed or interrupted transactions.

Hybrid processing

Most modern AIS environments are hybrid. Sales may be recorded online and inventory updated in real time, while general-ledger summarization, reconciliations, or management reporting occur in scheduled batches. The processing mode should be selected according to timeliness requirements, volume, cost, control risk, and the consequences of system failure.

8. Audit Trails and Internal Control

An audit trail is the documented and system-recorded path by which a transaction can be traced from source evidence to final report and, in reverse, from a report back to supporting records. A strong trail answers five questions:

  1. What happened?
  2. When did it happen?
  3. Who initiated, approved, processed, or changed it?
  4. Which records and accounts were affected?
  5. What evidence supports the event?

Forward tracing begins with a source document and follows the transaction through journal, ledger, trial balance, and financial statement. Backward tracing begins with a reported amount and locates the underlying ledger entries, journals, source documents, and approvals.

Audit trails depend on more than keeping files. Systems should use unique transaction identifiers, time stamps, user identification, immutable or protected logs, controlled reversals, version history, and documented retention periods. An audit log must itself be protected from unauthorized alteration. Retention requirements depend on law, regulation, contractual obligations, and organizational policy.

Relevant internal-control principles include:

  • Authorization: transactions and master-data changes are approved by appropriate personnel.
  • Segregation of duties: authorization, custody, recording, and reconciliation are separated where feasible.
  • Access control: users receive only the permissions needed for their responsibilities.
  • Independent reconciliation: records from different sources are compared by someone not responsible for the original processing.
  • Exception reporting: unusual, overdue, duplicate, or high-value items receive review.
  • Backup and recovery: records remain available and reliable after disruption.
  • Change management: programs, configurations, and validation rules are tested and approved before deployment.

A system that produces accurate calculations but cannot show who changed a supplier’s bank account is not a well-controlled AIS.

9. Worked Application: Credit Sale and Reporting Flow

Assume a wholesaler sells goods on credit for 2,000 currency units. The goods cost 1,200. The customer is approved, the invoice is issued, and the inventory is dispatched.

Step 1: Evidence. The sales order, approved customer record, dispatch note, and invoice establish the transaction and support authorization, delivery, price, and customer identity.

Step 2: Validation. The system checks that the customer is active, the product exists, the selling price is authorized, the quantity is available, the invoice number is unused, and the credit limit is not exceeded without approval.

Step 3: Journal entries. Assuming revenue recognition criteria are satisfied and ignoring tax:

AccountDebitCredit
Accounts receivable2,000—
Sales revenue—2,000
Cost of sales1,200—
Inventory—1,200

Step 4: Master and transaction updates. The invoice is stored as a transaction. The customer’s outstanding balance increases by 2,000, and the inventory item’s quantity and carrying amount decrease according to the inventory system’s policy.

Step 5: Ledger and control review. The accounts receivable subsidiary ledger should increase by 2,000, agreeing with the general-ledger control account. Inventory records and the inventory control account should reflect the reduction. The journal remains balanced because total debits equal total credits.

Step 6: Financial statements. Subject to other transactions and adjustments, revenue and cost of sales affect profit or loss; accounts receivable and inventory affect the statement of financial position; the resulting profit affects equity.

This example also demonstrates why the invoice alone may be insufficient. The dispatch evidence supports delivery, while the customer master file supports identity and credit terms. The complete audit trail is distributed across documents, transaction records, master data, journals, and ledgers.

10. Illustrative Case: Riverside Office Supplies

Background

Riverside Office Supplies, a fictional medium-sized distributor, used an integrated sales and accounting system. Sales staff could create customers, enter sales orders, and change prices. Accounts staff converted orders into invoices. The finance manager noticed that gross margin had fallen sharply even though sales volume appeared stable.

Problem

An investigation found three related weaknesses. Sales staff could use obsolete product codes, price changes were not independently approved, and several credit notes were entered without a reference to a returned-goods document. The system’s debit and credit totals still agreed, so the trial balance did not reveal the problem.

Analysis

The investigation traced selected financial-statement amounts backward. It identified invoices for discontinued products, duplicate customer records, and credit notes issued after month-end. The absence of enforced links between credit notes and return documents weakened the audit trail. In addition, customer creation and credit approval were performed by the same user for several accounts.

Approach and solution

Riverside introduced a controlled product master file, inactive status for obsolete codes, approval thresholds for price changes, and a mandatory return-document reference for credit notes. Customer creation was separated from credit approval. Daily exception reports identified duplicate invoice numbers, unusual margins, and credit notes issued after dispatch. A monthly reconciliation compared the accounts receivable subsidiary ledger with the general ledger, while internal audit reviewed master-file changes.

Outcome

The company identified and corrected misclassified sales and unsupported credit notes. Management gained more reliable margin information, and the finance department could trace reported balances to source evidence. Processing became slightly slower for unusual transactions, but the additional approval and validation reduced financial and fraud risk.

Learning points

  1. Balanced debits and credits do not guarantee valid accounting.
  2. Master-data controls can be as important as transaction-entry controls.
  3. Audit trails must connect operational evidence with accounting records.
  4. Exception reports should focus attention on risk rather than replace professional judgment.
  5. Control design should protect accuracy without making legitimate processing impractical.

11. Ethical, Governance, and Contemporary Issues

Accounting data contains commercially sensitive and often personal information. Ethical AIS practice requires confidentiality, integrity, availability, accountability, and respect for lawful privacy rights. Users should not access customer, employee, or supplier information merely because the system technically permits access.

Management is responsible for establishing policies concerning authorization, retention, access, data quality, system changes, and incident response. Auditors and accountants must maintain professional skepticism, document judgments, investigate unusual activity, and avoid concealing errors through unsupported manual adjustments.

Cloud accounting, application programming interfaces, mobile approvals, robotic process automation, and artificial intelligence increasingly connect transaction systems. These technologies can reduce manual entry and identify anomalies, but they also introduce risks involving vendor dependence, automated bias, opaque decision rules, cybersecurity, data residency, and inappropriate confidence in machine-generated classifications. AI-generated account suggestions should be treated as controlled assistance, not unquestionable evidence. Human review remains necessary for unusual, material, judgmental, or legally sensitive transactions.

Contemporary best practices include standardized data definitions, role-based access, multifactor authentication, encryption, continuous monitoring, reconciliations, tested backups, independent review of high-risk changes, and documented responsibility for automated processes. Organizations should also test whether interfaces transmit complete and unaltered data. An integration failure can create gaps even when each individual system appears to operate correctly.

Challenges and Limitations

Transaction processing systems face several persistent challenges:

  • Data quality: inaccurate master data can contaminate thousands of transactions.
  • Complexity: multiple currencies, tax rules, locations, and reporting frameworks increase configuration risk.
  • Timing: online systems may record events before all information needed for final accounting is available.
  • Integration: interfaces can duplicate, omit, or transform data incorrectly.
  • Manual overrides: necessary exceptions may become opportunities for concealment.
  • Change: new products, regulations, and technologies require continuous control redesign.
  • Availability: outages can interrupt sales, payroll, reporting, and statutory deadlines.
  • Human behavior: users may share credentials, bypass approval, or misunderstand codes.

No control is perfect. Effective AIS design combines preventive controls, detective controls, corrective procedures, monitoring, and competent people. The objective is reasonable assurance that transactions are authorized, complete, accurate, timely, properly classified, and traceable.

Chapter Summary

Transaction processing is the foundation through which economic events become accounting information. Source documents provide evidence; transaction capture records events; validation tests completeness, validity, format, authorization, and reasonableness; journals preserve chronological entries; and ledgers organize balances by account. Master files contain standing information, while transaction files contain individual events. Coding schemes provide structured classifications for accounts, products, customers, departments, and projects.

Batch, online, real-time, and hybrid processing modes differ in timeliness, efficiency, control requirements, and operational risk. Audit trails connect source documents, system users, journals, ledgers, and financial statements. Double-entry equality and trial-balance agreement are important controls, but neither proves that transactions are complete, authorized, or correctly classified. Strong AIS governance therefore requires access controls, segregation of duties, reconciliations, change management, exception reporting, secure retention, and professional judgment. Digital integration and AI can improve efficiency, but they increase the importance of data governance, cybersecurity, transparency, and human oversight.

Key Terms

Source document: Original or authorized evidence supporting an economic event.

Economic event: An occurrence that affects or may affect an entity’s resources, obligations, equity, income, or expenses.

Transaction: A measurable economic event recorded in the accounting system.

Journal: Chronological record of accounting entries.

General journal: Journal used for transactions not efficiently recorded in specialized journals.

Ledger: Record that groups transactions by account.

General ledger: Central record of the entity’s control accounts.

Subsidiary ledger: Detailed record supporting a general-ledger control account.

Chart of accounts: Organized list of accounts and their codes.

Coding scheme: Method for representing accounting classifications with symbols or numbers.

Master file: File containing standing or slowly changing information.

Transaction file: File containing records of individual economic events.

Data validation: Testing whether input satisfies defined rules and constraints.

Audit trail: Traceable path between source evidence, processing, records, and reports.

Batch processing: Processing accumulated transactions together at scheduled intervals.

Real-time processing: Processing that updates relevant records immediately or nearly immediately.

Control account: General-ledger account representing the total of a subsidiary ledger.

Exception report: Report identifying unusual, incomplete, invalid, or high-risk items.

Segregation of duties: Separation of authorization, custody, recording, and reconciliation responsibilities.

Master-data governance: Policies and controls for creating, maintaining, approving, and monitoring standing data.

Review Questions

Short Answer Questions

  1. What is the purpose of a source document in transaction processing?
  2. Distinguish a general ledger from a subsidiary ledger.
  3. State two differences between a master file and a transaction file.
  4. What is an audit trail, and why is it important?
  5. Name two advantages and two limitations of batch processing.

Long Answer Questions

  1. Explain the complete flow from an economic event to the financial statements, identifying the control role of each stage.
  2. Discuss the major types of coding schemes and the qualities of an effective chart of accounts.
  3. Explain data validation, verification, error handling, and exception reporting in an accounting information system.
  4. Compare batch, online, real-time, and hybrid processing, including situations in which each may be appropriate.
  5. Discuss how segregation of duties, access controls, reconciliations, and change management protect audit trails.

Analytical / Application Questions

  1. A company’s accounts receivable control account exceeds the total of its customer subsidiary ledger balances. Identify possible causes and design an investigation procedure.
  2. A system records equal debits and credits for every transaction, but management suspects fictitious suppliers. Explain why the trial balance may not reveal the problem and recommend controls.
  3. Design a transaction-processing and audit-trail procedure for an online sale involving inventory, customer credit, electronic payment, and a possible subsequent return.

Multiple Choice Questions with Answers

Question 1

Which document normally provides the initial evidence for recording a credit sale?

A. Sales invoice

B. Bank reconciliation

C. Trial balance

D. Depreciation schedule

Correct Answer: A. Sales invoice

Question 2

What is the primary purpose of a subsidiary ledger?

A. To replace the chart of accounts

B. To provide detailed support for a general-ledger control account

C. To authorize every payment

D. To calculate the accounting equation

Correct Answer: B. To provide detailed support for a general-ledger control account

Question 3

Which statement best describes a master file?

A. It contains only transactions processed during one batch

B. It contains standing information used repeatedly in processing

C. It is a list of financial statements only

D. It contains rejected input that must be deleted

Correct Answer: B. It contains standing information used repeatedly in processing

Question 4

Which validation test checks that an invoice number has not already been recorded for the same supplier?

A. Range check

B. Format check

C. Duplicate check

D. Reasonableness check

Correct Answer: C. Duplicate check

Question 5

If total debits equal total credits, what conclusion is justified?

A. All transactions are authorized

B. No transaction has been omitted

C. The double-entry totals are arithmetically in balance

D. The financial statements are necessarily accurate

Correct Answer: C. The double-entry totals are arithmetically in balance

Question 6

Which processing mode accumulates transactions and processes them at scheduled intervals?

A. Batch processing

B. Real-time processing

C. Continuous online processing

D. Interactive validation

Correct Answer: A. Batch processing

Question 7

Which control most directly reduces the risk that one employee creates a supplier and releases payment to that supplier?

A. Using sequential invoice numbers

B. Segregation of duties

C. Increasing screen brightness

D. Preparing a trial balance

Correct Answer: B. Segregation of duties

Question 8

What does backward tracing in an audit trail involve?

A. Following a source document into a future budget

B. Tracing a reported amount back to ledger entries and supporting evidence

C. Deleting an incorrect transaction and re-entering it

D. Comparing two unrelated master files

Correct Answer: B. Tracing a reported amount back to ledger entries and supporting evidence

Question 9

A sale is recorded for 2,000 currency units and the related inventory cost is 1,200. Ignoring tax, what is the gross profit on the sale?

A. 800 currency units

B. 1,200 currency units

C. 2,000 currency units

D. 3,200 currency units

Correct Answer: A. 800 currency units

Question 10

Which practice best protects the integrity of master-data changes?

A. Allowing all users to edit records freely

B. Reusing inactive codes for unrelated purposes

C. Using restricted access, approval, effective dates, and change logs

D. Deleting the previous version after every change

Correct Answer: C. Using restricted access, approval, effective dates, and change logs

Accounting Information Systems
Chapter 2 of 15