{"description":"Runs against the existing Financial Close **Process** item (process_type: financial_reporting, monthly) — one workflow instance per close period that operates that period's SOX key controls and is archived when the control owner's sub-certification closes the period, as the period's durable, control-indexed evidence trail; it enriches the standing Process and Control records, never recreating them. Consumes upstream: the in-scope close-cycle key-control population from the risk & control matrix — **Control** items (key_control: true, framework includes sox + coso-ic, domains includes financial_reporting_controls) produced by the *Annual ICFR Scoping & Risk Assessment* workflow and linked to this Financial Close Process — plus the prior period's carry-forward **Issue** items (aged reconciling items, approved carryovers). In scope: the close-cycle key controls operating each period — account reconciliations, management review controls, and journal-entry approval — scoped against the period-end close boundary. Named deliverables: the period IPE log, the signed account reconciliations, the completed MRC checklists, the journal-entry approval register, the control-indexed period evidence package, and the control owner's signed sub-certification (supporting the officers' Section 302 certification). Downstream handoff: the archived evidence package and control execution log stand as the sampling population for the *SOX Key Control TOD/TOE Test*; escalated potential deficiencies continue in the *Year-End Deficiency Aggregation & Severity Evaluation* (deficiency-evaluation) track. Out of scope: deficiency severity evaluation and TOD/TOE testing themselves, both of which consume this cycle's archived evidence.","edges":[{"id":"e-perform-reconciliations-execute-management-review","source":"perform-reconciliations","target":"execute-management-review"},{"id":"e-execute-management-review-approve-journal-entries","label":"No exceptions","source":"execute-management-review","target":"approve-journal-entries","whenValue":"no_exceptions"},{"id":"e-execute-management-review-resolve-exceptions","label":"Exceptions","source":"execute-management-review","target":"resolve-exceptions","whenValue":"exceptions_noted"},{"id":"e-resolve-exceptions-approve-journal-entries","source":"resolve-exceptions","target":"approve-journal-entries"},{"id":"e-approve-journal-entries-certify-and-file-evidence","source":"approve-journal-entries","target":"certify-and-file-evidence"}],"isPublic":true,"metadata":{"capabilities":[],"controlVerbs":{},"controls":["UC-FIN-02","UC-FIN-03","UC-FIN-04","UC-AUDIT-25","UC-BCDR-14"],"department":"finance","domains":["sox"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=sox-key-control-operation","contentDigest":"sha256:679d0d95a23910b4e09daa881a7f83c38e65960524b8db9d9adbae2eb08348f6","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:679d0d95a23910b4e09daa881a7f83c38e65960524b8db9d9adbae2eb08348f6","schemaVersion":1,"sourceTemplateId":"workflow-library:sox-key-control-operation"},"lineOfDefense":"operate","mappingStatus":"mapped","risks":[],"slug":"sox-key-control-operation","source":"coworkcanvas-gallery","standards":["sox","coso-ic"],"teams":["finance"]},"name":"SOX Key Control Operation (Close Cycle)","nodes":[{"data":{"description":"Complete every in-scope account reconciliation with each reconciling item investigated and explicitly dispositioned, and no reconciliation signed while an unexplained difference remains.","instructions":"**Objective**\nComplete every in-scope account reconciliation with each reconciling item investigated and explicitly dispositioned, and no reconciliation signed while an unexplained difference remains.\n\n**Inputs**\nThe **Financial Close Process** item this instance runs against (process_type: financial_reporting, monthly) — the anchor the period's evidence attaches to.\n- The in-scope close-cycle key-control population from the risk & control matrix — **Control** items (key_control: true, framework includes sox + coso-ic, domains includes financial_reporting_controls) with `frequency` and `control_owner`, each linked to the Financial Close Process and to the Risk it mitigates. This population is produced upstream by the *Annual ICFR Scoping & Risk Assessment* workflow; linked accounts, assertions and reviewer are read from the RCM.\n- The prior period's carry-forward items — open **Issue** items (issue_type: exception/observation, issue_owner, target_remediation_date) created when the prior close's certify-and-file-evidence step closed that period, and linked to their Control items: aged reconciling items, approved carryovers, controls performed late, with prior dispositions in the prior period's archived instance.\n- Each control's report specification (source system, report name, required parameters) — kept in each Control item's `description` (no dedicated field); the operative spec copy is re-attached in the IPE log.\n- The period-end close calendar and due dates — a staged document (upload) at this step; per-control cadence itself is `Control.frequency`.\n- Source-system data for the period-end pulls — trial balance, subledger detail, bank statements, journal-entry listing — pulled from the ERP/GL, subledgers and banks (outside AssureSwarm); the AssureSwarm copies are the pulled reports attached at this step.\n- Current approved reconciliation templates and MRC checklists — staged documents (upload) at this step (masters live outside AssureSwarm — no Template item type).\n\nThe staged reconciliation packages and validated source reports from the IPE log (documents on the perform-reconciliations step).\n- The reconciliation policy — a **Policy** item (policy_type: policy, policy_owner, framework includes sox), its aging thresholds, write-off limits and unexplained-difference tolerance carried in the attached policy document (zero for key accounts unless policy explicitly sets a de-minimis threshold — tolerance is a policy decision, never preparer discretion).\n- Prior-period reconciliations and their dispositions, for recurring and carried items (documents on the prior period's archived instance).\n\n**Procedure**\n*Agent retrieval, preparation and filing absorb “Prepare control package”; the responsible roles retain their judgments and all independent sign-offs within this checkpoint.*\n\n1. Assessment scope for Prepare control package: Stage every in-scope control with tied-out source data and a contemporaneous IPE record, so control execution starts from evidence that will survive audit rather than reconstructing it afterward.\n\n2. Pull each period-end report exactly per its specification, capturing IPE metadata at pull time: source system, report name, parameters (entity, period, as-of date), run timestamp, record count, and who ran it. Metadata captured after the fact is reconstruction, not evidence — contemporaneous capture is the point.\n3. Tie out every report before anything consumes it: record counts and control totals to the source system's own totals (trial balance total to the GL close balance; journal-entry listing count to the system's posted-entries count), and parameters against the specification. A wrong entity filter or an as-of date one day outside the period is a completeness failure — re-pull, don't annotate.\n4. For custom or configurable reports, confirm the report logic version: if the report definition changed during the period, note the change ticket. Baseline-plus-change-control is what lets auditors rely on a report without re-testing its query every period.\n5. Pre-populate each account's reconciliation template (GL balance, source balance, prior-period open items carried in) and each MRC checklist (thresholds, in-scope accounts, prior follow-ups); open a tracker row per control in the IPE-log/tracker and link each staged package to its Control item.\n6. Assemble the period IPE log: one row per report with its metadata, tie-out result, and the controls that consume it. One report feeding five reconciliations is one IPE validation, not five — the log is what makes that reuse defensible.\n7. The control owner verifies the IPE log — every report ties, parameters match the control definitions, run timestamps sit inside the period — and releases the packages for execution. A package released on unvalidated IPE contaminates every control that consumes it.\n\n8. Assessment scope for Perform reconciliations: Complete every in-scope account reconciliation with each reconciling item investigated and explicitly dispositioned, and no reconciliation signed while an unexplained difference remains.\n\n9. Match transactions between the general ledger and each source — subledger, bank statement, supporting schedule — on amount, date, and reference logic; compute the unreconciled difference per account. Auto-match first, hand-match the residual, and record the match rate so the reviewer sees how much judgment sits in the residual.\n10. Itemize every reconciling item with amount, direction, age (first-seen period), and classification: timing (clears in the normal course — cite the expected clear date), error (needs a correcting entry), or unidentified (nature unknown — the dangerous category).\n11. Age items against the policy thresholds: items past the aging limit (commonly 60–90 days) require escalation or a write-off proposal; unidentified items of any age require investigation this period. An \"unidentified, immaterial\" item recurring for three periods is a red flag, not a rounding note. Cross-reference recurring items to their prior dispositions — an item re-classified as \"timing\" every period without ever clearing has been misclassified.\n12. Disposition every item one of three ways: clear it (with clearing evidence), carry it (documented rationale and expected resolution date), or propose an adjustment (a correcting journal entry routed into the journal-entry approval control — never posted around it). Netting offsetting errors without investigation is prohibited: two errors that net to zero are still two errors.\n13. Sign each reconciliation as prepared only when the GL-to-source difference is fully explained by the itemized dispositions. An unexplained difference is unsignable at any size — a small net difference can hide large offsetting gross errors.\n14. Flag into the management review: any account with aged items over threshold, write-off proposals, a swing in reconciling-item count versus prior period, or anything the preparer could not fully resolve.\n\n**Record in AssureSwarm**\n**Step document** — attach the period IPE log and the staged control packages (XLSX log + package files). There is no native per-period control-operation item type, so the per-control tracker lives as the log's per-control rows on this step, not as items.\n- **Comment on Control item** — record each control's staging status and tie-out result as a comment on its **Control** item; unresolved mismatches stay as open comments on the affected Control item until cleared.\n- **Step** — the control owner's IPE-log release is recorded on this step.\n\n**Step document** — attach each completed reconciliation and its matching detail (XLSX per account); update its tracker row in the IPE-log/tracker with prepared status, preparer, sign date, open-item count and aging.\n- **Comment on Control item** — record prepared status and open-item aging as a comment on the account's **Control** item.\n- **Suggested change / comment** — proposed adjustments recorded on the account's Control item, referencing the correcting entry that routes into journal-entry approval.\n\n**Exit criteria**\nEvery in-scope control has a tracker item and a released package; the IPE log covers every report with full metadata and a passing tie-out; every mismatch is resolved or explicitly dispositioned; owner release recorded on the step. Every in-scope reconciliation attached and signed as prepared; every reconciling item classified, aged, and dispositioned; zero unexplained differences on signed reconciliations; every threshold breach escalated or carried with documented approval; MRC flags recorded.\n\n> **⚡ Audit Artist accelerator:** `/sox-python` recomputes the IPE tie-outs — record counts, control totals, period boundaries — deterministically, so the completeness checks are re-runnable instead of hand-checked.","label":"Perform reconciliations","performedBy":{"note":"","primitives":["coach-query-data","coach-document-upload","sox-python","coach-item-create","coach-items-link"]}},"id":"perform-reconciliations"},{"data":{"decisionField":"review_result","description":"Agent compiles fluctuation analyses, threshold breaches, and outlier journal entries with evidence links; human reviewer performs the MRC and records the result","formData":{"fields":[{"key":"review_result","label":"Management review result","options":[{"label":"No exceptions","value":"no_exceptions"},{"label":"Exceptions noted","value":"exceptions_noted"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Resolve whether the period's management review controls close clean or surface exceptions: the assigned reviewer performs each MRC at its documented precision, and this decision routes the close accordingly.\n\n**Decision criteria**\n\nPerform the review before deciding — the decision is only as strong as the review evidence behind it:\n\n- Work from the full analytics the control's precision requires: period-over-period and budget-versus-actual fluctuations per account with the control's thresholds applied and every breach listed; the period's outlier journal entries (manual above threshold, unexpected preparers, round-sum amounts, late postings), each tied to the account movement it drives; and the reconciliation statuses with their MRC flags.\n- Challenge every pre-drafted explanation by corroborating it against ledger or subledger detail. A narrative drafted from the data is a hypothesis until the reviewer verifies it — accepting drafted explanations unread is the classic MRC precision failure inspectors cite.\n- Evidence the review itself: which items were examined, what questions were asked, what answers were received, what follow-ups were opened. A signature without evidence of what was looked at does not demonstrate the control operated at its stated precision.\n\nBranch on the outcome:\n\n- **`no_exceptions`** — every threshold breach has a corroborated explanation that ties to underlying detail; every outlier journal entry has support and a business rationale the reviewer accepts; every reconciliation flagged into the review is resolved to the reviewer's satisfaction; no correction to the ledger is required and no open question about the period's numbers remains. Open follow-ups are acceptable only if they are process improvements, not unresolved questions about balances.\n- **`exceptions_noted`** — any single item requires correction or further investigation: a fluctuation explanation the data cannot support, an unsupported or miscoded entry, an unexplained difference, a reconciling item needing an adjusting entry, or an indicator the control itself may have failed. One unresolved item routes the whole close through exception resolution — the branch is chosen per period, not per item, and understating exceptions to keep the close on schedule defeats the control.\n\n**Record in AssureSwarm**\n- Submit the step form: `review_result` (the SELECT field driving this branch), the step result citing the specific breaches, entries, and reconciliations reviewed with their evidence references, and the step's approver record (the accountable reviewer).\n- Attach the completed MRC checklist with the review evidence — items examined, questions and answers, follow-ups opened (document upload).\n- The working review view assembled for this step (a query/dashboard putting threshold breaches, outlier entries and reconciliation statuses in one view — a step working artifact, not a published Dashboard) stays linked for the reviewer and for downstream audit.\n\n**Exit criteria** — Form submitted with a rationale naming the items reviewed and the accountable reviewer; every threshold breach carries a corroborated explanation or is captured as a noted exception; review evidence attached; the not-taken branch is prunable.","kind":"decision","label":"Execute management review","performedBy":{"primitives":["coach-query-data","coach-dashboard-create","coach-document-upload"]}},"id":"execute-management-review"},{"data":{"description":"Agent logs each exception with root-cause prompts, tracks corrections, and re-runs affected checks; human approves each resolution","instructions":"**Objective** — Convert every exception noted in the management review into a corrected, re-verified close item — root cause identified, correction landed through the proper controls, affected checks re-run clean — without restarting the whole review.\n\n**Inputs**\n- The noted exceptions from the review decision: the rationale field and the attached review evidence naming each item.\n- The reconciliations, analytics, and journal-entry detail that surfaced each exception.\n- The journal-entry policy (correcting entries route through approval) and the SOX program's deficiency-evaluation criteria.\n\n**Procedure**\n1. Open an **Issue** per noted exception (issue_type: exception, source: management_identified, severity, identified_date), linked to the Control and the evidence that surfaced it, capturing description, affected accounts, amount, and root_cause: data error, process gap, estimate revision, or possible control deficiency. Draw the critical distinction — an error the control caught is the control operating; an error the control missed (found later, elsewhere, or by chance) is a potential deficiency. That distinction drives escalation.\n2. Land each correction: a correcting journal entry (routed through the journal-entry approval control, never posted around it), an updated reconciliation, or a revised schedule — recording preparer and completion timestamp against the exception.\n3. Re-run the affected checks after each correction: the fluctuation the entry moves, the reconciliation it touches, and the threshold screens — confirming the exception clears and no new breach appears. Correcting entries commonly fix one account and break another's flux; re-check both sides of the entry.\n4. Evaluate deficiency indicators: the same root cause recurring across periods, a correction larger than the review control's precision threshold, or the control failing to detect the error at all. Escalate any of these to the SOX program owner for severity evaluation (deficiency / significant deficiency / material weakness on the likelihood-and-magnitude framework) — the evaluation itself happens in the deficiency track, but escalation from this step is mandatory, not judgmental.\n5. The reviewer approves each resolution individually — no batch approvals — confirming the re-checks are clean, then releases the close to proceed to journal-entry approval.\n6. Compile the exception resolution log: each exception, root cause, correction taken, re-check result, and approver.\n\n**Record in AssureSwarm**\n- **Item create + relationship** — one **Issue** per noted exception (issue_type: exception, source: management_identified, severity, description, root_cause, identified_date), linked to the **Control** it hit and to the source evidence.\n- **Item field update** — record correction progress and re-check result on each Issue; when a deficiency indicator fires, update the Issue's issue_type → deficiency (the severity evaluation itself runs in the downstream *Year-End Deficiency Aggregation & Severity Evaluation* track).\n- **Step document** — attach the exception resolution log (XLSX); escalations recorded as comments on the Issue naming the SOX program owner and date.\n\n**Exit criteria** — Every noted exception has an item with root cause, a completed correction, and a clean re-check; every resolution individually approved; every deficiency indicator escalated with a named owner and date; resolution log attached.","label":"Resolve exceptions","performedBy":{"primitives":["coach-item-create","coach-items-link","coach-workflow-scan","coach-query-data","coach-document-upload"]}},"id":"resolve-exceptions"},{"data":{"description":"Agent batches above-threshold journal entries with support attached and flags segregation-of-duties conflicts; human approver reviews and signs each entry","instructions":"**Objective** — Every journal entry that requires approval under the policy is explicitly signed or rejected by an authorized, independent approver with support attached, before the ledger closes.\n\n**Inputs**\n- The period journal-entry population — the validated listing from the IPE log, plus correcting entries raised during exception resolution.\n- The journal-entry policy — a **Policy** item (policy_type: policy, policy_owner, framework includes sox), its approval thresholds, sensitive-account list, and top-side and post-close rules carried in the attached policy document.\n- The segregation-of-duties matrix and delegation-of-authority limits per approver — staged documents (upload) at this step (no native SoD/DoA item type).\n\n**Procedure**\n1. Isolate the approval-required population: manual entries above the policy threshold, all top-side entries (consolidation-level entries outside the subledger flow are the classic fraud vector regardless of amount), post-close and late entries, entries to sensitive accounts (reserves, suspense, intercompany, revenue cutoff), and every correcting entry from exception resolution. Reconcile the split — selected plus exempt must equal the full listing, so no entry falls between filters.\n2. Completeness-check support per entry before routing: business rationale, supporting calculation or document, account coding, and period. Entries with missing or mismatched support return to the preparer first — routing them anyway converts the approver's signature into rubber-stamping.\n3. Screen every preparer–approver pair against the segregation-of-duties matrix and delegation-of-authority limits: self-approval (including via delegation), conflicting-duty combinations, and amounts above the approver's limit reroute upward to an independent approver. Also screen for approval-splitting — multiple related entries just under the threshold from one preparer are one economic entry; evaluate them at the combined amount.\n4. Route a batch per approver. Each approver reviews support, business rationale, and account coding, and signs or rejects every entry individually — no bulk approval without line-level review. Rejected entries return to the preparer; resubmissions re-enter the screen at step 2.\n5. Chase open approvals against the ledger-close deadline. An entry that posts before its approval is a control exception even if approved afterward — log it as one rather than backdating the review.\n6. Complete the approval register: entry id, amount, accounts, preparer, approver, decision, timestamp, and segregation-of-duties screen result per entry.\n\n**Record in AssureSwarm**\n- **Item export** — export the per-approver batches with support attached (CSV).\n- **Step document** — attach the completed approval register (XLSX).\n- **Comment on Control item** — rejections, reroutes, and any posted-before-approval exceptions recorded as comments on the affected **Control** items.\n\n**Exit criteria** — The approval-required population reconciles to the full listing; every entry in it carries an explicit sign or reject from an independent approver within their authority; zero unresolved segregation-of-duties conflicts; any entry posted before approval is logged as a control exception; register attached.","label":"Approve journal entries","performedBy":{"primitives":["coach-query-data","coach-export-package","coach-document-upload"]}},"id":"approve-journal-entries"},{"data":{"description":"Agent assembles the period evidence package indexed by control id, then archives it and seeds the next period with carry-forward items; human control owner sub-certifies the period and that signature closes the cycle","instructions":"**Objective** — Assemble a self-contained, control-indexed evidence package demonstrating each in-scope key control operated this period, secure the control owner's sub-certification over it, and close the period on that signature with the evidence archived and every open item carried forward.\n\n**Inputs**\n- Every period artifact: the IPE log, signed reconciliations, MRC checklists with review evidence and the submitted decision form, the exception resolution log (when the exceptions branch ran), and the journal-entry approval register.\n- The confirmed in-scope control population for the period — the completeness benchmark.\n- Prior-period metrics for trend comparison.\n- The open-item set: reconciling items carried with approval, unresolved review follow-ups, rejected entries not yet resubmitted.\n- The control execution log, the organization's retention schedule, and the next period's close calendar.\n\n**Procedure**\n\n_Items 6–10 close the period control cycle (folded from the former \"Close and archive\" step); the sub-certification the control owner signs at item 5 is the closure — no separate closure declaration follows._\n\n1. Index every artifact by control id and link each to its control tracker. Apply the operating-effectiveness test per control: an auditor sampling this period must find who performed it, who reviewed it where required, a date inside the close window, and the evidence itself — with performer, reviewer, and dates coming from the artifacts (signatures, form submissions, timestamps), not asserted by the index.\n2. Run the completeness check against the period scope: every control in the in-scope population maps to complete evidence. Remediate gaps before certification. A gap that cannot be remediated — the control genuinely did not operate — is disclosed in the certification as an exception, never papered over: a clean sub-certification over a known gap is a false assertion.\n3. Compute the period metrics: controls performed on time versus late, reconciling items cleared versus carried (with aging drift), exceptions raised and resolved, entries approved after the deadline. Compare to prior periods — a rising carried-item count or a growing late rate is the leading indicator external audit will ask about before you raise it.\n4. Draft the sub-certification: the owner's assertion that the listed key controls operated during the period, with the metrics and every known open item and exception disclosed. These sub-certifications support the officers' Section 302 quarterly certifications — a qualified sub-certification with disclosed items is credible; a clean one over known issues is not.\n5. The control owner reviews the package end to end, resolves or dispositions any remaining gap, and signs. That signature closes the period control cycle; items 6–10 execute it.\n6. Export the certified package and archive it in the designated evidence repository under retention controls (SOX-relevant workpapers are typically held seven years under SEC/PCAOB retention rules; the organization's retention schedule governs). Record the archive location and reference per control id, and verify retrievability by opening the archived copy — a write receipt is not a retrieval test. Post-archive corrections are new dated addenda, never edits to archived evidence.\n7. Update the control execution log with the period result, completion dates, and key metrics. This log is the population from which internal audit, SOX testers, and external audit select samples — a wrong completion date recorded here surfaces later as a testing exception.\n8. Create a carry-forward **Issue** per open item — aged reconciling items, approved carryovers, unresolved follow-ups (issue_type: exception/observation, issue_owner, target_remediation_date = due date) — each linked to its Control item and its prior-period evidence, so the next period's close cycle receives them as explicit inputs rather than tribal memory. Nothing may remain open without a tracked owner and a due date.\n9. Confirm downstream handoffs: escalated potential deficiencies continue in the deficiency-evaluation track with their owners named, and the archived package plus the execution log stand ready as source populations for SOX key-control TOD/TOE testing.\n10. Send the period closure notice to the controller and the SOX program owner: certification date, period metrics, open-item count with owners, and the archive reference. Confirm the next close is scheduled on the close calendar.\n\n**Record in AssureSwarm**\n- **Item relationship / document link** — link every period artifact to its **Control** item, indexed by `control_id`.\n- **Step document** — attach the control-indexed evidence package (bundle), the signed sub-certification statement (signed PDF), and the closure notice (DOCX/PDF). The notice doubles as the handoff pointer (archive reference + execution-log location) into the *SOX Key Control TOD/TOE Test*.\n- **Workflow instance** — export the full certified run (workflow export) as the durable audit trail; record the external retention-repository archive location and reference per `control_id` on this step.\n- **Item create + relationship** — one **Issue** per open item carried forward (issue_type: exception/observation, issue_owner, target_remediation_date = due date), linked to its **Control** item and to the prior-period evidence, so the next period's perform-reconciliations consumes them as explicit inputs.\n- **Comment on Control item** — completeness-check results recorded on this step; interim gaps tracked as comments on the affected **Control** items until resolved.\n\n**Exit criteria** — Every in-scope control shows performer, reviewer where required, an in-window date, and linked evidence; the completeness check is documented with zero unresolved gaps; metrics computed with prior-period comparison; the signed sub-certification attached with all open items disclosed; the archived package verified retrievable with a recorded reference per control id; the execution log updated with the period result; every open item existing as a carry-forward item with owner and due date; the closure notice attached.\n\n> **⚡ Audit Artist accelerator:** `/coach-render-package` assembles the control-indexed evidence package from the linked artifacts into a single reviewable bundle for the owner's sign-off, and renders the period closure notice from the same source records.","label":"Certify and file evidence","performedBy":{"primitives":["coach-document-upload","coach-query-data","coach-render-package","coach-workflow-export","coach-item-create"]}},"id":"certify-and-file-evidence"}],"sourceTemplateId":"workflow-library:sox-key-control-operation"}