D217 Accounting Information Systems, catalog number ACCT 3360, is a three-CU course on the accountant's role in management and financial reporting systems, the transaction cycles that feed them and the information systems built around those cycles. It sits at the join between accounting and technology, and it is assessed in a way that surprises students who expected either a software course or a bookkeeping course. It is neither. It is a course about how data becomes a financial statement and where that path can break.
Transaction cycles are the map of the whole course
Every organization runs the same handful of repeating processes, and accounting information systems are organized around them. The revenue cycle takes an order through shipment, invoicing and collection. The expenditure cycle takes a requisition through ordering, receiving and payment. Production converts materials to finished goods. Human resources and payroll turn time into pay. Financing and general ledger processes close everything into reportable form.
Learn the cycles as processes with documents attached and the course collapses to a manageable size. In the expenditure cycle, a purchase requisition becomes a purchase order, which meets a receiving report, which meets a vendor invoice, and the match between those three documents is the control that stops an organization paying for goods it never received. That single example contains the entire logic of the subject: a process, its documents, the risk at each handoff and the control that addresses it.
The accountant's role in all of this is not to build the system. It is to specify what the system must produce, to evaluate whether the controls embedded in it are adequate, and to know enough about how data moves to ask the questions nobody else in the room will ask. Tasks in this course usually put you in exactly that seat.
Budgeting words when diagrams do part of the work
Rubric aspects in your Course of Study are scored independently and each needs a 2. This course has a planning wrinkle the others do not: several aspects are often satisfied partly by a diagram or a table, and students either over-write around them or assume the diagram speaks for itself.
Worked example with visual deliverables. Suppose your rubric shows six scored aspects and two of them expect a process diagram or a control matrix. Set a prose target of 1,900 words. Take 130 for the framing, leaving 1,770. The four prose-only aspects take 350 each, which is 1,400. The two diagram-supported aspects take 185 each, which is 370, and the totals reconcile at 1,770.
One hundred and eighty-five words next to a diagram is not padding. It is the caption an evaluator needs: what the diagram shows, which risk each labelled point represents, and what the reader should conclude from it. A flowchart submitted without that paragraph is scored as an exhibit rather than as an answer, and that is the most common way an aspect goes unmet in this course.
Documenting a system so someone else can evaluate it
The deliverables here are system documentation and evaluation. Where task directions prescribe a format, follow it. Otherwise this sequence covers what these aspects usually ask for.
| Component | What it must show | How it is judged |
|---|---|---|
| Process narrative | The cycle described step by step, naming who does what and with which document | Whether an outsider could follow the process without prior knowledge of the business |
| Process diagram | The same flow drawn, with roles separated and handoffs visible | Consistency with the narrative; a diagram that contradicts the text costs both aspects |
| Data requirements | The fields captured, where they originate and where they are stored | Whether the data needed for reporting is actually collected somewhere in the flow |
| Risk identification | What can go wrong at each step, stated as an event rather than a category | Specificity; unauthorized access as a risk is a label, not a finding |
| Control matrix | Each risk paired with a control, classified preventive, detective or corrective | Whether every identified risk has a control and every control has a purpose |
| Reporting output | What the system produces for management and for financial reporting | Whether outputs trace back to captured data rather than appearing by assumption |
| Recommendation | The improvement proposed, its cost implication and the risk it reduces | Whether the recommendation addresses a risk the document already established |
Segregation of duties deserves its own attention in whatever form the task takes. Authorization, recording and custody in three different hands is the oldest control in accounting, and a documented process that puts two of them with the same person is a finding you should name explicitly.
Precision about systems, data and terminology
Systems writing fails in a specific way: it uses words that sound technical and mean nothing in particular. Precision here is the difference between a competent evaluation and a plausible-sounding one.
- Name the actor for every step. Systems do not approve invoices; a person in a named role does, or an automated control does under stated parameters.
- Distinguish data from information. What is captured and what is reported are different, and the transformation between them is usually where the interesting risk lives.
- Classify each control by type and by whether it is manual or automated, since the audit implications differ.
- Cite frameworks and course material in APA and in paraphrase, keeping quotation minimal because submissions are similarity-checked.
- Where you diagram, use a consistent symbol set and include a legend. An inconsistent diagram is read as a misunderstanding of the process rather than as a drafting slip.
Be careful with security language too. Confidentiality, integrity and availability are distinct properties, and a control that protects one may do nothing for another. Saying that a daily backup supports availability but does nothing for confidentiality is the kind of precise sentence that earns an aspect outright.
What separates a Competent systems evaluation
Each aspect is scored on its own against the competency standard, and this course rewards documents that could actually be handed to a client.
- The narrative and any diagram describe the same process without contradiction.
- Risks are stated as events with consequences, not as abstract categories.
- Every risk has a control, every control has a type, and gaps are named as gaps rather than quietly skipped.
- Segregation of duties is assessed explicitly wherever the process involves authorization, recording and custody.
- Recommendations connect to risks already identified and acknowledge what they cost.
WGU marks work Competent or Not Competent, with no letter grade and no ordinary grade point average, and performance assessment work can be revised and resubmitted with no penalty. A return here is usually about specificity rather than knowledge, which makes it fast to fix and frustrating to receive. The real cost is calendar time inside a six-month flat-rate term.
Where the course includes a proctored objective assessment, our support is preparation only: cycle-by-cycle review, control classification drills and an honest readiness verdict. We never sit an assessment and never ask for portal credentials.
Six mistakes that recur in systems coursework
- Submitting a diagram with no explanation. The paragraph beside the diagram is what the aspect is actually scoring.
- Describing software instead of process. The course is about how transactions flow and where they can fail, not about a vendor's feature list.
- Naming risk categories instead of risks. Fraud risk is a category; a warehouse clerk who can both receive goods and adjust inventory records is a risk.
- Listing controls with no link to a risk. An unattached control cannot be evaluated for adequacy.
- Ignoring segregation of duties. It is the most frequently assessed control concept in the subject and the easiest to check in your own documentation.
- Recommending a system replacement as the answer to everything. Recommendations are judged on proportionality, and replacing a system to fix an approval gap will not read as sound.
Support that treats this as a documentation course
Send the rubric, the task directions and any process description or company scenario. The draft comes back as a documentation package: a narrative that names actors and documents at every step, a diagram consistent with the narrative, risks written as events, a control matrix with types assigned, and recommendations tied to risks already established. The walkthrough covers how to read a process for control gaps, which is the transferable skill here.
D217 connects forward to D561 Information Systems for Accounting and Control in the graduate sequence and sideways to D215 Auditing, where internal control evaluation reappears from the auditor's side of the table.
Questions students ask about D217
Is D217 the same as ACCT 3360?
Do I need programming skills for D217?
What software will I have to use?
Process documentation or control matrix due?
Send the scenario and the rubric. You get a narrative, a consistent diagram and a control matrix where every risk has an owner.
Where D217 sits in WGU's programs
The July 2026 catalog places this code in 1 current WGU program. Open a program page for the complete standard path and term positions. The live Degree Plan remains authoritative after transfer credit, substitutions, and mentor planning.
The assessments, one by one
The public catalog does not publish this course's PA/OA identity or task count. WGU Tutors publishes at most one PA manual per course and only from a WGU-controlled public rubric. Until that source exists, PA help begins from the student's real Course of Study and OA support remains preparation only.