# Vouching and Tracing: Direction Decides the Assertion

- Author: PreciseBankFlow (https://precisebankflow.com)
- Published: 2026-10-17
- Category: Bank statements in an audit
- Canonical: https://precisebankflow.com/blog/vouching-and-tracing

> Vouching and tracing explained: which direction tests existence and which tests completeness, with bank statement examples for each in an audit.
Vouching and tracing are the same comparison run in opposite directions. Vouching starts from a recorded entry and goes back to the source document, so it tests existence: did this really happen? Tracing starts from the source document and goes forward to the records, so it tests completeness: was everything that happened recorded? The direction decides the assertion.

## Does vouching or tracing test existence?

Vouching tests existence, also called occurrence for transactions. You pick items that are already in the ledger and look for evidence outside it, such as a bank statement line, an invoice or a contract. A recorded item with no support may be fictitious. Tracing cannot find that problem, because it never starts from the fictitious entry.

The reason is simple once you picture the populations. A fake entry exists only in the ledger. If you start from the bank statement and work forward, you will never land on it, because no bank line leads there. Only a test that begins in the ledger can reach it. The reverse is just as true: a receipt that was never recorded exists only on the bank statement, so only a test that starts there can find it.

The table below summarizes the two directions. The bank examples are illustrations.

| | Vouching | Tracing |
| --- | --- | --- |
| Starts from | The ledger or journal | The source document, such as the bank statement |
| Ends at | The source document | The ledger or journal |
| Assertion tested | Existence or occurrence | Completeness |
| Finds | Recorded items that did not happen | Real items that were not recorded |
| Bank example | Ledger payment of 4,180.00 to a supplier, found on the statement as a cleared check | Statement deposit of 2,615.40, found in the cash receipts journal on the same day |

## Vouching a cash disbursement entry back to the bank statement

Vouching a disbursement means taking a payment recorded in the cash disbursements journal and finding the evidence that the money really left. The bank statement shows the payment cleared; the invoice and approval show what it was for. Both matter, because a statement line proves money moved but not that it was owed.

Work from the journal. For each selected payment, confirm four things: the amount on the bank line matches, the payee on the check image or transfer detail matches the vendor in the ledger, the date is in the right period, and there is an approved invoice behind it. A payment that clears for a different amount than recorded, or clears to a different name, is a finding even when the invoice looks fine.

Vouching recorded liabilities works the same way, but the most important test for liabilities runs the other way, as the [search for unrecorded liabilities](/blog/search-for-unrecorded-liabilities) shows. That search starts from payments made after year end and traces back to see whether the obligation was recorded at the balance sheet date.

## Tracing bank statement deposits forward into the ledger

Tracing a deposit means starting from a credit on the bank statement and finding where it was recorded. Every credit should land somewhere in the books: a customer receipt, a loan, a transfer from another account or interest. A credit that lands nowhere is an unrecorded receipt, and the next question is where the matching revenue or liability went.

Pick the sample from the bank statement, not from the receipts journal. For each deposit, find the receipts journal entry, confirm the amount and date, and check which account the credit side hit. Deposits that were posted to an odd account, such as a suspense account or an owner's loan, deserve a question even when the amount is right.

The [subsequent receipts test](/blog/subsequent-receipts-testing) uses the same bank evidence in the other direction. It starts from receivables recorded at year end and looks for the cash received afterwards, so it supports existence rather than completeness.

## Vouching and tracing a marketplace payout deposit

A marketplace payout is a single bank deposit that nets many orders, fees and refunds, so both tests need an extra layer. To trace it, start from the bank credit and go forward to the settlement report and then to the ledger entry. To vouch it, start from the ledger entry and go back to both documents.

Take an example payout of 9,842.17 (example value). The settlement report shows gross sales of 11,300.00, fees of 1,212.33 and refunds of 245.50. Tracing forward, you confirm that the ledger recorded sales, fees and refunds separately rather than one net figure, and that the totals agree to the report. Vouching back, you confirm that the recorded sales figure is supported by the report and that the net matches the bank line. How these payouts are tied out in detail is in the guide to [Amazon settlement reconciliation](/blog/amazon-settlement-reconciliation).

The netting is what makes this matter. A ledger that records only the net deposit understates both revenue and fees, and neither error shows up in a bank reconciliation.

## Mistake: why draw a vouching sample from the ledger, not the bank statement?

The most common error is choosing the population that matches the documents you have, not the assertion you are testing. An auditor who wants evidence for existence but samples from bank statements is actually tracing. The test then supports completeness, and the existence risk the program called for remains untested.

The fix is to state the assertion first and let it pick the population. Write it in the workpaper heading: "Existence of recorded disbursements: sample drawn from the cash disbursements journal." A reviewer can then see at a glance whether the direction fits. When a program needs both assertions for the same account, run both tests, each from its own population, rather than reusing one sample.

Results from both directions belong in the workpaper with the documents that support each item. The [reconciliation report sample](/blog/reconciliation-report-sample) shows a layout that keeps each exception next to its evidence. [PreciseBankFlow](/) is built to read every line of the statements and match them to the ledger, which gives you both populations to sample from without retyping either one.