A usable general ledger extract for audit testing needs, at minimum, the voucher date, voucher number, voucher type, narration, the debit and credit amounts, the ledger name and code on both sides of the entry, and a running balance. A day-book export gives you every voucher across all ledgers in date order, which is right for cut-off and completeness work; a ledger-wise export gives you one ledger's full movement, which is right for testing a specific balance. Using the wrong one, or treating them as interchangeable, is a common and avoidable source of rework.
What fields a general ledger extract must carry
| Field | Why it is needed | Common gap |
|---|---|---|
| Voucher date | Cut-off testing, period allocation, date-based sampling | Entry date and voucher date differ and only one is exported |
| Voucher number | Sequence testing, tracing to supporting documents, tying to sub-ledgers | Resets or restarts partway through the year without a note explaining why |
| Voucher type | Separating purchases, sales, journals, contra and payment entries | Loosely used, so a journal entry hides what should be classified elsewhere |
| Narration | Understanding the nature of a journal or unusual entry without going back to the client for every row | Left blank, or copied verbatim across unrelated entries |
| Debit and credit amount | Recomputation and agreeing the extract total | Exported as a single signed column, which works but needs a documented sign convention |
| Ledger name and code, both sides of the entry | Tracing double entry, grouping, and tying to the chart of accounts mapping | Only the ledger being reported on is shown; the contra ledger is omitted |
| Running balance | Spot-checking the extract against a point-in-time balance the client can verify independently | Present in a ledger-wise export, absent in most day-book exports |
Day-book export vs ledger-wise export
These two exports answer different questions, and the difference matters more than it looks on the surface.
- A day-book export lists every voucher posted across every ledger, in chronological order. It is the right source for completeness, cut-off and sequence testing, because it preserves the order and timing of entries across the whole company, not just one ledger.
- A ledger-wise export lists every entry that hit one specific ledger, with an opening balance, every movement, and a closing balance. It is the right source for testing a specific balance — a loan account, a key vendor, a fixed asset ledger — because it gives you a self-contained roll-forward you can tie to the trial balance figure for that ledger alone.
- Neither substitutes for the other. A day-book pulled for twelve ledgers one at a time is slower and more error-prone than one ledger-wise export per ledger; a single ledger-wise export cannot be used to test completeness across the whole population because it only ever shows you what already hit that one ledger.
Common practice, not a requirement
Decide which export you need before asking the client for data, not after. Re-requesting a different export mid-fieldwork because the first one does not answer the question is one of the most common causes of lost days in Indian audit fieldwork.
Reconciling the extract before using it
- 01Total the extract exactly as receivedSum debits and credits separately before any cleaning or reclassification. This is your baseline figure — every later transformation should be checked against it.
- 02Agree the total to the trial balance for the same ledger or group of ledgersA day-book total should tie to the sum of all ledger movements for the period; a ledger-wise total should tie to that one ledger's movement in the trial balance. A mismatch here, before any testing starts, is the cheapest point in the whole engagement to find it.
- 03Check the opening balance against the prior year's closing figuresAn extract whose opening balance does not match last year's signed closing balance usually means a different company file, a restated opening position, or a scope issue that needs to be understood before testing continues.
- 04Spot-check the running balance at two or three pointsPick a few dates through the year and confirm the running balance in the extract matches what the client's own ledger report shows at that date. This catches silent truncation or a partial export far faster than waiting for the final total to disagree.
- 05Record the extract's identity in the working paperFile name, export date, who produced it, and the row count. A client who re-exports mid-audit, even with no intended change, routinely produces a file that differs by a handful of rows.
An extract that does not reconcile to the trial balance is not yet a population. Any testing performed on it before the reconciliation is closed out is testing against an unknown, and that needs to be stated plainly if it cannot be avoided for timing reasons.
How we think about this
Totalling an extract, tying it to the trial balance, and spot-checking a running balance are rule-based checks that should run automatically, the same way, every time a GL extract is loaded. Deciding what an unusual opening-balance difference actually means for the scope of the audit is the auditor's call, not something a reconciliation report can settle on its own.
This is practical guidance written for audit teams, not an authoritative statement of any standard or statute. Standards, forms and timelines change. Check the current text issued by the ICAI and the relevant authority before relying on anything here in an audit file.
Related resources
- Audit data & extractsGetting clean audit data out of TallyThe export paths that actually work, what each one loses, and how to handle the three problems that break most audit imports: blank ledger names, duplicated vendor masters, and opening balances that do not tie.
- Audit data & extractsTrial balance mapping for audit softwareMapping a client's idiosyncratic ledgers to a standard chart of accounts is the step that decides whether analytics and disclosures work at all, and the one most firms rush.
- Audit data & extractsValidating an audit population before you draw a sampleA sample drawn from an unvalidated population tells you something precise about the wrong set of transactions. The checks that establish a population is actually a population, before any sampling begins.
Free tools, no signup
Each one reads a file entirely in your browser — or, for two of them, just answers a few questions — and nothing is ever uploaded.
- Purchase register checkDuplicate payments, round-sum amounts, weekend-dated invoices, incomplete records.
- GSTR-2B reconcilerMatches your purchase register against GSTR-2B — missing invoices either side, amount mismatches.
- Bank reconciliation checkerMatches your cash book against a bank statement — what's outstanding on each side.
- Fixed asset register checkDuplicate asset codes, missing location or useful life, negative net book value.
- Payroll red-flag scannerBank accounts shared across employees, and records missing an ID, PAN or salary.
- CARO applicability checkerAnswer a few questions about the company and see which CARO 2020 clauses likely apply.
- MSME payment delay checkerMSME-flagged invoices paid — or still unpaid — beyond the 45-day Section 22 limit.
- Related-party transaction screenerTransactions above a threshold you set with no approval reference, grouped by counterparty.
- Depreciation useful life checkerCompares a useful life in use against the Schedule II, Part C indicative figure.
- Materiality calculatorOverall and performance materiality against PBT, revenue, assets or equity, with reasoning shown.
- Sample size calculatorStatistical sample size for a test of controls or a substantive test of detail.