ERP architecture, AIS design, automation, and blockchain topics.
This chapter explains how large enterprise systems and accounting information systems organize financial and operational data. ISC emphasizes how these systems shape processing integrity, data flow, and the CPA’s ability to rely on output.
ERP questions should be read as control and data-flow questions, not as software vocabulary checks. The exam usually asks whether an integrated system improves completeness, accuracy, authorization, monitoring, or evidence reliability.
| System area | What to evaluate | Common ISC trap |
|---|---|---|
| ERP modules and data flows | How transactions move across purchasing, sales, inventory, payroll, and financial reporting. | Assuming integration eliminates reconciliation or authorization risk. |
| Accounting information systems | Whether accounting data is captured, processed, summarized, and reported completely and accurately. | Treating AIS as a separate accounting topic rather than a system-control topic. |
| RPA and emerging technologies | Which manual step was automated and what control evidence remains. | Assuming automation is reliable without change control, exception handling, or monitoring. |
| Blockchain reporting considerations | Whether ledger structure changes evidence, access, validation, or reporting responsibility. | Treating blockchain immutability as a substitute for financial statement assurance. |
| Step | What to do | Why it matters on ISC |
|---|---|---|
| 1. Trace the transaction flow | Identify where the transaction starts, which module records it, and how it reaches the general ledger or reporting layer. | ERP integration changes data movement, but it does not eliminate processing risk. |
| 2. Identify master data dependencies | Determine which customer, vendor, inventory, employee, chart-of-accounts, or approval data drives the transaction. | Incorrect master data can create recurring errors across many transactions. |
| 3. Evaluate automated controls | Check authorization rules, edit checks, workflow approvals, exception reports, and segregation-of-duties controls. | Automated processing is only reliable when the control logic is designed and monitored properly. |
| 4. Review change and access controls | Consider who can change configurations, scripts, bots, interfaces, and permissions. | ERP failures often arise from unauthorized changes or excessive access rather than from one manual mistake. |
| 5. Connect system output to evidence | Decide whether reports, logs, reconciliations, or analytics can support accounting and assurance conclusions. | The CPA must understand whether system output is complete, accurate, and usable as evidence. |
| Checkpoint | Exam use | What to avoid |
|---|---|---|
| Transaction path | Trace where the transaction starts, which module captures it, and how it reaches reporting. | Assuming integration means the transaction is complete and accurate. |
| Master data dependency | Identify customer, vendor, inventory, employee, approval, and chart-of-accounts data used by the process. | Testing a transaction while ignoring the master data that drives it. |
| Automated control | Evaluate workflow approvals, edit checks, exception reports, segregation rules, and monitoring. | Treating automation as reliable without checking design and oversight. |
| Change and access risk | Review who can alter configurations, bots, interfaces, scripts, and permissions. | Looking only at end-user access while configuration risk remains open. |
| Output reliability | Tie reports, logs, reconciliations, and analytics to completeness, accuracy, and audit evidence needs. | Using system output as evidence without evaluating the system behind it. |