Athena — v1 Scope

Superseded scope notice. This document's v1 scope (4 finding types — kiting, unsupported_manual_journal, restricted_cash, lapping — plus 5 normal_checks, all liquide-middelen-specific) is superseded/expanded by the owner's data-audit-engine-requirements-source.md (2026-09-01). The authoritative, numbered requirements are now in srs.md, sequenced for delivery in roadmap.md. Per srs.md §3: unsupported_manual_journal merged into the new SRS's general manual- journal-entry detection (DA-013); the 5-business-day cutoff normal_check merged into the new configurable cut-off window (DA-035); kiting, restricted_cash, the bank-confirmation-letter extraction capability, and the IBAN normal_check were dropped — none has a corresponding row in the new MoSCoW table, since the new scope's Data-import section no longer lists bank-statement-PDF or bank-confirmation- DOCX ingestion as a requirement. lapping partially merged into the new Debiteuren section's subsequent-receipts matching (DA-051 per the original numbering; note: in the current srs.md DA-051 is the Memorial/Journal Entries Viewer — the subsequent-receipts matching requirement was assigned a different DA number), without carrying forward the specific cycle-detection algorithm below. The concrete EUR amounts and training-file references below remain valid and are reused as acceptance-criteria evidence throughout srs.md — only the finding-type framing around them is superseded.

Grounding

V1 scope is defined entirely by what is evidenced in the training/ground-truth dataset at /Users/sarkout/projects/prive/financial-audit/, specifically 09_verwachte_controlebevindingen.json (the ground-truth findings file) and 10_data_dictionary.json (field documentation). That JSON defines exactly two categories of expected output:

1. expected_findings — 4 specific, typed findings (F-001 through F-004), one per finding type: kiting, unsupported_manual_journal, restricted_cash, lapping.
2. normal_checks — 5 standing checks that are not tied to a single flagged instance in this dataset but describe procedures the tool must be capable of running.

Alongside these, the dataset includes a bank confirmation letter (06_standaard_bankverklaring_voorbeeld.docx) whose stated purpose (per the data dictionary) is "Extractie van saldi, faciliteiten, zekerheden en restricted cash" — extraction of balances, facilities, securities/collateral, and restricted cash. This extraction capability is in scope because it is the direct evidentiary source for finding F-003 (restricted_cash) and for one of the normal_checks (bank confirmation vs. bank account register comparison).

Everything else visible in the wider seed material — notably the 10-step methodology in Document1.docx (risk analysis, cash counts, foreign-currency review, analytical review of cash-flow trends, automated management-letter generation) — is explicitly out of scope for v1. None of those steps has a corresponding ground-truth finding or input file in this training set, so there is no acceptance bar to build or test against yet. They are noted as a possible later phase, not a v1 commitment.

v1 acceptance bar

V1 is done when Athena, run against this exact training dataset, reproduces all 4 expected findings (F-001–F-004) with matching type, source_files, and expected_detection field values, and correctly surfaces the facts needed for all 5 normal_checks. This dataset is the acceptance test, not just a design reference.

Capability 1: Kiting detection

Finding type: kiting (ground truth: F-001, severity high)

• What it detects: An internal transfer between two of the entity's own bank accounts where the receiving side is booked in the general ledger on or before the balance sheet date, but the receiving bank's actual value date (bankvaluta) falls after the balance sheet date — while the paying bank already cleared the outgoing side before year-end. This creates a window where the same cash is counted as present in two places (or, as in F-001, produces a book balance that anticipates cash not yet received at the bank), overstating year-end cash.
• Inputs required:
  • GL bank mutations (CSV, 01_auditfile_grootboek_bankmutaties.csv, or the equivalent XAF XML 02_voorbeeld_auditfile_XAF.xml) — for booking_date, document_date, manual_entry, source, debit/credit, and account.
  • Bank statement PDFs for both accounts involved (04_bankafschrift_rabobank_2025-12.pdf, 05_bankafschrift_ing_2025-12_en_2026-01.pdf) — for the actual bank-side value dates and amounts of the same transfer.
