# Audit Data Analytics for Bank Transactions

- Author: PreciseBankFlow (https://www.precisebankflow.com)
- Published: 2025-12-15
- Updated: 2025-12-15
- Category: Bank statements in an audit
- Canonical: https://www.precisebankflow.com/blog/audit-data-analytics-for-bank-transactions

> Audit data analytics for bank transactions: full-population tests, weekend and holiday activity, round amounts and how to document analytics as evidence.
Audit data analytics for bank transactions means running tests over every statement line for the period instead of a sample: duplicates, check gaps, weekend and holiday activity, round amounts and payments just under approval limits. Each test produces a list of exceptions. The auditor investigates those exceptions and documents the data, the logic and the conclusion.

## Preparing bank data for audit data analytics

Bank data has to be proven complete and accurate before any test on it means anything. You need every statement for every account, each one footing, each closing balance carrying into the next opening balance, and extracted lines that agree to the PDF. An analytic run on partial data reports a clean result for transactions it never saw.

### Getting the statements

Collect statements for every account on the cash lead, plus any account the bank confirmation names that the lead does not. Accounts outside the books are a risk of their own, and [how auditors find unrecorded bank accounts](/blog/unrecorded-bank-accounts) covers the search. Where possible, get the statements from the bank or through online access you control, rather than as files the client prepared.

### Proving the extraction

Most bank data arrives as PDFs, and turning them into rows is where errors creep in: a page skipped, a line wrapped onto two rows, a minus sign lost. Three checks catch most of it:

1. **Footing.** For each statement, the opening balance plus credits less debits must equal the printed closing balance.
2. **Continuity.** Each closing balance must equal the next statement's opening balance. A gap means a missing statement.
3. **Vouching.** Agree a selection of extracted lines back to the PDF, starting with the lines the extraction was least sure of.

PreciseBankFlow runs the footing check on every statement and gives each extracted field a confidence score, so the vouching starts where it is most needed. When the first statement's opening balance does not agree to the prior year's closing figure, the cause is usually on the books side; [what to do when a beginning balance does not match the bank statement](/blog/beginning-balance-does-not-match-bank-statement) walks through the fixes.

### Tying to the ledger

Finally, agree total debits and credits per account to the general ledger cash activity, allowing for reconciling items at each end. Only then is the dataset fit to test.

## Which full-population tests suit bank transactions?

The tests worth running on bank transactions look for patterns a sample would rarely hit: exact and near duplicates, check number gaps, activity on non-business days, round amounts, payments just below approval limits, unusual payees, and transfers involving accounts not on the cash lead. Each needs a clear rule tied to a risk.

The table below is an example from a hypothetical client with three accounts and a year of activity. Population size and exception counts are made up to show how results typically look.

| Test | Rule used | Lines tested | Exceptions | Resolved as |
| --- | --- | --- | --- | --- |
| Exact duplicates | Same date, amount and description | 14,206 | 11 | 9 recurring fees, 2 duplicate vendor payments |
| Near duplicates | Same amount and payee within 5 days | 14,206 | 38 | 34 regular weekly payments, 4 for follow-up |
| Check number gaps | Missing numbers in the cleared sequence | 1,912 checks | 17 numbers | 15 voided per register, 2 not explained |
| Non-business days | Posting date on a weekend or bank holiday | 14,206 | 63 | 58 card settlements, 5 manual transfers |
| Round amounts | Debits that are whole thousands | 9,440 debits | 72 | Mostly payroll funding and loan payments; 6 for follow-up |
| Just below limit | Debits within 5 percent under the 10,000.00 approval limit | 9,440 debits | 29 | 3 vendors with repeated splits |
| Unlisted counterparties | Transfers to accounts not on the cash lead | 14,206 | 3 | 1 new savings account, 2 to an owner |

### Turning results into work

The exceptions column is the start of the work, not the end. Each row needs a decision: legitimate, error or something to investigate. The figure in the last column is what goes into the workpaper. Duplicate detection is covered in depth in [finding duplicate and missing transactions on bank statement lines](/blog/finding-duplicate-transactions-on-bank-statement-lines), including which repeats are normal.

### Receipts as well as payments

Most analytics focus on debits, because that is where money leaves. Credits deserve tests too: deposits split into amounts just under reporting thresholds, receipts from parties who are not customers, and gaps in deposit timing. [Cash receipts audit procedures and tests](/blog/cash-receipts-audit-procedures) cover how those results feed the receipts work.

## Weekend and holiday bank transactions: reading the timing test

Bank transactions posted on weekends or bank holidays are worth a look because ordinary business payments usually post on business days. A manual transfer or wire dated on a Sunday can point to someone working outside normal oversight. Card settlements, online bill payments and automated sweeps also post on odd days, so the test needs filtering before it means anything.

### Building the calendar

Use posting dates, not transaction dates, and build the calendar of non-business days for each bank's country. For US accounts, the list of weekends plus the bank's published holidays is the usual base. Cash moved on a day the bank was closed will often show the next business day, so a holiday entry in the data is itself unusual and worth checking against the PDF.

### Filtering the noise

Group the flagged lines by type before you look at any of them. Card purchase settlements, processor deposits and recurring automated payments explain most weekend lines in a typical business. What is left, usually a short list, is manual activity: transfers between accounts, wires and online payments entered by a person. For those, find who initiated each and whether it was approved before or after the fact.

### Pairing timing with other flags

A weekend line on its own is weak evidence of anything. A weekend line that is also a round amount, paid to a new payee, and just below the approval limit is a strong lead. Combine flags by line and rank by the number of flags.

## Round-amount bank transactions and split payments

Genuine business payments rarely come out to whole thousands, because invoices include tax, freight and odd quantities. A high share of round amounts can point to estimates, transfers, loans to insiders or invented payments. Payments that sit just below an approval limit, especially several to one payee close together, suggest a large payment was split to avoid a second signature.

### Setting the round-amount rule

Choose a rule that suits the client. Whole thousands is a common start. Whole hundreds catches more but produces more noise. Exclude known round payments such as rent, loan installments and payroll funding before reviewing what remains. A client whose vendors invoice in round figures, such as consultants on fixed fees, will need the rule adjusted.

### Testing for split payments

Get the approval limits from the client's authorization policy. Then flag debits within a small band below each limit, and group them by payee and week. Three payments of 9,800.00 to the same vendor in four days is a pattern; one payment of 9,800.00 is not. For each group, ask for the invoices. If they are sequential invoices for one order, the approval control was bypassed whether or not the goods were real.

## Analytics exceptions in bank data that turn out to be noise

Most exceptions from bank transaction analytics are legitimate: recurring fees that look like duplicates, regular weekly payments that look like near duplicates, voided checks that leave gaps, and processor deposits that post on weekends. Treat noise as a design problem. Tune the rule, record why, and rerun, rather than clearing hundreds of items one by one.

### Common sources of false positives

- **Recurring charges.** Monthly service fees and subscription debits are exact duplicates by design. Exclude known recurring items by payee and amount.
- **Voided checks.** Check gaps usually close once you compare them with the void list in the check register.
- **Batch deposits.** Processor payouts split one day's sales into several deposits of similar size.
- **Reversals and corrections.** A payment, its return and the reissue look like three suspicious lines. Pair them first.

### When tuning goes too far

Every exclusion is a place fraud could hide. Do not exclude a payee because it is frequent; exclude a specific pattern that you have checked once. Keep the excluded lines in a separate list so a reviewer can see what was removed and why.

## How do you document bank transaction analytics as audit evidence?

Document four things: the source of the data and how its completeness was proven, the exact rule each test applied, the exceptions it produced, and how each exception was resolved. A reviewer should be able to rerun the test from the workpaper and get the same list. An analytic without that trail is a lead, not evidence.

For audits under PCAOB standards, this is now spelled out. The [SEC order approving the PCAOB's amendments on technology-assisted analysis](https://public-inspection.federalregister.gov/2024-18986.pdf) describes amendments that specify the auditor's responsibilities for items identified for further investigation in tests of details, require that a procedure used for more than one purpose meet each objective, and address the reliability of information the company provides. The amendments apply to audits of fiscal years beginning on or after December 15, 2025.

### What the workpaper should hold

- The list of accounts and statements, with the footing and continuity results.
- The tie of the dataset to the general ledger.
- Each test's rule in plain words, with any thresholds and exclusions.
- The exception list for each test, with the disposition of every item.
- A conclusion on what the test supports, and whether it was a risk assessment step or a substantive test.

### Analytics and the opinion

Analytics change where the auditor looks, not who decides. PreciseBankFlow is built to run the footing, duplicate and gap checks across every statement and to export the exceptions with their source lines for the file. Judging what each exception means, and whether the evidence is enough, stays with the engagement team.

To see those checks on a set of client statements, [request early access to PreciseBankFlow](/get-started).