Financial anomaly library

Sample event

{
  "finance_revenue_recognition_cutoff_days": [
    1,
    1,
    2,
    1,
    2,
    1,
    2,
    1,
    1,
    2,
    1,
    1,
    2,
    1,
    1,
    2,
    1,
    1,
    2,
    1,
    9
  ],
  "detected_value": 9
}

Stream: finance_revenue_recognition_cutoff_days · detected_value: 9

Drafted corrective-action plan

Hold period-close reporting, re-cut the revenue schedule around the actual delivery date, and document the slip for the auditor before the close locks.

1. Affected systems: Finance / Revenue — cutoff slip on the latest revenue window is 9 days past the period boundary, well above the 2-day tolerance.
2. Root-cause hypothesis: the delivery confirmation for the affected engagement posted after the period close and pulled the recognition date into the following period without an adjustment.
3. Next three steps: (1) pull the engagement-level delivery log and re-derive the recognition cutoff against the actual service date, (2) raise a manual adjusting journal to reclassify the slipped revenue into the correct period, and (3) document the cutoff exception for the auditor so the period-close evidence chain is intact before lock.

Sample event

{
  "finance_expense_capitalization_ratio": [
    0.72,
    0.71,
    0.74,
    0.73,
    0.72,
    0.71,
    0.73,
    0.74,
    0.72,
    0.71,
    0.73,
    0.72,
    0.74,
    0.73,
    0.72,
    0.71,
    0.73,
    0.74,
    0.72,
    0.71,
    0.41
  ],
  "detected_value": 0.41
}

Stream: finance_expense_capitalization_ratio · detected_value: 0.41

Drafted corrective-action plan

Re-classify the affected project costs against the capitalization policy, refresh the project tagger, and flag the deviation for the close review.

1. Affected systems: Finance / Revenue — capitalization ratio on the active capital project dropped to 0.41, well below the 0.71–0.74 policy band.
2. Root-cause hypothesis: a recent project-code reassignment routed capitalizable labour into the shared opex pool instead of the project tag, draining the capitalization ratio for the close window.
3. Next three steps: (1) pull the project's labour distribution for the close window and re-tag the capitalizable hours against the project code, (2) raise a reclassification entry that moves the slipped cost back into capex, and (3) flag the project-code routing rule for the close review so the next hit doesn't repeat the mis-tagging.

Sample event

{
  "finance_related_party_journal_count": [
    0,
    1,
    0,
    1,
    0,
    1,
    0,
    1,
    0,
    1,
    0,
    1,
    0,
    1,
    0,
    1,
    0,
    1,
    0,
    1,
    9
  ],
  "detected_value": 9
}

Stream: finance_related_party_journal_count · detected_value: 9

Drafted corrective-action plan

Hold the affected journals, request business-purpose documentation from the originator, and loop controller review before the entries post for the period.

1. Affected systems: Finance / Revenue — 9 round-dollar journals posted to related-party accounts outside business hours in the close window, well above the 0–1 daily baseline.
2. Root-cause hypothesis: a controller-side auto-post rule fired on a backdated reclass workflow that bypassed the related-party review queue during the overnight batch.
3. Next three steps: (1) hold the 9 related-party journals pending business-purpose documentation from the originating team, (2) request the audit trail behind the overnight auto-post and disable the rule for the affected account class, and (3) loop controller review into the morning close stand-up so the entries only post after sign-off.

Sample event

{
  "finance_duplicate_vendor_invoice_count": [
    0,
    0,
    1,
    0,
    0,
    1,
    0,
    0,
    1,
    0,
    0,
    1,
    0,
    0,
    1,
    0,
    0,
    1,
    0,
    0,
    6
  ],
  "detected_value": 6
}

Stream: finance_duplicate_vendor_invoice_count · detected_value: 6

Drafted corrective-action plan

Reverse the duplicate postings, run the vendor dedupe rule against the affected supplier, and tighten the AP intake checklist for the next batch.

1. Affected systems: Finance / Revenue — 6 duplicate vendor invoices for the same supplier / same amount landed in the AP queue during the close window.
2. Root-cause hypothesis: the supplier's invoicing template resubmitted the prior period's line items without an updated invoice number, so the AP intake rule did not catch the duplicate by invoice-id alone.
3. Next three steps: (1) reverse the 6 duplicate postings before the disbursement file transmits and confirm with the AP specialist, (2) repoint the AP dedupe rule to include supplier + amount + service-period as the match key, and (3) tighten the supplier onboarding checklist so the next invoice carries a unique invoice id that the rule can lock onto.

Sample event

{
  "finance_period_end_manual_journal_volume": [
    4,
    3,
    5,
    4,
    3,
    4,
    5,
    3,
    4,
    4,
    3,
    5,
    4,
    3,
    4,
    5,
    3,
    4,
    4,
    3,
    5,
    4,
    3
  ],
  "detected_value": 5
}

Stream: finance_period_end_manual_journal_volume · detected_value: 5

Drafted corrective-action plan

Cluster the late-window journals by account class, route each cluster to a dedicated reviewer, and capture an evidence note for the audit binder.

1. Affected systems: Finance / Revenue — manual journal volume in the final 3 days of the period ran 5x normal, well above the 3–5 daily cadence.
2. Root-cause hypothesis: a series of late-breaking reclassifications landed at once when the close forecast shifted, and each one became its own manual entry instead of consolidating into a single adjustment.
3. Next three steps: (1) cluster the late-window manual journals by account class so the dominant reclass theme surfaces for the close reviewer, (2) consolidate any cluster with a shared account into a single adjusting journal before lock, and (3) capture the reclass evidence note for the audit binder so the manual-journal footprint is documented in the close file.

Sample event

{
  "finance_bank_reconciliation_lag_days": [
    1,
    1,
    2,
    1,
    2,
    1,
    2,
    1,
    1,
    2,
    1,
    1,
    2,
    1,
    1,
    2,
    1,
    1,
    2,
    1,
    7
  ],
  "detected_value": 7
}

Stream: finance_bank_reconciliation_lag_days · detected_value: 7

Drafted corrective-action plan

Page the on-call owner with the reconciliation breach flagged as CRITICAL, sweep the oldest unmatched lines first, and hold the close until the cash position is settled.

1. Affected systems: Finance / Revenue — bank reconciliation lag reached 7 days, well past the 2-day close tolerance the team operates to.
2. Root-cause hypothesis: a feed outage on the bank statement side left a window of unmatched disbursements against the GL, and the reconciliation rule could not settle the lines until the feed resumed.
3. Next three steps: (1) page the on-call owner with the reconciliation lag flagged as CRITICAL before the close window transmits, (2) sweep the oldest unmatched disbursement lines first so the cash position settles ahead of the close, and (3) file a feed-availability incident with the bank so the gap is documented before the audit picks it up.