Purchase register audit: what to check before you test anything

A purchase register audit checks that the register is a complete, internally consistent record of the period's purchases before any transaction in it is tested. That means agreeing its total to the purchases ledger and the trial balance, confirming the date range and voucher types it covers, checking for gaps and duplicates in the document sequence, and identifying the purchase streams it excludes. A register that fails these checks is not a population, and every sample drawn from it supports a conclusion about the wrong set of transactions.

Why the register is the load-bearing document

Three separate pieces of audit work draw from the same purchase register: purchase and accounts payable testing, the input tax credit reconciliation against GSTR-2B, and the payables balance and ageing. A defect in the register propagates into all three, and it usually surfaces late, as an unexplained difference in the reconciliation that nobody can close.

It is also the document the client produces with the least care. In most mid-market clients it is a report run out of the accounting system on request, with whatever columns and filters the person who ran it happened to choose. Two registers produced a week apart by two people routinely disagree.

What the register has to contain to be testable

Before checking anything, check that the columns you need are present. Requesting a re-run at this point costs a day. Discovering a missing column in week three costs the section.

The checks that establish the register is usable

1. 01Confirm the period and the basis on which it was runAsk which date field the report was filtered on. A register filtered on voucher date and one filtered on invoice date will not contain the same transactions at the year end, and the difference is precisely the population your cut-off testing is about.
2. 02Total the register and agree it to the purchases ledgerDo this on the file you will actually test, not on a summary the client sends separately. Differences are usually journals posted straight to purchases, purchases recorded under a different voucher type, or a filter that excluded a branch.
3. 03Agree the ledger to the trial balance and the trial balance to the draft accountsTwo reconciliations, both short. Without them the register is agreed to something that itself agrees to nothing.
4. 04Reconcile to the GST returns at a summary levelTotal taxable value of inward supplies in the register against the credit claimed in the GSTR-3B returns for the year. It will not agree exactly and is not meant to, but the size of the gap tells you early whether the input credit work is going to be a half-day or a fortnight.
5. 05Test the voucher sequence for gaps and duplicatesA gap is usually a cancelled voucher, and the client should be able to show you the cancelled one. A gap nobody can explain is a deleted transaction, which is a different matter entirely. Duplicated voucher numbers usually mean two company files or a restored backup.
6. 06Check for duplicate invoice references within the registerThe same supplier and the same invoice number appearing twice is the highest-yield single check on the register, and it costs minutes.
7. 07Count and quantify blank critical fieldsRows with no supplier code, no GSTIN, no invoice number or no date. Quantify them by value rather than by count. Two hundred blank GSTINs on small rows is a data quality note; four blanks totalling a quarter of the purchases figure is a scope problem.
8. 08Identify negative and zero-value rowsNegatives are usually purchase returns or credit notes sitting inside the register. They must be separated before the register is used as the population for a match against GSTR-2B, where they behave differently.
9. 09Group the vendor master and look at the concentrationGroup by PAN or GSTIN where present, by normalised name where not. Then look at the top vendors by value, the number of one-transaction vendors, and vendors created during the year. This is where related-party and unusual-vendor work starts.
10. 10Profile the postings by datePurchases by month, and by day around the year end. A month-end spike is normal; a year-end spike that does not repeat in other months is a cut-off question. Postings dated after the year end but within the period are a control question.
11. 11Establish which purchase streams are outside the registerImports, reverse-charge supplies, purchases from composition dealers, branch transfers, job work, expenses booked through journal entries and anything routed through a petty cash book. List them, quantify them, and cover each with its own procedure rather than assuming the register covers everything.

A worked example of a register that looks fine

A register totals to the purchases ledger exactly. It looks clean. Three checks change the picture.

• Grouping the vendor master by PAN collapses 640 supplier names into 517 suppliers. Twelve of the collapsed groups contain a transaction pair with the same invoice number and amount, entered once against each spelling: a duplicate booking that the ledger total cannot reveal because both entries are in it.
• Filtering on voucher type shows 38 rows of type Credit Note carrying negative values. They net off inside the total, so the total still agrees, but the population for the GSTR-2B match has been understated by their gross value and the payables ageing is wrong for those vendors.
• Profiling by date shows 14% of the year's purchases posted in the last four days of March, against a monthly average of 8%. That may be entirely genuine, and it is the single most useful thing to know before designing the cut-off sample.

None of these is exotic. All three are invisible if the only check performed is that the register agrees to the ledger.

Recording the work

The register checks belong in the file as a working paper in their own right, not as a preamble to the testing paper. A reviewer needs to be able to see that the population was established, by whom, on what file, and with what unresolved defects, without reading the testing that follows.

• The file tested, identified precisely, with row count and control total.
• The reconciliation chain from register to ledger to trial balance to draft accounts, with each difference explained rather than netted.
• The streams excluded from the register and where each is covered instead.
• Data quality defects found, quantified by value, and what was done about each.
• Any defect left unresolved, with its effect on the scope of the testing stated explicitly.