16.2 ERP, Accounting Systems, and Change Management
Key Takeaways
- Enterprise resource planning systems integrate accounting, purchasing, sales, payroll, inventory, fixed assets, treasury, and reporting data into connected, real-time business processes.
- ISC questions often reconcile the documented process with the actual sequence of steps, documents, approvals, tools, and system activities, then locate the precise control gap.
- Processing integrity means transactions are authorized, complete, accurate, timely, and valid throughout an accounting information system.
- Effective change management requires authorization, testing, code review, separation of duties between development and production, logging, monitoring, and rollback procedures.
- Direct, parallel, and pilot conversions create different implementation risks; the best approach depends on tolerance for disruption, cost, and the evidence needed before cutover.
ERP and Accounting Information Systems
An enterprise resource planning (ERP) system integrates major business functions in one application suite or tightly connected platform. A sales order can decrement inventory, a shipment can trigger billing, a cash receipt can update accounts receivable, and an approved vendor invoice can flow to disbursements and the general ledger, all in near real time. An accounting information system (AIS) may be a full ERP or a narrower set of applications that capture, process, store, and report accounting data.
For ISC, the tested skill is tracing the process. The blueprint expects candidates to reconcile the actual sequence of steps, documents, tools, and technology used in processes such as sales, purchasing, payroll, production, treasury, fixed assets, general ledger, and reporting against the documented (intended) process. A walkthrough follows one transaction from initiation to reporting: who performs each step, what system records it, what evidence is created, and what exception path exists when validation fails.
Modern AIS modules commonly include order-to-cash (sales, AR, cash receipts), procure-to-pay (purchasing, AP, disbursements), record-to-report (general ledger, consolidation, financial reporting), hire-to-retire (payroll, HR), and plan-to-produce (inventory, manufacturing). Each module shares master data such as the customer, vendor, chart-of-accounts, and item masters.
Because one master record feeds many transactions, master-data controls are leverage points: a single unauthorized change to a vendor bank account or a product price can corrupt thousands of downstream transactions, which is why the exam treats master-file maintenance as a high-risk activity requiring independent approval and change-report review.
Process-Mapping Questions
| Process fact | Likely CPA concern | Better control response |
|---|---|---|
| Vendor bank details entered by accounts-payable clerks | Unauthorized disbursements / fraud | Independent approval plus daily change-report review |
| Shipping creates invoices before proof of shipment | Revenue occurrence and cutoff | System match of invoice to shipment document |
| Payroll rates changed without HR approval | Accuracy and authorization | Workflow approval and exception reporting |
| Manual journal entries bypass review | Financial-reporting integrity | Required approval, restricted posting rights, logging |
| Three-way match disabled for rush POs | Validity of payments | Re-enable match; supervisory exception review |
The correct ISC answer usually names the gap precisely. "Weak controls" is too broad. Better reasoning says the disbursement was not independently approved, the invoice was not matched to shipping evidence, or the journal entry was posted without review.
Processing Integrity
Processing integrity means the system processes data completely, accurately, timely, and only as authorized, producing valid output. Controls are preventive (required fields, credit limits, three-way match, input edit checks) or detective (exception reports, batch totals, reconciliations). In a SOC 2 context, a CPA may need to identify a design deficiency or an operating deviation in a processing-integrity control.
Classic input edit checks worth memorizing:
- Limit / range check: value falls within a permitted boundary (hours worked 0-80).
- Validity check: entered code exists in a master file (valid GL account).
- Completeness check: all required fields are present.
- Reasonableness check: value is plausible given related data.
- Check digit: an appended digit verifies an account or part number was keyed correctly.
Blockchain may appear, but the focus stays on internal control. A posted blockchain record may be hard to alter, yet management still must control private keys, approve transactions before posting, validate source-data accuracy, ensure interface completeness, and apply correct accounting treatment.
Change Management, Environments, and Conversions
Change management controls reduce the risk that hardware, software, configuration, or data changes disrupt operations or cause misstatement. Strong processes use change requests, authorization, acceptance criteria, code review, documented test evidence, version control, build automation, monitoring, logging, rollback procedures, and restricted production access.
Environments must be separated: development builds code, staging/test validates it, and production runs live transactions. Test layers include unit, integration, system, and user acceptance testing (UAT). A developer who can both write code and migrate it directly to production violates segregation of duties, the single most common change-management defect on the exam.
Conversion approaches when replacing a system:
- Direct (big-bang) conversion: old system stops, new system starts at once; fast and cheap but highest risk.
- Parallel conversion: old and new run together so outputs can be compared; strongest evidence, highest cost.
- Pilot conversion: one location, module, or group goes first; limits exposure before full rollout.
- Phased conversion: modules go live in stages over time.
Patch management follows the same logic: prioritize by risk, schedule, validate compatibility, test before release where feasible, deploy through approved channels, and monitor results.
Emergency changes deserve special attention. A genuine break-fix may bypass normal approval to restore service, but the control is not abandoned: the change must be retroactively documented, reviewed, tested in lower environments after the fact, and approved promptly. A standing "emergency" path that becomes the routine way to skip review is itself the deficiency. Agile and DevOps pipelines compress these steps with automated build, test, and deployment, but the same control objectives apply: automated test gates, peer code review via pull requests, and separation between who writes and who approves a release into production.
Exam Focus
If a fact pattern describes a change moving to production, hunt for the missing control: no authorization, no test evidence, no logging, unrestricted production access, or no rollback plan. Name that specific gap rather than the general weakness.
A controller approves a new ERP sales-tax configuration, but the same developer who wrote the change migrates it directly to production without independent review, test evidence, or logging. What is the strongest change-management deficiency?
A manufacturer is replacing its inventory system. Management wants evidence that quantities and costs agree before shutting down the old system and is willing to operate both systems for one month. Which conversion approach best fits that objective?