TotalApp Docs
Ctrl K
Home
EN | TR
Go to App

Transaction Audit & Reconciliation

The 4 screens that audit invoice matching, multi-source bank reconciliation, fraud/anomaly detection, and ledger variance.

What this group does

Transaction Audit & Reconciliation is the transactional-integrity layer of the Financial Audit & Fintech Ops add-on: a 3-way invoice match ledger, a multi-source bank/gateway/POS/ERP reconciliation ledger, a fraud/anomaly triage ledger, and a chart-of-accounts line variance ledger. All 4 screens use the identical direct-per-record two-stage hybrid engine (Stage 1 embedding infrastructure, unwired to the UI; Stage 2 AI-engine-routed synthesis) described on the Overview page.

Invoice Matching Audit
→
Multi-Source Audit & Reconciliation
→
Fraud Detection & Anomaly Audit
→
Ledger Variance Audit

1. Invoice Matching Audit

Purpose: A 3-way match audit ledger — compares a supplier invoice against its purchase order (PO) and goods-receipt note (GRN) amounts, so AP teams can see match risk before approving payment.

Ledger columns / key fields

  • ID format INV-YYYY-XXXX
  • matchId, invoiceNo, vendorName, poReference, invoiceAmount, poGrnAmount, currency
  • matchStatus — fully_matched / price_discrepancy / quantity_mismatch / unlinked_po
  • countryCode, auditDate, aiDiscrepancyBreakdown

Gauge

3-Way Match Ratio Meter — the percentage of records fully matched out of the total, rounded. Standard status-count pattern. Bar color: ≥80% green, 50–79% amber, below red.

Key actions

  • New Record — opens the record modal.
  • AI Analyze — runs the invoice matching audit, producing a discrepancy breakdown plus a confidence score; disabled while invoice number or vendor name is blank.
  • Approve / Approve for Payout (row action) — updates the record’s own match status to fully matched only; disabled once already fully matched.
  • Delete — permanent, with inline confirmation.

Known limitation

Approve does not touch a real accounts-payable ledger. The app does have a real Accounts Payable module with real supplier invoices, but there is no link/lookup between those records and this screen’s invoice match records. Approve only updates this add-on’s own record.

2. Multi-Source Audit & Reconciliation

Purpose: Internally named Bank Reconciliation. Compares a bank/payment-gateway/POS/ERP statement against the company’s internal book balance — matched, pending clearance, or an unexplained variance.

Ledger columns / key fields

  • ID format REC-YYYY-XXXX
  • reconciliationId, statementReference, channel (bank / payment_gateway / pos / erp_internal)
  • statementBalance, internalBookBalance, currency
  • status — matched / unmatched_variance / pending_clearance
  • countryCode, auditDate, aiVarianceBreakdown

Gauge

Reconciliation Match Ratio Gauge — the percentage of records marked matched out of the total. Bar color: ≥80% green, 40–79% amber, below red.

Key actions

  • New Record, AI Analyze (runs the reconciliation audit, producing a variance breakdown plus an optional suggested adjustment; disabled while statement reference is blank).
  • Adjust / Correct Variance (row action, inline mini-form: amount + reason) — appends a correction note, and flips the status to matched only if the adjustment amount closes the remaining gap.
  • Delete — permanent.

Known limitation

Adjust does not post to a real general ledger. There is no journal-entry-posting system anywhere in the app today. Adjust only appends a note and conditionally updates its own record’s status.

3. Fraud Detection & Anomaly Audit

Purpose: A fraud triage ledger — flags suspicious transaction patterns (velocity spikes, structuring, geo/IP mismatches) per account/asset, each carrying a risk score, risk level, and audit decision.

Ledger columns / key fields

  • ID format FRD-YYYY-XXXX
  • auditId, accountRef, transactionVolume, currency
  • riskScorePct (0–100), anomalyType (velocity_spike / structuring / geo_ip_mismatch)
  • riskLevel (critical / high / medium), auditAction (frozen / under_review / cleared)
  • triggerTimestamp, countryCode, aiPatternAnalysis

