MSME disclosure testing checks whether a company has correctly identified which of its suppliers are registered micro, small or medium enterprises under the Udyam registration framework, and then whether payments to those suppliers were made within the time limit set by the Micro, Small and Medium Enterprises Development Act, generally understood to require payment within forty-five days of acceptance of goods or services where there is a written agreement, with interest becoming payable on delayed amounts at a rate specified under that Act. The disclosure required in the financial statements covers principal and interest amounts due and paid late, and the exact statutory period and rate should be confirmed against the current MSMED Act and rules before being cited in a working paper.
Why the vendor master is the real obstacle
The computation behind this disclosure, once you know which vendors are MSMEs, is a straightforward date comparison: invoice acceptance date, payment date, days elapsed, interest on the excess over the statutory period. The difficulty is almost never the computation. It is that most vendor masters in mid-market ERPs have no reliable field recording Udyam registration status, so the starting population of "which vendors are MSMEs" is wrong before testing even begins.
- A vendor master field for MSME status often exists but is populated inconsistently, sometimes self-declared by the vendor years ago and never refreshed.
- A vendor can be Udyam-registered and simply never have told the company, in which case the company's own records show them as a non-MSME vendor even though the statutory disclosure obligation still applies.
- Udyam classification itself can change: a vendor registered as micro can be reclassified to small as its turnover grows, which changes nothing about the disclosure obligation but is worth knowing when assessing vendor concentration risk separately.
Building a reliable MSME vendor population
- 01Start from the full vendor master, not a client-flagged subsetAsking the client for "the list of MSME vendors" first and testing only that list repeats whatever gaps already exist in their own flagging. Start from every vendor paid during the year.
- 02Request Udyam registration certificates for vendors above a reasonable testing thresholdA Udyam certificate carries a registration number that can be checked against the format and, where practical, against the public Udyam portal for existence and category.
- 03Cross-check vendor GSTIN and PAN against any available Udyam-linked data the client holdsSome ERPs and GST reconciliation tools surface Udyam status through linked identifiers; treat this as a lead to confirm with the certificate, not as a substitute for it.
- 04Flag vendors with no response and assess materialityA vendor who has not confirmed Udyam status either way cannot be definitively classified; document the enquiry made and the conclusion reached rather than defaulting silently to "not MSME."
- 05Enrich and freeze the vendor master for the engagementOnce classification is established for the year, record it against the vendor master as audit evidence, including the date the status was confirmed, since status can change the following year.
Treating a vendor as non-MSME simply because the company's own vendor master has no flag for them is the single most common failure in this area. The absence of a flag is not evidence of non-MSME status; it is evidence that nobody asked.
Testing the 45-day payment tracking
| Field | Why it is needed |
|---|---|
| Date of acceptance of goods or services | The statutory clock for the payment period runs from acceptance, which is not always the invoice date and should be checked against any written agreement |
| Agreed credit period, if any | Where the parties have agreed a credit period in writing, that period applies up to the statutory maximum; silence defaults to the statutory period |
| Actual payment date | Compared against acceptance date plus the applicable period to determine delay |
| Invoice amount and any partial payments | Interest accrues on the unpaid principal from the day after the due date, so partial payments change the base for interest calculation |
- 01Reconcile MSME vendor invoices to payment datesFor the full population of confirmed MSME vendors, pull every invoice and its corresponding payment, computing days elapsed from acceptance to payment.
- 02Flag every invoice exceeding the statutory periodNot just a sample. This is a mechanical date comparison across a full population and is exactly the kind of check that should not be sampled.
- 03Compute interest on delayed paymentsApply the statutory interest rate to the overdue principal for the delay period on each flagged invoice, and confirm the rate against the current Act since it is specified in the statute itself.
- 04Reconcile the computed disclosure to what the company has disclosedCompare the company's own MSME disclosure note, including principal and interest outstanding and paid beyond the period, against the independently computed figures, and investigate any material gap.
Regulatory requirement
The statutory payment period, the interest rate on delayed payments, and the disclosure format required under Section 22 of the MSMED Act and under the relevant Companies Act disclosure rules should all be confirmed against the current text of those laws. This article deliberately avoids asserting the exact number of days or the exact interest rate as a cited figure, because these are statutory specifics that should be checked rather than remembered.
How we think about this
Once the vendor population is correctly classified, the days-elapsed and interest computation is a deterministic calculation that should run against every invoice from every confirmed MSME vendor, not a sample, because the disclosure requirement itself is about completeness of reporting rather than a materiality-scoped estimate. The genuinely hard part, confirming which vendors are actually MSMEs when the company's own records do not reliably say so, is where the real audit effort belongs.
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
- CARO & Companies ActCARO 2020 reporting checklist for statutory auditorsThe topic areas CARO reporting covers, what evidence each one needs, and how the clauses fit together across the audit file.
- CARO & Companies ActCARO statutory dues clause: testing approachHow to test timely deposit of statutory dues for CARO reporting, handle disputed dues disclosure, and avoid redoing work already done in the GST and payroll sections.
- CARO & Companies ActCARO default in repayment of loans: audit testingTesting repayment schedules against actual payment dates, using bank confirmations as the independent check, and where the line sits between a minor delay and a reportable default.
- Purchase & AP auditVendor reconciliation in statutory auditHow to select vendors for confirmation, the seven categories every difference falls into, how to handle non-responses, and what an unconfirmed balance is worth.
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.
- 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.