Testing purchase order approval controls means checking two things separately: whether the approval matrix itself is designed with sensible limits and segregation, and whether purchases above those limits actually passed through an approved PO rather than being booked directly against a supplier invoice. The second check is where the control usually breaks, because a client's accounting system will post a purchase invoice with no PO reference at all and no system check will stop it.
What the approval matrix should specify
Most mid-market clients on Tally or a similar ERP have an approval matrix as a policy document, not a system-enforced workflow. Get the current version in writing and read it against what people in the purchase function describe actually happens, because the two frequently diverge after the policy was last updated.
| Element | Why it matters |
|---|---|
| Value bands and the approver for each band | Defines the threshold your testing has to key off. A matrix with only two bands for a client spending crores on capex is itself a design weakness worth noting. |
| Whether limits are per PO or per vendor per period | A per-PO limit is trivially defeated by raising several POs to the same vendor in a short window. Ask which basis is actually monitored, not just which basis is written down. |
| Who can raise a PO versus who can approve it | Segregation between requisition and approval. In a small purchase team the same two or three people often do both, which the matrix should acknowledge rather than assume away. |
| What happens for purchases with no prior PO | Emergency and recurring purchases (utilities, statutory dues, small repairs) are usually and legitimately exempted. The exemption list is where controls quietly expand if nobody reviews it. |
| Revision and cancellation authority | Who can increase an approved PO's value after the fact, and whether that increase needs the same approval as a fresh PO of that value. |
Testing whether the control actually operated
Walkthroughs and a sample of ten POs tell you the control exists. They do not tell you whether it was bypassed on the purchases that mattered. The useful test is a population-level comparison of the purchase register against the PO register, not a sample.
- 01Pull the full PO register and the full purchase register for the periodBoth at line level where possible. A PO register that only the purchase department can produce, separate from the accounting system, is itself worth noting as a control weakness.
- 02Match purchase invoices to PO numbersEvery purchase invoice above the matrix's lowest threshold should carry a PO reference that exists in the PO register, for an amount that is consistent with the PO (allowing for a defined tolerance, not an open-ended one).
- 03Extract invoices above threshold with no PO reference at allThis is the population that matters. In our experience on Tally-based clients this is rarely zero, and the question is whether the exceptions are legitimate (recurring vendors, statutory payments) or are value purchases that should have gone through approval and did not.
- 04Check approver identity against the matrix, not just the presence of a signatureA PO approved by someone one level below the required authority, or by someone on leave that week with a stamp used in their absence, passes a presence test and fails a substance test.
- 05Reconcile PO value to invoiced value and to goods or services actually receivedAn approved PO for one amount followed by an invoice for a materially higher amount, with no revision approval on file, means the approval that exists on paper is not the approval that governed the actual spend.
- 06Look at POs raised and approved on the same day, or out of chronological sequenceA PO dated after the supplier invoice date, or approved within minutes of being raised by the same person who would normally need a second approver, indicates the PO was created to document a purchase decision already made rather than to control it.
A single large purchase split into several invoices, each below the approval threshold, is the most common way this control is bypassed, and it is deliberate far more often than it is accidental. Look for the same vendor, the same or closely dated invoices, and line items that are naturally part of one transaction (one machine, one annual contract, one batch of materials) billed separately within a short window. Aggregate by vendor and by week, not just by invoice, because the threshold test on individual invoices will never catch this by design.
Quantifying and aggregating the split-invoice pattern
The test for splitting is an aggregation test, not a lookup. Group the purchase register by vendor and by a rolling window (seven to fourteen days works for most clients), sum the invoice values in each group, and flag any group whose total exceeds an approval threshold that no single invoice in it individually crossed. Cross-check the flagged groups against the PO register: if there is one PO covering the combined value, the split is probably administrative and benign; if there is no PO, or several small POs raised to match the split invoices, that is the pattern worth escalating.
- Same vendor, multiple invoices within a short window, no single invoice above threshold but the sum materially above it.
- Invoice descriptions that are clearly part of one purchase decision (sequential delivery challans for one order, phased billing of one contract with no phasing clause).
- POs, if any exist for the group, raised in quick succession to amounts just under the threshold rather than one PO for the real requirement.
- The pattern concentrated in one buyer or one approver rather than spread across the purchase function.
What to do with the exceptions
Quantify the no-PO population and the split-invoice population separately, by value and by vendor, before forming a view. A handful of small recurring vendors with no PO is a control observation. A pattern concentrated in a few vendors or one buyer, at material value, is a control deficiency that belongs in the management letter and should widen the sample for substantive purchase testing in that area, because a control that is being actively worked around gives no comfort over the transactions it was meant to cover.
Common practice, not a requirement
Raising the question with the purchase team before concluding is standard practice, not a requirement. Genuine reasons exist — a long-standing vendor relationship where a blanket PO was never formally renewed, or a system migration that lost historical PO links — and distinguishing those from deliberate avoidance is a judgement call that depends on talking to the people doing the buying, not just the data.
How we think about this
Matching every invoice to a PO, flagging the no-PO population, and aggregating by vendor and window to surface splitting are all mechanical, population-wide checks that software should run every time rather than a sample a reviewer picks. What stays with the auditor is judging whether a given exception is an administrative gap or a deliberate workaround, and that judgement needs a conversation with the purchase team, not just the output of a query.
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
- Purchase & AP auditPurchase testing in statutory audit: procedures, samples and exceptionsAgreeing the population, choosing a sample basis that survives review, the procedures that address each assertion, and what to do with what they throw up.
- Purchase & AP auditPurchase register audit: what to check before you test anythingWhat a purchase register must contain, the checks that establish it is complete and internally consistent, and the defects that quietly invalidate everything tested on top of it.
- Purchase & AP auditPurchase invoice vouching: a practical approachWhat to examine on a purchase invoice, in what order, the tickmarks worth using, and how to record the test so a reviewer can tell what was checked without asking.
- Purchase & AP auditGoods receipt note (GRN) audit and the missing-GRN riskWhat to test when a client's GRNs do not exist or cannot be trusted, and how GRN-to-invoice timing is used as a cut-off indicator rather than a formality.
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.
- 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.