A journal entry test is only as good as the file it runs on. If the export leaves out a voucher type, a company code or a month, every clean result from the test is quietly worthless. Before any filter for odd dates or round amounts, the auditor should prove that the file holds every posting that built the trial balance.
Last reviewed: 17 October 2026. Facts checked. We opened a web search on SA 240 and an ICAI newsletter extract that reproduces the requirement to test the appropriateness of journal entries and other adjustments; we did not open the full ICAI text of SA 240, so paragraph numbers are not cited. We did not open Tally or SAP documentation; the export steps below describe common practice and menu names vary by version. The worked example is invented.
Why completeness comes first
SA 240 asks the auditor to test the appropriateness of journal entries recorded in the general ledger and other adjustments made in preparing the financial statements, whatever the assessed risk of management override. The wording points to two things: entries in the ledger, and adjustments that may sit outside it. An export that covers only the first has already missed half the question.
The person who hands over the file is often the person whose entries are under test. That is not an accusation, just a reason to check the file independently rather than trust it.
For the tests themselves, see our guide to journal entry testing procedures and red flags. This post covers the step before them.
The three-way tie-out
A complete file passes three simple checks.
- Debits equal credits for the whole file. If total debits and credits differ, rows are missing or the export has split a voucher.
- Account totals rebuild the trial balance. For each ledger account, opening balance plus the file's net movement should equal the closing balance in the signed trial balance. Do this for every account, not only the large ones. A short list of differences is a finding about the file, not about the client.
- Voucher counts and number sequences are continuous. Sort by voucher number within each voucher type. Gaps are not automatically a problem (deleted drafts, cancelled vouchers) but each one needs an explanation.
Keep the tie-out as a working paper. It is the evidence that the population was complete and reliable, which is what the later conclusions rest on.
Tally: where files go incomplete
Tally exports are easy to produce and easy to get wrong. Points to check:
- Period and company. Confirm the export covers the full financial year, not the current view on screen, and that it is the right company data folder. A client with several companies in one installation can hand over the wrong one.
- Voucher types. Day book exports may exclude optional vouchers, memorandum vouchers or post-dated vouchers depending on settings. Ask which voucher types exist and confirm each appears in the file.
- Cancelled and deleted vouchers. Cancelled vouchers can remain visible with zero value; deleted ones vanish. If the audit trail (edit log) is on, it records changes and deletions. Our guide to the Tally edit log explains what it captures and how to review it.
- Ledger-level or voucher-level. A ledger-wise report repeats each voucher once per ledger it touches, so totals double up. Decide the grain before summing.
- Narration and user fields. Tally data may or may not carry the user who created a voucher. If it does not, say so in the working paper; the user-based tests cannot be run on that file.
SAP: where files go incomplete
In SAP, journal data usually comes from extracts of document header and line item tables, or from a report the client's team runs. Points to check:
- Company codes and ledgers. Confirm that every company code in scope is in the extract and that the ledger used (leading or a parallel one) matches the financial statements.
- Document types. Different document types serve different purposes: ordinary journals, vendor invoices, clearing documents and so on. Ask for the list of document types and their meaning, then decide which are in scope.
- Parked and held documents. These are not posted and do not affect balances, but they show activity that may be posted later. Know whether they are in or out of your file.
- Posting date and entry date. The header normally carries both a posting date and a date the document was entered, and a user name for who entered it. These fields drive the timing and user tests later, so confirm they came through intact.
- Period 13 to 16 postings. Special periods used for year-end adjustments are exactly where late entries live. Check that they are in the file.
Our guides on SAP tables for an internal audit data request and on what auditors test in SAP and what access they need cover the data request side.
Adjustments that never touch the ledger
Some of the most important changes are made after the ledger closes: consolidation entries, reclassifications in the Schedule III working, and adjustments made in a spreadsheet to move from trial balance to financial statements. These are "other adjustments" in the SA 240 wording. Ask for the bridge between the ledger trial balance and the final financial statements, and treat every line on that bridge as a journal to be tested. Our post on post-closing and top-side adjustments goes deeper.
A worked example (invented)
A mid-sized company runs Tally Prime for its books. The extract for FY 2025-26 shows 14,200 vouchers and balanced debits and credits. The tie-out finds that closing balances rebuilt from the file differ from the trial balance for three ledgers, all in March. Investigation shows that the export was taken on 10 April and the client posted further vouchers after that date.
Numbers like these are made up for illustration. The lesson is real: the first file looked complete because it balanced. Balance proves nothing about missing pairs of entries. Only the account-by-account rebuild exposed the gap, and the auditor re-requested the file.
What to document
- Source, date and time of the export, and who ran it.
- The report or table used, with filters applied.
- Control totals (row count, total debits, total credits).
- The account-level reconciliation to the trial balance and explanations of differences.
- Voucher sequence gaps and what explained them.
- Limits: fields that were not available, such as user name.
If a gap cannot be explained, say so and consider how it affects the conclusion rather than silently proceeding. Reliance on a file that fails its own tie-out is not defensible.
The takeaway
Completeness is dull work that makes everything after it believable. Spend the first hour on the tie-out, and the red-flag tests become evidence rather than decoration.
Statutory facts on this page are checked against their sources, and the page says where it relied on secondary reporting. How we verify · Report an error