· Aisha Rahman
Invoice completeness is a financial assertion, not a report from the vendor
If the billing application is the book of original entry for subscriptions, completeness testing has to start in that application — not in the ledger summary it posts.
Statutory auditors are used to testing sales completeness from dispatch notes or till rolls. Subscription businesses often have neither. The event that should give rise to an invoice is a record inside the billing application: an active subscription, a usage file, a renewal flag, a recovered payment.
Relying on the application’s own “invoices this month” report to prove completeness is circular. The report is produced by the same system whose completeness is in question. An independent extract of the subscription master, compared to the invoice register on keys the vendor does not control in one screen, is a more useful starting point.
In Malaysian entities we also look at SST. An uninvoiced taxable supply is still a tax problem. Completeness testing that ignores tax codes will miss a class of error that LHDN cares about even when the revenue number looks plausible.
The practical sequence we use in Damansara engagements is: lock a population date, extract subscriptions that should have billed, extract invoices that did bill, and explain every unmatched row. “The customer was in trial” is an explanation only if the trial flag existed at the population date, not on the day someone looked.
If this is the problem on your close, request a scoping note