Gauge

Portfolio Anomaly Severity Meter — the percentage of records at critical or high risk level out of the total. Reversed-logic bar (high is bad): ≥60% red, 30–59% amber, below green. Row-level risk score bars use the same thresholds independently per record.

Key actions

  • New Record, AI Analyze (runs the fraud/anomaly audit, producing a pattern analysis plus an optional confidence score; disabled while account/asset reference is blank).
  • Freeze Account / Freeze Assets (row action, inline mini-form: reason) — sets the audit action to frozen and appends a “Frozen: …” note; disabled once already frozen.
  • Delete — permanent.

Known limitation

Freeze does not lock a real account or notify a real security team. There is no separate account-freeze/security-alert system anywhere in the app today. The action only updates this record’s own audit-action field.

4. Ledger Variance Audit

Purpose: The final screen in this group. Tracks the gap between a chart-of-accounts line’s expected balance (trial balance) and its actual ledger balance — unexplained, under review, or reconciled.

Ledger columns / key fields

  • ID format VAR-YYYY-XXXX
  • auditId, accountCode, accountTitle, expectedBalance, actualBalance, currency
  • varianceSeverity (high / medium / low), auditStatus (unexplained_variance / under_review / reconciled)
  • financialPeriod, countryCode, aiRootCauseAnalysis

Gauge

Balance Sheet Integrity Index — the percentage of records marked reconciled out of the total. Bar color: ≥80% green, 40–79% amber, below red.

Key actions

  • New Record, AI Analyze (runs the ledger variance audit, producing a root-cause analysis plus an optional confidence score; disabled while account code/title is blank).
  • Post Adjusting Entry (row action, inline mini-form: amount + debit account + credit account + reason) — sets the audit status to reconciled and appends adjustment details to the notes; disabled once already reconciled.
  • Delete — permanent.

Known limitation

Post Adjusting Entry does not post a real double-entry journal. The Finance module does have a real Journal Entries screen, but it exposes no journal-posting function this screen can call, and there is no link between this screen’s ledger variance records and a real general-ledger entry. The action only updates this record’s own status and notes.

Architecture note: embedding layer present but not wired to the UI

All 4 screens follow the add-on-wide two-stage hybrid engine. Stage 1 (embedding) semantic-search infrastructure exists for Bank Reconciliation, Fraud Detection, and Invoice Matching respectively (Ledger Variance Audit has no dedicated semantic search at all) — but none of the four screens use it yet. Users go straight from filling the form to pressing “AI Analyze,” which triggers Stage 2 (AI-engine-routed synthesis) directly, with no semantic-search step first. See the Overview page for the full two-stage architecture.

Pages in this section

Frequently Asked Questions

Does Approve on Invoice Matching Audit actually pay the vendor?
No — it only updates this record’s own match status to fully matched. There is no link to the real accounts-payable ledger and its supplier invoice records.
Does Adjust on Multi-Source Audit & Reconciliation post to a general ledger?
No — there is no general-ledger/journal-posting system anywhere in this codebase. The action only appends a correction note and, if the amount closes the gap, flips the record’s own status to matched.
Does Freeze Account on Fraud Detection actually lock the account?
No — there is no account-freeze or security-alert system in the app today. The action only updates this record’s own audit-action field to frozen.
Is the embedding/semantic-search layer used anywhere in these 4 screens?
No — it exists as background infrastructure but isn’t used by any of the 4 screens yet. Users go directly from the form to the AI Analyze button, which triggers Stage 2 synthesis only.
Does the Ollama AI engine ever call the server for these screens?
No — when the selected AI engine is Ollama, local-LLM, or web-LLM, all 4 screens run their analysis directly from the browser and never hit the server. Only local-CLI and API route to the server.