• Output/finding shape (modeled on F-001's expected_detection):

  {
    "finding_id": "string",
    "type": "kiting",
    "severity": "high",
    "source_files": ["..."],
    "logic": "human-readable explanation of the mismatch",
    "expected_detection": {
      "internal_transfer_amount": 0.0,
      "outgoing_bank_date": "YYYY-MM-DD",
      "incoming_book_date": "YYYY-MM-DD",
      "incoming_bank_date": "YYYY-MM-DD",
      "potential_overstatement_at_year_end": 0.0
    }
  }
  

• Done: Athena identifies the BNK-9001/BNK-9002 internal-transfer pair in the training data, matches it to the Rabobank outgoing entry (2025-12-30) and the ING incoming entry (bank value date 2026-01-02) in the two PDF statements, and reproduces the exact amount (EUR 50,000.00) and all three dates in F-001.

Capability 2: Unsupported manual journal entry detection

Finding type: unsupported_manual_journal (ground truth: F-002, severity high)

• What it detects: A manual journal entry (manual_entry = true, source = manual) posted to a bank/cash GL account, dated at or near year-end, that has no corresponding bank mutation to support it — i.e., it does not reconcile against the bank statement or the bank reconciliation workpaper.
• Inputs required:
  • GL bank mutations (CSV/XAF XML) — to identify manual entries on bank accounts via the manual_entry/source fields.
  • Bank reconciliation workpaper (07_bankreconciliatie_met_afwijking.xlsx) — to confirm the entry is called out as a reconciling item without underlying bank support ("Af: niet-geboekte handmatige correctie", tied to journal ID BNK-9003 in the seed data).
• Output/finding shape:

  {
    "finding_id": "string",
    "type": "unsupported_manual_journal",
    "severity": "high",
    "source_files": ["..."],
    "logic": "explanation referencing the missing bank support",
    "expected_detection": {
      "journal_id": "string",
      "amount": 0.0
    }
  }
  

• Done: Athena flags journal_id BNK-9003 (EUR 25,000.00, dated 2025-12-31, manual_entry=true, source=manual, user=directie), matching F-002 exactly.

Capability 3: Restricted cash / G-rekening detection

Finding type: restricted_cash (ground truth: F-003, severity medium)

• What it detects: A GL balance-sheet cash account whose balance is not freely available — identified either by account naming/classification in the trial balance (e.g., a G-rekening/blocked account) or by explicit restriction language in the bank confirmation letter — and therefore requires separate assessment/presentation rather than being included at face value with unrestricted cash.
• Inputs required:
  • Trial balance (03_saldibalans_voorbeeld.xlsx) — account 1120 "G-rekening", classified under "Liquide middelen beperkt beschikbaar" with a control note "Presentatie/toelichting beoordelen".
  • Bank confirmation letter (06_standaard_bankverklaring_voorbeeld.docx) — the "Geblokkeerde rekeningen" field stating "G-rekening EUR 32.500".
• Output/finding shape:

  {
    "finding_id": "string",
    "type": "restricted_cash",
    "severity": "medium",
    "source_files": ["..."],
    "logic": "explanation of why the balance is restricted",
    "expected_detection": {
      "gl_account": "string",
      "amount": 0.0
    }
  }
  

• Done: Athena cross-references trial balance account 1120 (EUR 32,500.00) against the bank confirmation letter's G-rekening line and reproduces F-003 with matching account and amount.

Capability 4: Lapping detection

Finding type: lapping (ground truth: F-004, severity high)

• What it detects: A chain of customer receipts where a payment from one customer is applied to a different (typically older) customer's outstanding invoice rather than to the paying customer's own invoice — a pattern consistent with concealing a misappropriation of receipts by continually covering old shortfalls with newer customers' cash.
• Inputs required:
  • 08_debiteurenontvangsten_lapping_scenario.csv — per the data dictionary this file carries customer, invoice, invoice_date, amount, bank_receipt_date, bank_amount, applied_to_invoice, posting_date, and an exception narrative column. The detection logic is: for each row, is applied_to_invoice an invoice number that does NOT belong to customer, and does the applied invoice belong to a customer whose own payment (received later) is in turn misapplied to a third customer's older invoice — forming a cycle.
• Output/finding shape:

  {
    "finding_id": "string",
    "type": "lapping",
    "severity": "high",
    "source_files": ["08_debiteurenontvangsten_lapping_scenario.csv"],
    "logic": "explanation of the misapplied-payment chain",
    "expected_detection": {
      "affected_customers": ["string", "..."],
      "cycle_amount": 0.0
    }
  }
  

• Done: Athena traces the 4-row chain (Klant A→INV-250901 paid by Klant B's receipt, Klant B→INV-250915 paid by Klant C's receipt, Klant C→INV-251001 paid by Klant D's receipt) and reproduces F-004's affected_customers list (Klant A, Klant B, Klant C, Klant D) and cycle_amount (EUR 10,000.00 — uniform across all 4 rows in this scenario).

Capability 5: Bank guarantee / security extraction from bank confirmation letter

• What it detects/extracts: Structured extraction of facility, guarantee, collateral/security, and restriction facts from the free-text/tabular bank confirmation letter, specifically the fields observed in 06_standaard_bankverklaring_voorbeeld.docx: Bank, entity, peildatum (reference date), IBAN, Saldo, Kredietfaciliteit, Gebruikte kredietruimte, Bankgaranties, Zekerheden, Geblokkeerde rekeningen, Bevoegde personen, Overige verplichtingen.

• Inputs required: The bank confirmation letter (DOCX).

• Output shape: A structured record per bank confirmation letter, e.g.:

  {
    "bank": "Rabobank",
    "entity": "Demo Handelsmaatschappij B.V.",
    "reference_date": "2025-12-31",
    "iban": "NL91RABO0123456789",
    "balance": 152340.25,
    "credit_facility": 100000.0,
    "credit_facility_used": 0.0,
    "bank_guarantees": [{"amount": 25000.0, "beneficiary": "verhuurder"}],
    "securities": ["Pandrecht op huidige en toekomstige vorderingen"],
    "blocked_accounts": [{"description": "G-rekening", "amount": 32500.0}],
    "authorized_persons": ["A. Directeur", "B. Controller"],
    "other_obligations": null,
    "source_file": "06_standaard_bankverklaring_voorbeeld.docx"
  }
  

  Feeds directly into Capability 3 (restricted cash) and into normal_check #3 below.

• Done: All fields listed above are correctly extracted from the training letter, in particular the EUR 32,500 G-rekening figure (feeds F-003) and the EUR 25,000 bank guarantee (which has no corresponding ground-truth finding in this dataset but must still be extracted and surfaced, since it is explicitly named as an extraction target in the data dictionary).

Capability 6: The 5 normal_checks

These are standing procedures, not single flagged instances — each must run deterministically and produce a pass/exception result with supporting data, not a single finding record.

1. IBAN-formaat controleren (IBAN format validation)

   • Input: any IBAN encountered (bank confirmation letter, trial balance account descriptions if present). Training data has NL91RABO0123456789 (Rabobank) and NL20INGB0987654321 (ING).
   • Output: pass/fail per IBAN against the Dutch IBAN structure (checksum + BBAN format), with the source document referenced.
   • Done: both training IBANs validate as well-formed.

2. Bankafschrift-eindsaldo aansluiten met grootboek na correcties (bank statement ending balance reconciles with GL after corrections)

   • Input: bank statement PDFs' stated Eindsaldo, GL account balance from the trial balance, and the bank reconciliation workpaper's adjusting items.
   • Output: reconciliation result showing GL balance, adjustments applied (e.g., the EUR -25,000 BNK-9003 backing-out entry), and resulting balance vs. bank end balance, with a match/mismatch flag.
   • Done: reproduces the reconciliation shown in 07_bankreconciliatie_met_afwijking.xlsx — GL 1100 balance EUR 177,340.25 minus the unsupported EUR 25,000 correction equals the Rabobank statement end balance of EUR 152,340.25.

3. Bankbevestiging vergelijken met bankrekeningregister (bank confirmation vs. bank account register comparison)

   • Input: bank confirmation letter extraction (Capability 5) vs. the set of bank accounts present in the GL/trial balance/XAF file (accounts 1100, 1110, 1120).
   • Output: per-account match result — is every account named in the confirmation letter present in the register and vice versa, do balances agree.
   • Done: confirms the Rabobank IBAN/account and G-rekening balance in the letter tie to GL accounts 1100 and 1120; flags absence of an ING confirmation letter in this dataset as a gap (only Rabobank's confirmation letter is provided — this is a genuine limitation of the training set that Athena's check should surface, not silently pass).

4. Negatieve banksaldi niet zonder meer salderen (do not net negative bank balances without justification)

   • Input: per-account balances from GL/trial balance.
   • Output: flag any account with a negative balance to confirm it is not being offset against a positive balance on a different account without a legal right of set-off; none of the training accounts are negative, so this check has no triggered instance in this dataset but must still execute and report "no negative balances found" rather than being silently skipped.

5. Transacties vijf werkdagen voor en na balansdatum analyseren (analyze transactions in the 5 business days around balance sheet date)

   • Input: GL bank mutations, filtered to booking/document dates within 5 business days before and after 2025-12-31 (i.e., roughly 2025-12-24 through 2026-01-07, excluding weekends).
   • Output: the list of transactions in that window with date, amount, account, manual/bank_import source flag, and description, so an auditor can review the cutoff period — this is the same window that surfaces both BNK-9001/BNK-9002 (kiting pair) and BNK-9003 (unsupported manual journal) in the training data.
   • Done: the produced window list includes BNK-9001, BNK-9002, and BNK-9003 (all dated 2025-12-30/31) as well as the ordinary bank_import entries in that date range (e.g., BNK-0107, BNK-0120, BNK-0134, BNK-0005, BNK-0084, BNK-0076).

Out of scope for v1 (explicit)

• Cash counts (kascontrole), foreign currency revaluation (vreemde valuta), general analytical review of cash flow trends, fraud-risk scoring beyond the 4 finding types above, automated management-letter drafting, and ERP/accounting-system live integrations (Exact Online, AFAS, Twinfield) — all visible in the broader methodology document (Document1.docx) found alongside the training set, but with no corresponding ground-truth finding or acceptance data in this training set.
• Any audit area outside liquide middelen (debtors, inventory, fixed assets, revenue, etc.), even though the trial balance file includes non-cash accounts (Debiteuren, Crediteuren) for context.
• Formal validation against the official XAF XSD — the sample XML is explicitly documented as "not intended as a formal validation set against an official XAF-XSD."