{"description":"Each cycle runs as a workflow instance attached to the EXISTING financial-reporting Process item (process_type=financial_reporting) that represents financial-systems transaction processing; the four unified controls it operates (UC-FIN-06 through UC-FIN-09) are EXISTING Control items linked to that Process — enrich them, never recreate them. A decision-aware workflow covering input-control queue clearance and configuration revalidation, automated-processing exception disposition and configuration-change approval, interface reconciliation and failure resolution, and system-generated report validation and baselining. It consumes the prior cycle's carry-forward open items (Issue items created when that cycle's evidence package was certified and closed, linked to their Control) as this cycle's scope. In scope each cycle: every in-scope input control, automated processing control, interface, and relied-upon standard report for the cycle window, with change-flagged items retested and prior-cycle carryovers carried forward. The named deliverable is the control-indexed cycle evidence package with the owner's signed certification statement. There is no downstream workflow — the workflow is terminal and self-seeding: the open items this cycle discloses become carry-forward Issue items that seed the next run of this same cycle on the same Process.","edges":[{"id":"e-review-processing-exception-reports-approve-processing-configuration-change","label":"Configuration change required","source":"review-processing-exception-reports","target":"approve-processing-configuration-change","whenValue":"config_change_required"},{"id":"e-review-processing-exception-reports-certify-and-file-evidence","label":"No configuration change","source":"review-processing-exception-reports","target":"certify-and-file-evidence","whenValue":"resolved_no_config_change"},{"id":"e-approve-processing-configuration-change-certify-and-file-evidence","source":"approve-processing-configuration-change","target":"certify-and-file-evidence"},{"id":"e-reconcile-interface-transfers-resolve-interface-and-output-failures","label":"Failures identified","source":"reconcile-interface-transfers","target":"resolve-interface-and-output-failures","whenValue":"failures_identified"},{"id":"e-reconcile-interface-transfers-certify-and-file-evidence","label":"Reconciled clean","source":"reconcile-interface-transfers","target":"certify-and-file-evidence","whenValue":"reconciled_clean"},{"id":"e-resolve-interface-and-output-failures-certify-and-file-evidence","source":"resolve-interface-and-output-failures","target":"certify-and-file-evidence"},{"id":"e-baseline-and-revalidate-standard-reports-certify-and-file-evidence","source":"baseline-and-revalidate-standard-reports","target":"certify-and-file-evidence"}],"isPublic":true,"metadata":{"capabilities":[],"controlVerbs":{},"controls":["UC-FIN-06","UC-FIN-07","UC-FIN-08","UC-FIN-09"],"department":"finance","domains":["sox"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=sox-financial-systems-transaction-integrity-monitoring","contentDigest":"sha256:8bb0b7cccad61b8cb4ef25c21e62649e2f2dc93983cdd11756dcf9ef0fdbd10a","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:8bb0b7cccad61b8cb4ef25c21e62649e2f2dc93983cdd11756dcf9ef0fdbd10a","schemaVersion":1,"sourceTemplateId":"workflow-library:sox-financial-systems-transaction-integrity-monitoring"},"lineOfDefense":"operate","mappingStatus":"mapped","risks":[],"slug":"sox-financial-systems-transaction-integrity-monitoring","source":"coworkcanvas-gallery","standards":["sox","soc2"],"teams":["finance","it"]},"name":"Financial Systems Transaction Integrity Monitoring","nodes":[{"data":{"decisionField":"exception_disposition","description":"Agent compiles exception, error, and edit reports from automated processing controls with proposed disposition; human reviewer dispositions each and decides whether a configuration change is required","formData":{"fields":[{"key":"exception_disposition","label":"Exception disposition","options":[{"label":"Resolved, no configuration change","value":"resolved_no_config_change"},{"label":"Configuration change required","value":"config_change_required"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Reach a documented disposition for every exception, error, and edit report the cycle's automated processing controls generated — system-enforced calculation failures, three-way match mismatches (purchase order, receipt, invoice), tolerance breaches — and decide whether resolution stays inside the current configuration or requires a control-setting change. The processing-control reviewer owns the call. (UC-FIN-07)\n\n**Decision criteria**\n\nBefore branching, verify the exception population itself: the reports' run parameters cover the full cycle window and every in-scope processing control, and exception counts tie to the systems' own totals — exception reports are system-generated information, so a wrong date range here invalidates the entire review. Confirm every exception carries its transaction, the rule that fired, and the variance amount, and that recurring types are cross-referenced to prior-cycle dispositions. Treat zero-exception controls with suspicion: confirm from the configuration revalidation that the rule is still active — a control that never fires may be disabled, or tolerated so wide it cannot fire.\n\n- **Resolved, no configuration change (`resolved_no_config_change`)** — every exception has a documented disposition executed within existing settings: timing differences confirmed self-cleared, data errors corrected at source and reprocessed through the control, genuine processing errors corrected with root cause addressed. No pattern recurs beyond the policy's acceptable frequency, and nobody is proposing a tolerance, match-rule, or calculation change. In-progress corrective actions qualify only with a named owner and date in the register.\n- **Configuration change required (`config_change_required`)** — any of: a pattern recurs past the recurrence threshold (a workable default: the same exception type in three consecutive cycles, or touching more than roughly 2% of the control's transactions); a tolerance is demonstrably mis-set — flooding the queue with immaterial variances (too tight) or, worse, evidence that a material variance passed unflagged (too loose); or any disposition requires altering a system-enforced calculation, match rule, or threshold. Name each candidate control with current and proposed setting and the exceptions driving it — the approval step sizes its simulation from that list.\n\n**Record in AssureSwarm**\n- Attach the exception register with per-item dispositions and the configuration-change candidate list (document upload).\n- Submit the decision form: `exception_disposition` (the branch), the step result with exception counts by root-cause category — and, on the change branch, the named controls with current and proposed settings — and the step's approver record.\n\n**Exit criteria** — Form submitted; every exception in the register has a disposition or a named owner and date; rationale counts reconcile to the register; the population-completeness check is documented; the not-taken branch is prunable because the taken branch fully describes the remaining work.","kind":"decision","label":"Review processing exception reports","performedBy":{"primitives":["coach-query-data","coach-document-upload","coach-form-fill"]}},"id":"review-processing-exception-reports"},{"data":{"description":"Agent packages the proposed processing-control configuration change with before/after settings and a transaction-history simulation; human approver reviews and signs the change before it goes live","instructions":"**Objective** — Put every proposed change to a system-enforced calculation, three-way match rule, or tolerance check through independent, evidenced approval — backed by a transaction-history simulation quantifying what the new setting would and would not catch — before anything goes live. Runs only when the exception review selects the configuration-change branch. (UC-FIN-07)\n\n**Inputs**\n- The configuration-change candidates from the exception review: control, current setting, proposed setting, and the driving exception pattern.\n- Transaction history for each affected control — at least one full processing cycle; 90 days is a sensible floor for tolerance changes.\n- The financial-systems change-management policy — the existing Policy item (policy_type: policy, policy_owner) governing configuration changes: required approvals, segregation rules, promotion windows, back-out requirements.\n\n**Procedure**\n1. Build a change request per candidate: current setting, proposed setting, the exception pattern driving it, expected effect on future processing, and the financial-statement assertions the control supports — an approver who cannot see what the control protects cannot approve intelligently.\n2. Simulate the proposed setting against the transaction history and report both directions: the exceptions the change would have prevented (the benefit) and any genuine error it would now pass silently (the cost). A tolerance widening that would have suppressed even one true error fails as proposed — narrow it, or pair it with a documented compensating detective review before resubmitting.\n3. Screen segregation of duties: requestor and approver are different people; the approver is independent of the process that generated the exception pattern; the implementer (system owner or IT) is separate from both where policy requires. Approval must be dated before implementation — a retroactive approval is a change-management deviation, not an approval.\n4. Route each request with its simulation to the independent approver. Rejected changes return to the exception reviewer for an alternative disposition (a compensating manual review, a source-data fix); approved changes get a scheduled promotion window and a back-out plan agreed with the system owner.\n5. Do not update the configuration baseline here. The implemented change lands on the configuration-change log, which flags the control for mandatory retest in the next cycle's revalidation — only that retest confirms the new baseline.\n\n**Record in AssureSwarm**\n- Create an Issue (issue_type: observation, source: self_assessment, issue_owner, identified_date, target_remediation_date) per proposed change, capturing the before and after settings in its description — there is no native Change Request type, so the before/after detail lives in the description and the attached simulation — and link it Issue ↔ Control to the affected Control item.\n- Attach the simulation results, the segregation-of-duties screen, and the approval routing (document upload).\n- Record each approver sign-off or rejection on this step, with the promotion schedule for approved changes.\n\n**Exit criteria** — Every candidate is signed or rejected by an independent approver; each simulation quantifies both prevented exceptions and suppressed genuine errors; the segregation screen shows no unresolved conflict; approved changes have promotion windows and back-out plans; rejected changes are back with the reviewer with an alternative-disposition owner.","label":"Approve processing configuration change","performedBy":{"primitives":["coach-item-create","coach-query-data","coach-document-upload","coach-items-link"]}},"id":"approve-processing-configuration-change"},{"data":{"decisionField":"interface_status","description":"Agent runs record-count, control-total, or hash-check reconciliation at every interface with automated alerting on breaks; human reviews the results and decides whether failures need investigation","formData":{"fields":[{"key":"interface_status","label":"Interface reconciliation status","options":[{"label":"Reconciled clean","value":"reconciled_clean"},{"label":"Failures identified","value":"failures_identified"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Determine whether every in-scope interface's transfers for the window reconciled completely and accurately and every output was delivered per specification, so the cycle proceeds straight to report validation or routes failures to resolution. The interface control owner decides on the full reconciliation results. (UC-FIN-08)\n\n**Decision criteria**\n\nVerify four things per interface before branching: (1) its documented reconciliation method actually ran for the window — record counts prove row-level completeness, control totals (amount or hash totals) prove accuracy, hash checks prove content integrity; a method downgrade, such as counting rows where the specification calls for control totals, is not a clean reconciliation; (2) exactly-once delivery — sequence numbers or batch ids show no duplicate and no dropped transmission; (3) the automated alerting log shows an alert for every break found — a break this review caught that the alert missed is a monitoring failure to route to resolution even when the numbers now tie; (4) output delivery met its documented timing window, format, and destination.\n\n- **Reconciled clean (`reconciled_clean`)** — 100% of in-scope interfaces reconciled with their documented method and zero unexplained differences; documented timing items qualify only when itemized to specific in-transit transactions and confirmed cleared on re-check; zero duplicates or drops; alerting verified operational; every delivery in specification. An interface that could not be reconciled this window — job failed, data unavailable — disqualifies this branch: unreconciled counts as failed, never as unknown.\n- **Failures identified (`failures_identified`)** — any unexplained count, total, or hash difference of any size (interface breaks are not materiality-screened at this gate: a small systematic break can net off large offsetting errors), any duplicate or dropped transmission, any alert that failed to fire on a real break, or any delivery outside its timing, format, or destination specification. Itemize failures by interface with amounts and missed specifications in the rationale — the resolution step sizes its work from those counts.\n\n**Record in AssureSwarm**\n- Build or refresh the interface reconciliation dashboard — per interface: method, result, delivery status — and attach the detailed reconciliation output (document upload).\n- Submit the decision form: `interface_status` (the branch), the step result with interfaces reconciled n-of-n and failures itemized by interface, and the step's approver record.\n\n**Exit criteria** — Form submitted; every in-scope interface shows a documented method and result on the dashboard; the rationale ties to the dashboard; the alert-log cross-check is documented; the not-taken branch is prunable.","kind":"decision","label":"Reconcile interface transfers","performedBy":{"primitives":["coach-query-data","coach-dashboard-create","coach-document-upload","coach-form-fill"]}},"id":"reconcile-interface-transfers"},{"data":{"description":"Agent logs each interface or delivery failure with root-cause prompts and tracks the fix to a clean re-run; human approves each resolution before output is relied upon","instructions":"**Objective** — Take every reconciliation break, transmission fault, alerting miss, and delivery failure to a root-caused fix proven by a clean re-run reconciliation — or to a documented escalation as a deficiency candidate — so no unreconciled or undelivered transfer carries forward silently. (UC-FIN-08)\n\n**Inputs**\n- The failures itemized in the reconciliation decision: interface, break amount or missed specification, and the reconciliation evidence that surfaced each one.\n- Interface specifications: mapping documents, job schedules, delivery specifications, and the exactly-once mechanism (sequence numbers, batch ids).\n- The financial-systems change-management policy — the same existing Policy item — for any fix that alters a mapping or job.\n\n**Procedure**\n1. Open a failure item per break or miss, linked to the interface and the reconciliation evidence. Quantify it — records and amount affected — and establish direction: missing at the target versus extra at the target, because direction determines the fix (retransmit versus reverse).\n2. Assign root cause from the standard taxonomy: timing cutoff (transactions in flight at the window edge), mapping or transformation error, job or network failure, destination-system rejection, duplicate submission, source-side extract defect. \"Unknown\" is not a closable root cause.\n3. Execute each fix with its hazard controls. Retransmissions first establish what portion of the original batch already posted — naively re-running a partially processed batch double-posts. Mapping and transformation fixes are configuration changes: they go through change-management approval before promotion and land on the change log for next-cycle retest. Manual re-keying is last resort and requires a second person's independent verification against source.\n4. Re-run the interface's documented reconciliation after each fix — the same record-count, control-total, or hash method must tie exactly, and delivery must be confirmed at the destination in the specified format and window. A fix without a clean re-run is an open failure.\n5. Where the automated alert failed to fire, fix the alerting and evidence a test alert — closing the data break while leaving the detective alert broken repairs one failure and hides the next.\n6. Assess downstream contamination: if unreconciled data already fed the general ledger or a completed close, notify the controller or close owner for a correction assessment. Escalate repeat failures on the same interface across cycles, or design gaps such as no exactly-once guarantee, to the SOX program owner as deficiency candidates.\n\n**Record in AssureSwarm**\n- Create an Issue (issue_type: exception, source: management_identified, root_cause, issue_owner) per failure with its fix and fixer identity recorded, and link it Issue ↔ Control to the owning interface control (UC-FIN-08) — there is no native Interface item, so the Control item is the link target.\n- For repeat cross-cycle failures or design gaps, create a deficiency-candidate Issue (issue_type: deficiency, source: self_assessment) linked to the same Control, and note the escalation in a step comment.\n- Attach the failure resolution log and each clean re-run's reconciliation output (document upload).\n- Record the control owner's per-failure approval on this step.\n\n**Exit criteria** — Every failure item shows root cause and either an executed fix with a tying re-run and confirmed delivery, or a documented escalation with an owner; alerting gaps retested with evidence; downstream-contamination assessment documented where reliance already occurred; the owner approved each resolution individually.","label":"Resolve interface and output failures","performedBy":{"primitives":["coach-item-create","coach-items-link","coach-workflow-scan","coach-query-data","coach-document-upload"]}},"id":"resolve-interface-and-output-failures"},{"data":{"description":"Agent traces every relied-upon report, query, and spreadsheet to source data, verifies logic, parameters and totals, and compares each standard report's current definition to its retained baseline; human owner confirms each report fit for reliance and accepts the re-baselines with their retained validation evidence","instructions":"**Objective** — Establish with evidence that every report, query, and spreadsheet relied upon this cycle is complete and accurate — source traced, logic and parameters verified against specification, totals independently recomputed — and keep a current baseline for every standard report so a future cycle can rely on an unchanged report without revalidating from scratch; the human moment is the owner's fit-for-reliance confirmation and acceptance of each re-baseline. (UC-FIN-09)\n\n**Inputs**\n- The information-requirements catalog: the data definition and specification for each relied-upon report, query, and spreadsheet — including the reports that fed this cycle's exception review and interface reconciliation, and any financial-reporting deliverable.\n- Source-system access sufficient to re-derive counts and totals independently of the report under test.\n- The cycle window and each report's exact run parameters.\n- The standard-report baseline registry: per report — source, logic, parameters, layout, owner, baseline date, and the pointer to retained validation evidence.\n- The configuration-change log and report-definition version history since each report's last baseline.\n\n**Procedure**\n_Items 1–6 are agent-run (folded from the former \"Validate system-generated reports\" step); the human moment is the owner's fit-for-reliance and re-baseline acceptance at item 11._\n1. Trace each report's data to its origin system and confirm the population parameters — entity, date range, status filters — match both the specification and this cycle's window. A correctly built report run with last month's date range is wrong information however clean it looks.\n2. Verify logic at the definition level, not the output level: for queries, read the actual filter and join logic; for spreadsheets, verify formulas and ranges — the classic failure is a SUM or lookup range that stops at row N while the data now extends past it — and confirm no hardcoded value overrides a formula cell.\n3. For spreadsheets, confirm the end-user-computing basics: version identified, access restricted, input cells segregated from formula cells.\n4. Capture the exact parameters used for this run (a parameter-screen export or equivalent) so a reviewer can reproduce the run.\n5. Recompute independently: re-derive record counts and key totals at source and tie them to the report's outputs. Ties must be exact — an \"immaterial\" unexplained difference in a completeness check is still an unexplained difference, because you cannot know what it conceals without explaining it.\n6. Classify every gap: a one-time data issue is corrected, re-run, and re-tied; a report-definition defect routes through change management for correction — and every control that relied on the defective report in prior cycles is flagged for impact assessment, because bad information means those control operations may not have covered their populations.\n7. Compare each standard report's current definition — source tables, logic, parameters, layout, owner — against its retained baseline. Detect change from the definition itself (version, modification date, definition hash where available), never from the output looking familiar: identical-looking output from changed logic is exactly the failure baselining exists to catch.\n8. Apply the conditions that void a baseline beyond direct edits: a change to the underlying source schema, or a failure this period in the controls that protect report definitions (change management or access over the reporting environment). Baselining is defensible only while the definition provably could not have changed unnoticed — the same condition that lets auditors benchmark automated controls. If those controls failed this window, treat all baselines as void and revalidate from scratch.\n9. For each changed or voided report, assemble the revalidation package: the prior baseline, exactly what changed, and this cycle's validation result from items 1–6, so the reviewer sees the delta instead of re-deriving it.\n10. For unchanged reports, confirm two things: the retained baseline evidence is actually retrievable (open it — do not trust the pointer), and the baseline age is inside the policy's maximum revalidation interval — an annual full revalidation is the common ceiling even with no change detected.\n11. The report owner confirms each report fit for reliance and accepts each revalidation; re-baseline only then, with the new baseline record citing the evidence package and the cycle date so it becomes the comparison point for the next cycle.\n\n**Record in AssureSwarm**\n- Attach the report validation log — per report: source trace, captured parameters, logic check, totals tie-out — as the XLSX workpaper on this step (document upload).\n- Attach the retained validation evidence packages, indexed by report name and cycle date.\n- Update the standard-report baseline registry — the living document carried on this step from cycle to cycle (there is no native Report/IPE item type) — per report with baseline date, evidence pointer, and what changed.\n- Record each flagged gap's classification and its resolution or escalation owner; for a report-definition defect, create an Issue (issue_type: deficiency, source: self_assessment, issue_owner) linked Issue ↔ Control to each Control that relied on the defective report in prior cycles.\n- Record the owner's fit-for-reliance confirmation and re-baseline acceptance per report on this step.\n\n**Exit criteria** — Every relied-upon report has a documented trace, captured parameters, verified logic, and an exact independent tie-out; every gap is classified with a resolution or named owner; prior-cycle reliance impact assessed for definition defects; every standard report is either confirmed unchanged with retrievable baseline evidence inside the policy age, or revalidated and re-baselined with an accepted evidence package; the environment-control condition for baselining is assessed and documented; the owner confirmed each report fit for reliance before use and the registry is current for the next cycle.\n\n> **⚡ Audit Artist accelerator:** `/sox-python` — scripts the independent recount and totals tie-out against source so every recomputation is deterministic and reproducible by a reviewer.","label":"Baseline and revalidate standard reports","performedBy":{"primitives":["coach-query-data","coach-item-create","coach-document-upload","coach-item-update","sox-python","coach-items-link"]}},"id":"baseline-and-revalidate-standard-reports"},{"data":{"description":"Revalidate every in-scope input control's configuration against its policy baseline, assemble the cycle evidence package indexed by unified control (UC-FIN-06 through UC-FIN-09), and secure the owner's certification with every open item disclosed — that signature is the closure; the package is then archived and the open items seed the next cycle.","instructions":"**Objective**\nRevalidate every in-scope input control's configuration against its policy baseline, assemble the cycle evidence package indexed by unified control (UC-FIN-06 through UC-FIN-09), and secure the owner's certification with every open item disclosed — that signature is the closure; the package is then archived and the open items seed the next cycle.\n\n**Inputs**\nThe in-scope input controls — the existing Control items for UC-FIN-06 and the system-level input controls (linked to the anchor Process, carrying control_id, control_owner, frequency) — and their reject and suspense locations in the source systems: interface error queues, batch input error reports, GL suspense accounts, EDI reject files.\n- The input-control policy's clearance thresholds — read from the existing Policy item that governs input controls (policy_type: policy, policy_owner, framework carrying sox|soc2), enriched as a reference input never recreated (usable defaults where the policy is silent: routine rejects cleared within 5 business days; anything at 30+ days escalates to the control owner's manager; suspense balances substantiated to zero or itemized at every period-end).\n- Prior-cycle carryover items — the open Issue items raised when the prior cycle was certified and closed (issue_type: exception, source: management_identified) with their original queue-entry dates, linked to their Control items.\n\nLive configuration of every in-scope input control (edit/validation rules, required-field and format enforcement, duplicate checks, batch and completeness controls, override and bypass roles) and the window's override and bypass log.\n- Configuration baseline records (expected setting per rule per system), change-flagged items from the configuration-change log, and the queue procedure's miscalibration escalations with their example transactions.\n- Every other cycle artifact — queue clearance log, exception register with approved configuration changes, interface reconciliation dashboard and failure resolution log, report validation log, standard-report baselines — plus the confirmed cycle scope as completeness yardstick and the prior cycle's certification and metrics.\n- The evidence repository, the SOX evidence-retention policy (seven years is the common horizon), and the next cycle's review calendar.\n\n**Procedure**\n*Agent retrieval, preparation and filing absorb “Clear rejected-input and suspense queue”; the responsible roles retain their judgments and all independent sign-offs within this checkpoint.*\n\n1. Assessment scope for Clear rejected-input and suspense queue: Work every rejected-input and suspense item across the in-scope systems to a documented disposition — corrected and resubmitted, returned to source, cancelled as duplicate, or explicitly carried with an owner and target clearance date — so failed edits never age into silent write-offs. (UC-FIN-06)\n\n2. Pull every queue in scope and prove each pull complete: the extract row count ties to the system's live queue count at the extraction timestamp. Capture per item the failing check (edit, validation, required-field, format, completeness), the source transaction, the amount, and the queue-entry date.\n3. Age every item against the clearance thresholds, keeping carryovers on their original dates. Items above the posting-approval limit or process materiality are worked individually regardless of age.\n4. Categorize root cause per item: source data error, format mismatch, duplicate submission, master-data gap (missing vendor, customer, or account), or control miscalibration — a valid transaction the check wrongly rejected. A cluster from one source system or interface usually means one upstream defect, not many independent data errors; fix the defect once and resubmit the cluster.\n5. Disposition each item: corrections are resubmitted through the same edit and must pass it — force-posting around a failed check defeats the control and is a reportable deviation, not a workaround; returns to source name the defect; confirmed duplicates are cancelled with the surviving document referenced; write-offs require approval per the delegation of authority. The same item resubmitted repeatedly without passing is an unfixed root cause, not progress.\n6. Escalate every suspected miscalibration with the offending rule and example transactions — the configuration revalidation that runs inside the certification step evaluates it, and the check is never retuned from inside this step.\n7. Give anything not cleared by cycle end a named owner and target clearance date, and flag high-value items that will sit across a period-end to the close owner: unsubstantiated suspense at close is a misstatement risk, not housekeeping.\n\n8. Assessment scope for Certify and file evidence: Revalidate every in-scope input control's configuration against its policy baseline, assemble the cycle evidence package indexed by unified control (UC-FIN-06 through UC-FIN-09), and secure the owner's certification with every open item disclosed — that signature is the closure; the package is then archived and the open items seed the next cycle.\n\n9. Diff each input control's live settings against its baseline rule by rule, recording expected versus observed per deviation. The ones that matter: a check disabled, a threshold or tolerance loosened, a required field made optional, a new role granted override or bypass. (UC-FIN-06)\n10. Retest every change-flagged control rather than diffing it: submit negative-test inputs that must fail (missing required field, out-of-format date, duplicate document number, out-of-balance batch), confirm rejection, then a valid record and confirm acceptance. Use benign test data per policy and capture both responses; an uncaptured response is not a retest.\n11. Review the override and bypass log: every override needs an authorized user and a documented reason. Unlogged or self-approved overrides are deviations however the configuration reads.\n12. Evaluate the queue procedure's miscalibration escalations against their example transactions. A genuinely mis-set rule becomes a configuration-change candidate on the same independent-approval path as other control changes — the baseline updates only after approval and retest, never as a side effect of this review.\n13. Classify every deviation: an approved change (ticket exists, approval predates the change) updates the baseline record citing the ticket; unauthorized drift gets a remediation owner with the who, when and how captured, and the change-management bypass is logged as a deficiency candidate in its own right: drift and a broken change process are two different failures.\n14. Index the package by unified-control id, linking each artifact to its control item: queue clearance and configuration revalidation under UC-FIN-06; exception dispositions and configuration-change approvals under UC-FIN-07; interface reconciliations and failure resolutions under UC-FIN-08; report validations and baselines under UC-FIN-09.\n15. Check completeness against scope: every in-scope input control, processing control, interface and standard report shows a result, a named reviewer and linked evidence. Remediate or explicitly disposition every gap before certification — certifying over a silent gap turns an evidence gap into a false assertion.\n16. Compute cycle metrics against the prior cycle: rejects cleared versus carried and the carryover aging profile; exceptions dispositioned and configuration changes approved; interfaces clean versus failures resolved; reports validated or re-baselined. A rising carryover age or repeat-failure interface is a trend the certification discloses, not smooths over.\n17. Draft the certification statement: the owner's assertion that the input, processing, interface and reporting-information controls operated for the window, with the metrics and every open item listed with owner and target date.\n18. The finance systems controls owner reviews the package, resolves or explicitly accepts each disclosed item, and signs — inside the policy window after cycle end (five business days is a common ceiling) so the assertion stays contemporaneous. This signature closes the cycle; the remaining items file it.\n19. Export and archive the certified package in the evidence repository under retention controls, recording the archive location per unified-control id. Verify retrievability by opening at least one artifact back out — a pointer that resolves is the test, not the upload confirmation. Post-archive corrections are dated addenda alongside the original; the archived package is never reopened.\n20. Update the control execution log with the cycle's result, completion dates and key metrics per control — this log is the population samplers draw from; a cycle missing from it is an unoperated control to a tester.\n21. Create a carry-forward item per open item disclosed — aged suspense entries, configuration changes awaiting next-cycle retest, unresolved interface failures, reports pending revalidation — each with a named owner and due date, seeding the next cycle's scope.\n22. Confirm the next cycle is scheduled (the daily or weekly cadence run, or the change trigger armed on the configuration-change log) and send the closure note with metrics and carryovers to the SOX program owner.\n\n**Record in AssureSwarm**\nAttach the queue clearance log — every item with failing check, root-cause category, disposition, and age — as the XLSX workpaper on this step (document upload).\n- Create an Issue (issue_type: exception, source: management_identified, issue_owner, identified_date, target_remediation_date) for each aged or above-limit entry, and link it Issue ↔ Control to the owning input control's Control item (UC-FIN-06).\n- Note miscalibration escalations in a step comment naming the affected rule.\n\nAttach the configuration revalidation report: per-control baseline comparison, retest evidence with inputs and captured system responses, and the override-log review (document upload).\n- Update the baseline registry — the versioned document on this step (there is no native Configuration Baseline item type) — for each control whose new setting is confirmed approved, citing the change ticket.\n- Create an Issue (issue_type: deficiency, source: self_assessment, issue_owner) per unauthorized drift and per change-management bypass, and a carry-forward Issue (issue_type: exception, source: management_identified, issue_owner, identified_date, target_remediation_date) per disclosed open item — each linked Issue ↔ Control to the relevant Control item; the carry-forwards are the next run's scope input, and remediation owners go in a step comment.\n- Link every artifact-bearing Issue to its UC-FIN Control item.\n- Attach the control-indexed evidence package, the signed certification statement (PDF), and the closure record with archive locations per control id and the retrieval-check result.\n- Record the certification as this step's approval — it is the closure declaration; no separate confirmation is recorded. The closed, archived workflow instance on the anchor Process is itself the control-execution-log entry samplers draw from; note the closure summary in a step comment.\n\n**Exit criteria**\nQueue-pull completeness evidenced per system; every item dispositioned or carried with owner and target date; zero force-posts around failed edits; miscalibration candidates escalated with example transactions; period-end-spanning high-value items flagged to the close owner. Every in-scope input control has a baseline-comparison result and every change-flagged control pass/fail retest evidence with captured responses; every deviation classified approved (baseline updated) or unauthorized (owner named, bypass logged); the package covers 100% of scope with no unexplained gaps; metrics computed against the prior cycle; every open item disclosed with owner and target date and carried forward as an Issue; certification signed inside the policy window and recorded here; package archived with per-control locations and a passed retrieval check; execution log updated and next cycle scheduled.\n\n> **⚡ Audit Artist accelerator:** `/coach-render-package` — renders the control-indexed evidence package and its linked artifacts into one reviewable deliverable for the certifier.","label":"Certify and file evidence","performedBy":{"note":"","primitives":["coach-document-upload","coach-query-data","coach-render-package","coach-items-link","coach-item-update","coach-item-create","coach-workflow-export"]}},"id":"certify-and-file-evidence"}],"sourceTemplateId":"workflow-library:sox-financial-systems-transaction-integrity-monitoring"}