Accounts payable is where most occupational fraud money leaves the building and where most process errors turn into cash, and it is also the process with the best data: every invoice, vendor, approval and payment sits in one or two tables with dates, users and amounts. That combination is why AP analytics is the first program most audit functions build and the one that pays back fastest. This catalog sets out forty tests across six families, duplicate payments, vendor-master red flags, timing and sequence anomalies, amounts and outliers, approval and bypass patterns, and employee-vendor collusion, each with the logic, the data it needs, a starting threshold, what a hit usually means and what produces false positives. It then covers the data preparation the tests depend on, how to run the catalog as a program rather than a one-off, a triage and corroboration template, and a worked first run at a beverage distributor.
This guide was rewritten in September 2026 from a shorter version published in August 2026. The tests are stated in terms of fields rather than any particular tool, because every one of them can be run in SQL, Python, a purpose-built audit analytics package or, for smaller populations, a spreadsheet. The ACFE’s Occupational Fraud 2026: A Report to the Nations, covering 2,402 cases in 143 countries with a median loss of $104,000, associates proactive data monitoring and analysis with median losses 53 percent lower than in organizations without it, which is the business case in one sentence.
In this guide
- The data you need first, and how to prove it is complete
- Family 1: Duplicate payments (8 tests)
- Family 2: Vendor-master red flags (8 tests)
- Family 3: Timing and sequence anomalies (6 tests)
- Family 4: Amounts, thresholds and outliers (7 tests)
- Family 5: Approval and bypass patterns (6 tests)
- Family 6: Employee-vendor collusion (5 tests)
- Building the three hardest matches
- Running the catalog: thresholds, triage and corroboration
- The triage and corroboration record
- Worked example: MidState Beverage’s first AP run
- From one-off run to continuous program
- Common mistakes
- Related guides
The data you need first, and how to prove it is complete
Four tables carry the whole catalog, and the first hour of any run is spent proving they are complete, because a finding drawn from an extract missing a company code will not survive its first meeting. The invoice table: invoice number, vendor ID, invoice date, entry date and time, entering user, amount, currency, PO reference, description, GL account, approval status and approver, payment status. The payment table: payment ID, vendor ID, invoice references, payment date, amount, method, bank account paid to, releasing user. The vendor master: vendor ID, name, tax ID, addresses, bank accounts with change history, creation date and user, status, payment terms, last change date and user. And the employee master, from HR rather than the ERP: name, addresses, bank account for payroll, tax ID, hire and termination dates, department. Change-history tables for the vendor master and the approval workflow log complete the set for the approval and collusion families.
Completeness is proved before any test runs: invoice totals by period reconciled to the AP sub-ledger and the payments to the cash disbursements journal and the bank; vendor counts reconciled to the master’s own control report; the employee file reconciled to headcount. The reconciliation, the extraction queries and the run date go in the workpaper as the population record, following the IPE testing guide, and the sampling memo template is used where a test’s hits are sampled rather than reviewed in full. Field normalization comes next: names upper-cased with punctuation and legal suffixes stripped, addresses standardized, bank accounts and tax IDs stripped of formatting, amounts converted to a base currency, and invoice numbers stored both raw and with leading zeros and separators removed. Half the catalog’s power comes from matching on normalized fields, and half its false positives from matching on raw ones.
Family 1: Duplicate payments (8 tests)
Duplicate payments are the family with the highest recovery per hour, because a confirmed hit is cash the vendor owes back, and the family in which the ERP’s own duplicate check gives the most false comfort, since it usually keys on exact vendor, invoice number and amount and is defeated by a space, a suffix or a second vendor record. The tests run from exact to fuzzy, and a duplicate found by a later test and not an earlier one tells you which control gap let it through.
| Test | Logic | Data and threshold | A hit usually means | False positives |
|---|---|---|---|---|
| D1 Exact duplicate | Same vendor ID, invoice number and amount, both paid | Invoice and payment tables; no threshold | Control failure at entry or the ERP’s check disabled or bypassed | Legitimate recurring invoices with the same number by vendor design (rare) |
| D2 Same invoice, different date | Same vendor and invoice number and amount, different invoice date | Invoice table | Re-keyed invoice with a corrected date; vendor re-billing | Installment billing with repeated reference numbers |
| D3 Same everything but invoice number | Same vendor, amount and invoice date, different invoice number | Invoice table; amounts above a floor (for example $500) to cut noise | Second copy entered from a statement or a reminder with a different reference | Genuine identical orders on the same day (utilities, fixed fees) |
| D4 Fuzzy invoice number | Same vendor and amount; invoice numbers match after stripping non-alphanumerics, leading zeros, and common suffixes; or within an edit distance of 1 to 2 | Normalized invoice number field | The classic evasion of the exact-match control, deliberate or accidental | Sequential invoices from the same vendor for identical amounts |
| D5 Duplicate vendor records | Same amount and invoice number (raw or normalized) across two vendor IDs whose normalized name, tax ID or bank account match | Vendor master plus invoice table | Duplicate vendor setup used to pay the same invoice twice | Legitimate separate legal entities sharing a name |
| D6 Near-amount duplicates | Same vendor, same or similar invoice number, amounts within a small tolerance (for example 1 percent or a fixed freight or tax difference) | Invoice table | The same invoice re-entered with or without tax, freight or a discount | Credit-and-rebill sequences; partial deliveries billed separately |
| D7 Cross-entity duplicates | Same vendor tax ID or bank account, same invoice number and amount, paid by two company codes or entities | All entities’ invoice tables; vendor master joined on tax ID | Shared-service or decentralized entry paying the same invoice from two entities | Intercompany recharges misrecorded as vendor invoices |
| D8 Unapplied credits | Credit memos or vendor credits older than a threshold not applied against any payment | Invoice table (negative amounts) and payment application | Money owed to the organization that nobody is collecting; sometimes the trace of a duplicate refunded and never applied | Credits legitimately held for disputed accounts |
Family 2: Vendor-master red flags (8 tests)
The vendor master is where fictitious-vendor and payment-diversion schemes begin, and the tests in this family compare it to the one dataset the fraudster cannot control, the employee master, and to its own change history. The vendor master audit guide covers the controls over the master; these tests are the detective layer that runs whether or not the controls exist.
| Test | Logic | Data and threshold | A hit usually means | False positives |
|---|---|---|---|---|
| V1 Vendor bank equals employee bank | Normalized vendor bank account (and sort or routing code) matches an employee payroll account | Vendor master bank fields; HR payroll bank file (handled under strict access) | Fictitious vendor or diverted payments to an employee | Employees legitimately reimbursed through AP as vendors; family businesses disclosed as conflicts |
| V2 Vendor address equals employee address | Standardized address match, including PO boxes and unit numbers | Vendor and employee address fields | Employee-owned vendor, disclosed or not | Shared office buildings; home-based contractors properly set up |
| V3 Vendor tax ID equals employee tax ID | Exact match on normalized tax identifiers | Vendor and employee tax ID fields | Sole-proprietor vendor that is an employee; near-certain conflict | Disclosed dual roles (an employee who is also a landlord) |
| V4 New vendor, fast money | First payment within N days of vendor creation (for example 14), especially above a threshold or without a PO | Vendor creation date; first payment date and amount | Vendor created to pay a specific invoice; urgent-sounding scheme pattern | Genuine emergency suppliers; one-off professional services |
| V5 Bank change before payment | Bank account changed within N days before a payment, particularly a large one, or changed and changed back | Vendor change history; payment table | Business email compromise or insider diversion; the highest-loss pattern in the family | Genuine bank changes coinciding with routine payments |
| V6 Shell-profile vendors | Missing or generic data: no tax ID, PO box only, free-email domain, phone matching another vendor or an employee, name that is a person’s name paid for non-personal services | Vendor master attributes; scoring across attributes | Fictitious vendor or poorly vetted one | Small legitimate suppliers set up in a hurry |
| V7 Dormant vendor reactivated | No activity for more than N months (for example 18), then payments, especially after a master-data change | Payment history by vendor; change history | Reused vendor ID hijacked for new payments | Seasonal suppliers; renewed contracts |
| V8 Multiple remit-to accounts | Vendor with several bank accounts or remit-to addresses, or bank accounts shared across vendors | Vendor bank table | Diverted payments layered through alternative accounts; duplicate vendor setups | Multinational vendors with regional accounts; factoring arrangements |
Family 3: Timing and sequence anomalies (6 tests)
Timing tests find process circumvention rather than fraud in most hits, and they are the family that most often produces control findings the process owner had no idea about, because the ERP records timestamps nobody looks at.
| Test | Logic | Data and threshold | A hit usually means | False positives |
|---|---|---|---|---|
| T1 Invoice before PO | Invoice date or entry date earlier than the PO creation date it references | Invoice and PO tables | Retrospective POs raised to legitimize commitments already made; the purchasing control not operating | Blanket POs with later releases; date entry errors |
| T2 Same-day trio | PO created, goods receipt recorded and invoice entered on the same day, especially by the same user | PO, receipt and invoice tables with users | Documentation manufactured after the fact to pass the three-way match | Genuine same-day services; small-value fast purchases |
| T3 Off-hours entry | Invoices or payments entered or released outside working hours, on weekends or holidays | Entry timestamps; calendar | Activity outside supervision; or a batch process with a system user, which is the normal explanation | Time zones; scheduled jobs; period-end overtime |
| T4 Boundary-date clustering | Concentration of invoices dated or entered in the last days of a period, or just after, relative to the period’s daily average | Invoice dates by period | Cut-off manipulation; expense acceleration or deferral | Genuine month-end billing cycles by vendors |
| T5 Payment before invoice | Payment date earlier than invoice date or invoice entry date | Payment and invoice tables | Prepayments not controlled as such; manual payments with the invoice entered later; date manipulation | Legitimate deposits and prepayments recorded through AP |
| T6 Bulk clearing of aged items | Many aged open items cleared, written off or paid in one batch by one user | Open item history; clearing documents | Cleanup that may conceal duplicates, disputes or unrecorded liabilities; or a write-off used to bury a diverted payment | Authorized housekeeping before a system migration |
Family 4: Amounts, thresholds and outliers (7 tests)
Amount tests are where approval limits and human habits show up in the data. The two that matter most, just-below-threshold clustering and split invoices, need the organization’s actual approval limits as inputs, taken from the delegation of authority rather than from what people say the limits are.
| Test | Logic | Data and threshold | A hit usually means | False positives |
|---|---|---|---|---|
| A1 Just-below-threshold clustering | Frequency of invoices in the band just below each approval limit (for example 90 to 99.9 percent of the limit) compared to the bands above and below | Invoice amounts; delegation of authority limits | Deliberate structuring to avoid a higher approver | Price points that naturally sit near round limits |
| A2 Split invoices | Two or more invoices from one vendor within a short window whose sum exceeds a limit that each alone avoids; same PO or description | Invoice table; limits | Structuring; or a vendor billing in parts by agreement with the requester | Genuine partial deliveries or milestone billing |
| A3 Round-amount concentration | Share of invoices at round amounts ($1,000, $5,000) by vendor and by user against the population norm | Invoice amounts | Fabricated or estimated invoices; services billed without measurement | Retainers, rents, subscriptions |
| A4 Benford deviation | First-digit (and first-two-digit) distribution of invoice amounts by vendor or user compared to Benford’s expected distribution, for populations large enough to test | Invoice amounts, at least several hundred per stratum | Invented numbers; a vendor or user whose amounts do not arise naturally | Populations with natural limits (fixed price lists) do not follow Benford; small samples |
| A5 Price drift | Unit price for the same item or service code rising over time against the contract or the population, by vendor | Invoice lines with item codes and quantities; contract prices | Overbilling; contract non-compliance; kickback-funded price increases | Legitimate indexation; specification changes |
| A6 Vendor baseline outlier | Invoice amount far above the vendor’s own historical distribution (for example beyond three standard deviations or above the 99th percentile) | Invoice history by vendor | Error, duplicate, or a one-time fraudulent invoice against a familiar vendor name | Annual or project invoices from vendors that usually bill small amounts |
| A7 Fee and surcharge creep | Non-product lines (freight, fuel surcharge, handling, expedite fees) as a rising share of vendor spend | Invoice lines by category | Contract leakage; charges outside the agreed terms | Genuine market changes in freight or fuel |
Family 5: Approval and bypass patterns (6 tests)
Approval tests read the workflow log, and they are the family that most directly tests whether the segregation the organization believes it has is the segregation the system enforces. A single hit on P1 is a control failure regardless of amount, because it proves the routing can be defeated.
| Test | Logic | Data and threshold | A hit usually means | False positives |
|---|---|---|---|---|
| P1 Self-approval | Approver user equals entering or requesting user, or equals the user who created the vendor | Workflow log; invoice and vendor creation users | Routing rule or delegation setting that lets the requester approve; the failure MidState Beverage found in 1,412 of 37,400 route-cash overrides | None; every hit is at least a control finding |
| P2 Under-level approval | Approver’s delegated limit below the invoice amount, using the delegation of authority as at the approval date | Workflow log; delegation table with effective dates | Limits not enforced in the system; workflow configured from an outdated delegation | Temporary delegations properly authorized but not recorded in the table |
| P3 Speed-run approvals | Time between routing and approval below a plausible review time (for example under 30 seconds), or many approvals by one user within minutes | Workflow timestamps | Rubber-stamping; approval by a delegate clearing a queue | Small recurring invoices genuinely reviewable at a glance |
| P4 Off-channel payments | Payments with no invoice record, manual payments outside the payment run, or payment methods outside policy (manual checks, wires from treasury) to vendors | Payment table; bank data compared to AP | Bypass of the invoice controls entirely; the pattern behind many diverted-payment cases | Legitimate treasury payments (taxes, debt service) that should be excluded by design |
| P5 Creator pays own vendor | User who created or changed a vendor record also entered or approved invoices to it, or released its payments | Vendor change history; invoice and payment users | Segregation failure at the heart of the fictitious-vendor scheme | Small AP teams where the same person legitimately does both, which is itself the finding |
| P6 Rush-payment concentration | Share of payments flagged urgent or paid outside terms, by requesting user and vendor, against the norm | Payment table with urgency flags and terms | Pressure used to bypass review; or a process that cannot meet its own terms | Genuine early-payment discount programs |
Family 6: Employee-vendor collusion (5 tests)
Collusion tests look for the relationship rather than the transaction: the requester who always uses the same vendor, the vendor whose fortunes track one employee’s tenure. They produce few hits and the hits are serious, and they are the family whose results are handled under the fraud response protocol from the first review, per the fraud risk management guide.
| Test | Logic | Data and threshold | A hit usually means | False positives |
|---|---|---|---|---|
| E1 Single-requester vendors | Vendors whose spend comes almost entirely (for example above 90 percent) from one requester or approver, above a spend floor | Invoice table with requester; spend by vendor | A relationship worth understanding; the precondition for kickbacks | Specialist suppliers used by one department by design |
| E2 Vendor tenure tracks employee tenure | Vendor’s first and last activity dates within weeks of an employee’s hire, transfer or termination | Vendor activity history; HR dates | A vendor brought in and taken out by one person | Coincidence; suppliers tied to a project the employee ran |
| E3 Shared contact data | Vendor phone, email domain or contact name matching an employee’s, or two vendors sharing contacts | Vendor contact fields; employee directory | Undisclosed ownership or a front | Employees legitimately listed as vendor contacts for internal coordination |
| E4 Sole-source without justification | Vendors above a spend threshold with no competitive process recorded and one requester | Spend by vendor; sourcing records | Procurement bypass; the environment in which price drift and kickbacks operate | Genuine sole sources with the justification filed elsewhere |
| E5 Post-termination activity | Invoices approved or vendors changed by a user after their termination date, or vendors paid after their contact employee left with no successor | Workflow users; HR termination dates | Credentials still active (an access control failure) or a scheme continuing through a shared login | Termination dates recorded late in HR |
Building the three hardest matches
Three tests account for most of the build effort, and each has a pattern worth stating. The fuzzy invoice match (D4) is built as a self-join of the invoice table on vendor ID and amount, with the join condition on a normalized invoice key: upper-case, non-alphanumerics removed, leading zeros removed, and common suffixes such as A, R, REV and the like stripped into a separate flag; pairs where the normalized keys are equal but the raw keys differ are the hits, and a second pass computes an edit distance of one or two between raw keys for the pairs the normalization missed. The employee-vendor match (V1 to V3) is a join between the vendor master and an HR extract on normalized bank account, address and tax ID, run one field at a time and scored, with the HR extract obtained under a documented access arrangement and destroyed after the run, because the analytics workbook must not become the organization’s least-protected copy of payroll bank data. The below-threshold band (A1) is built from the delegation of authority as a table with effective dates, joined to invoices by the approver’s limit at the approval date; the test counts invoices per band of the limit (80 to 90 percent, 90 to 100 percent, 100 to 110 percent) by requester and vendor, and flags where the 90 to 100 band is more than twice the average of its neighbors. In every case the parameters live in a configuration table, not in the code, so the second run changes numbers rather than logic.
Running the catalog: thresholds, triage and corroboration
Forty tests on a year of AP data produce thousands of hits, and the program lives or dies on what happens next. Thresholds are set to make review possible, not to find everything: the first run sets each test’s parameters (the duplicate amount floor, the fast-money window, the below-threshold band) so that the hit list for each test is reviewable in a day, records the parameters, and tightens them in later runs as the false-positive causes are eliminated at source. Hits are scored, not just listed: a transaction that hits several tests (a new vendor with a shell profile, paid fast, entered off-hours, just below a limit, by a user who created the vendor) is worth more than five single hits, and a simple additive score with weights by family, higher for approval and collusion, orders the review queue. Each test’s hits are then triaged in three passes: the mechanical pass that removes known systematic causes (the batch user, the intercompany vendor, the utility that bills identical amounts), the desk pass that reviews the remaining hits against the source documents in the ERP, and the corroboration pass that takes the hits that survive to the vendor’s website, the contract, the requester, the bank, or, for the collusion family, to the fraud response protocol.
Corroboration is where an analytics finding becomes an audit finding. A duplicate is corroborated by the vendor’s statement or a credit note; a self-approval by the workflow configuration that permitted it; a vendor-employee match by the employee’s disclosure record and the vendor’s registration; a bank change by the change request and the verification call that should have preceded it. The accounts payable audit guide covers the control tests that corroboration usually leads into, and the root cause analysis guide the step from a pattern of hits to the control failure behind it. Findings are written against the control that failed, with the hit count and the amount at risk, rather than as a list of anomalies; a list of anomalies is what the process owner will argue with, and a control failure with a count is what they will fix.
The triage and corroboration record
One record per test per run, with the hit-level detail held in the analytics workbook or tool and referenced. The record is what makes the run repeatable and what a reviewer reads to see that the hits were dealt with rather than counted.
AP analytics test record
1. Test. Catalog reference and name; family; run date; period covered; analyst.
2. Population. Tables and extraction queries; record counts and totals; reconciliation to the sub-ledger, bank or HR control totals; normalization applied.
3. Parameters. Thresholds, windows, floors and limits used, with the source of any organizational input (delegation of authority version, contract price file).
4. Results. Raw hit count and amount; hits after the mechanical pass with the systematic causes removed and listed; hits after the desk pass with the categories of explanation; hits taken to corroboration.
5. Corroboration. For each corroborated hit: evidence obtained, conclusion (error, control failure, policy breach, suspected fraud, false positive), amount, recovery status, referral made.
6. Findings. Control failures identified with counts and amounts; finding references; process changes agreed.
7. Tuning. False-positive causes to eliminate at source or exclude next run; parameter changes recommended; tests to add or retire.
8. Sign-off. Analyst, reviewer, dates; handling restrictions for records containing personal data.
Worked example: MidState Beverage’s first AP run
MidState Beverage, the illustrative three-state drinks distributor used across this site, runs AP through a 2013 ERP with a three-way match tolerance of 5 percent or $250 that has not changed since 2019, twelve depots that raise purchase requisitions, and two acquired distributors whose payables were migrated onto the ERP eighteen months ago. Its six-person audit function ran the catalog for the first time as part of the FY27 analytics allocation, with the analytics auditor spending 180 of the plan’s 600 analytics hours on it. The population was 14 months of data: 61,400 invoices totaling $148 million, 3,140 active vendors, 58,900 payments, and an HR file of 1,400 current and 312 terminated employees, reconciled to the sub-ledger and the bank within $2,100, which was traced to two voided checks.
| Family | Raw hits | After triage | What was found |
|---|---|---|---|
| Duplicate payments | 1,940 | 63 | 41 confirmed duplicates totaling $286,000, 29 of them from the acquired distributors’ migrated vendor records (D5), recovered $241,000 within the quarter; the ERP’s exact-match check had been disabled during the migration and never re-enabled |
| Vendor-master red flags | 412 | 27 | Two vendor bank accounts matching employee payroll accounts (V1): one a disclosed spouse-owned cleaning contractor, one an undisclosed trucking vendor owned by a depot manager, referred under the fraud protocol; 14 bank changes within 10 days of large payments (V5) with no verification call, one a business email compromise attempt that had been caught by the bank |
| Timing and sequence | 5,300 | 210 | 1,860 invoices dated before their POs (T1), concentrated in three depots, a purchasing control not operating rather than fraud; 92 same-day trios by two depot administrators (T2) |
| Amounts and outliers | 2,100 | 88 | Clustering just below the $5,000 depot approval limit (A1) at two depots, 3.4 times the expected frequency; 31 split invoices (A2) from one fleet maintenance vendor; fuel surcharge share up from 6 to 11 percent of one carrier’s spend (A7) outside the contract |
| Approval and bypass | 1,480 | 1,480 on P1, 19 others | 1,412 self-approved overrides on route-cash items (P1), the routing rule finding that became finding F2 in the route cash audit; 210 manual payments outside the run (P4), 40 to vendors, the rest treasury items excluded next run |
| Employee-vendor collusion | 96 | 6 | The depot manager’s trucking vendor (E1, E2, E3 all hit); one requester using a single sole-source vendor for $410,000 with no competitive process (E4); two post-termination approvals through a shared depot login (E5) |
The run produced nine findings: the disabled duplicate check and the migration’s vendor duplication (High), the routing rule (High, already in the route cash report), the unverified bank changes (High), the depot manager’s undisclosed vendor (referred), the purchasing-control failure behind the pre-PO invoices (Medium), the below-limit clustering and splits (Medium), the shared depot login (Medium, cross-referenced to the ERP user access audit), the fuel surcharge leakage (Low, recovered $38,000), and the manual payment channel (Low). The recoveries, $279,000 in the first quarter, exceeded the analytics auditor’s annual cost, which the CAE put in the audit committee pack without comment. The second run, six months later, used the tuned parameters, excluded the treasury payments and the intercompany vendors by design, and took 60 hours.
From one-off run to continuous program
The first run is an audit; the second is a program. The transition has four parts. The tests are coded once, parameterized and stored under version control, so that a run is an execution rather than a rebuild, and the population reconciliation is part of the code. The frequency is set by test: duplicate and bank-change tests run monthly or before each payment run, because their value is in prevention; vendor-master and collusion tests quarterly; timing and amount tests semi-annually, because they describe process behavior that changes slowly. Ownership splits: the analytics auditor owns the tests, the AP manager receives the duplicate and bank-change hits as a control (which then becomes a management control the audit tests rather than performs, as the continuous auditing versus continuous monitoring guide distinguishes), and internal audit keeps the approval and collusion families, whose hits it would not hand to the process owner. And the results feed the risk assessment: a family whose hits fall to near zero for three runs is evidence for the internal audit risk assessment that the process risk has moved, and a family whose hits rise is a trigger to look before the annual plan does.
Common mistakes
Running the tests on an extract nobody reconciled. Matching on raw fields and drowning in false positives, or normalizing so aggressively that distinct vendors merge. Taking the approval limits from what people say instead of the delegation of authority as at the date. Handing the collusion family’s hits to the process owner. Reporting anomalies instead of control failures. Setting thresholds to catch everything and reviewing nothing. Treating the ERP’s duplicate check as a control without testing whether it is switched on and what it keys on. Excluding the acquired entities because their data is messy, which is where the duplicates were. Running once and calling it a program. And storing employee bank and tax data from the HR match in the analytics workbook without the access restrictions the data privacy audit guide would require of anyone else. The journal entry analytics catalog and the payroll analytics catalog follow the same structure, and the procurement fraud analytics guide covers the tender and contract side that this catalog begins at the invoice.
Related guides
- How to audit accounts payable
- How to audit the vendor master
- Procurement fraud analytics
- The payroll analytics catalog
- The journal entry analytics catalog
- IPE testing
- Audit sampling memo template
- Fraud risk management
- Fraud red flags
- Root cause analysis for audit findings
- Continuous auditing versus continuous monitoring
- Internal audit risk assessment
- Procurement fraud schemes — the scheme families the vendor-master and duplicate tests point at
- How to audit payment operations and wire transfers — the bank-side controls the payment tests assume
- How to audit cash management and bank reconciliations — the reconciliation tests that corroborate the run
- SQL for Auditors: 20 Queries Mapped to Audit Questions — 20 queries mapped to audit questions.
- Auditing Insurance Claims: FNOL to Settlement Program — first notice of loss to settlement: reserving, authority, vendors, fraud and leakage.
- Documenting Analytics as Audit Evidence: Queries and Scripts — queries, scripts, completeness and the workpaper that lets a reviewer rely on the result.
- Continuous Monitoring on a Small Budget: 5 to 10 Indicators — five to ten indicators, Power Query or SQL jobs, thresholds and triage, with no platform.
Leave a Reply