Run an audit

historical exports ──▶ storage tables ──▶ Audit Findings (reconcile table)
                                                 │
                                            one task per check
                                                 │
                                          findings + evidence ──▶ review ──▶ xlsx report

ap_ledger:          invoice_id, vendor_id, invoice_number, invoice_date,
                    posting_date, amount_net, amount_gross, currency,
                    po_number, cost_center, entity, payment_status
vendor_master:      vendor_id, vendor_name, tax_id, bank_iban,
                    bank_last_changed, parent_vendor_id, entity
payment_runs:       run_id, run_date, invoice_id, amount_paid, entity
credit_notes:       credit_id, vendor_id, credit_number, amount,
                    issue_date, applied_to_invoice_id, status
contracts (opt.):   vendor_id, article_or_service, agreed_price, unit,
                    valid_from, valid_to

# SOP — AP leakage audit (read-only lookback)

Version 1.0 · Owner: Controlling · Last approved by: <name>, <date>

## Purpose
Investigate a historical AP population for recoverable money and control
failures. Report findings with evidence. This is a READ-ONLY audit: never
propose a posting, never modify a record, never contact a vendor.

## Scope
The period loaded into the project's storage tables. State the exact date
range and row count in every finding report so results are reproducible.

## Output format — every finding, without exception
| Field               | Content                                          |
|---------------------|--------------------------------------------------|
| check               | Which check below produced this                  |
| finding             | One sentence: what is wrong                      |
| row_references      | Every source row id involved — never summarize   |
| amount              | Money at stake, with currency                    |
| confidence          | high / medium / low, with the reason             |
| recommended_action  | What a human should do next                      |

A finding without row references is not a finding. If you cannot point at
the rows, report it as an observation and mark confidence low.

## Check 1 — Exact duplicates
Same vendor + same invoice number → duplicate. Same vendor + same amount
+ same invoice date, different invoice number → duplicate.
Evidence required: both invoice_ids, both payment statuses, amount.
Report paid duplicates and unpaid duplicates separately — only the paid
ones are recoverable.

## Check 2 — Near duplicates
Same vendor + same amount, invoice dates within 10 days, different
invoice number. Also flag same amount + same PO across different invoice
numbers.
Evidence required: both rows, the date gap, the PO if present.
Confidence is never high here. Recurring identical charges (rent,
subscriptions, retainers) are normal — check whether the pair repeats
monthly before flagging, and say so.

## Check 3 — Cross-entity duplicates
The same invoice paid by two entities, or by a parent and a subsidiary.
Match on vendor tax_id (NOT vendor_id — the same vendor has different ids
per entity) + invoice number, or tax_id + amount + date window.
Evidence required: both entity codes, both vendor_ids, the shared tax_id.
This check finds money the single-entity checks structurally cannot.

## Check 4 — Unapplied credit notes
Credit notes with status open, or with no applied_to_invoice_id, where the
vendor has since been paid.
Evidence required: credit_id, amount, issue date, age in days, and the
payments made to that vendor after the issue date.
Sort by age. A two-year-old open credit is a different conversation from
a two-week-old one.

## Check 5 — Bank detail changes near a payment run
Any vendor whose bank_iban changed within 30 days before a payment to
that vendor.
Evidence required: vendor_id, change date, payment run date and id, the
amount paid, the days between.
This is a fraud-pattern check, not an error check. Report every hit
regardless of amount, and never conclude fraud — report the pattern and
let a human investigate.

## Check 6 — Split invoices under an approval threshold
Two or more invoices from one vendor, within 7 days, that individually
sit below an approval threshold and together sit above it.
Ask for the thresholds if they are not in the data. Do not assume them.
Evidence required: all invoice_ids, individual amounts, the total, the
threshold it crosses.
Legitimate causes exist (partial deliveries, milestone billing). Report
the pattern, mark confidence medium, and name the plausible innocent
explanation you considered.

## Check 7 — Price vs contract
Only run when `contracts` is loaded. Compare invoiced unit price against
the agreed price valid on the invoice date.
Tolerance: the smaller of 2% or 10.00 per unit.
Evidence required: invoice row, contract row, both prices, the variance
per unit and in total.
Skip lines with no matching contract — say how many you skipped rather
than guessing at a price.

## Rules that apply to every check
- Never guess an amount. If the data does not support a number, say so.
- Never merge two findings to make a bigger one.
- A check that finds nothing is a result. Report it explicitly with the
  row count examined — silence is not evidence of absence.
- If a check cannot run because data is missing, say which column was
  missing rather than skipping quietly.
- Report counts and totals per check, plus the population size, so the
  whole audit reconciles.