← All posts
Methodology

Monetary Unit Sampling, explained: how the math picks your 41 invoices

A population of ledger amounts divided into equal sampling intervals, with the selected items highlighted

Every audit junior has built the cumulative column: revenue lines stacked in Excel, a running total down column J, and a set of selections that somehow becomes “the sample.” Monetary Unit Sampling is the method behind that ritual — and once you see the arithmetic laid out, it stops being a ritual and starts being defensible. Here is the whole thing, walked through on one engagement-shaped example.

The idea: sample ringgit, not invoices

In MUS — also called probability-proportional-to-size sampling — the sampling unit is not the invoice. It is each individual ringgit in the population. Picture the year’s revenue laid out as one long line of 8,712,500 one-ringgit units. The method selects ringgit at regular intervals along that line, and whichever invoice a selected ringgit happens to sit inside becomes a sample item.

That single design choice does the clever work: a RM 240,000 invoice contains 240,000 chances of selection, a RM 1,300 invoice contains 1,300. Large items are proportionally more likely to be picked, which is exactly where an overstatement would hurt most. This is why MUS is the workhorse for revenue and receivables testing.

The four numbers that set the sample

Everything flows from parameters the firm sets, not the software:

ParameterExampleWhere it comes from
MaterialityRM 850,000The firm’s benchmark and percentage
Performance materialityRM 637,500Here 75% of materiality — firm policy
Confidence level95%Assessed risk; 95% → reliability factor 3.0
Sampling intervalRM 212,500PM ÷ reliability factor = 637,500 ÷ 3.0

The reliability factor comes from the Poisson distribution — 3.0 is the standard factor for 95% confidence with zero expected misstatements. Divide performance materiality by it and you get the interval: one selection for every RM 212,500 of population.

Why the sample lands on 41

Now the arithmetic that fills the workpaper. The revenue population is RM 8,712,500. Divide by the interval:

8,712,500 ÷ 212,500 = 41 selections.

The selection itself is systematic: pick a random start between 1 and 212,500, then take every 212,500th ringgit after it. Two more rules finish the method:

  • Items larger than the interval are certainties. Any invoice of RM 212,500 or more must contain at least one selected ringgit, so it is automatically in the sample — the “tested 100%” stratum on the workpaper.
  • Credit notes and negatives are handled separately. They cannot sit on the cumulative line, so the method deals with them outside the main selection — a detail that is easy to fumble in a hand-built spreadsheet.

Where hand-built MUS goes wrong

The method is sound; the execution is where engagements bleed. Three failure modes come up again and again in review:

  1. The cumulative column is built on a messy GL. If the ledger was standardized by hand from a PDF export and a line was dropped or doubled, every selection after that point shifts. The sample looks fine and is silently wrong.
  2. The interval math and the workpaper disagree. The parameters say one thing, the selections say another, and nobody re-derives the numbers before sign-off.
  3. Fatigue at the vouching stage. The selection was perfect; the checking at item 34, late in the evening, was not.

The same math, run by an agent

Audeet runs exactly this method with the firm’s own parameters — materiality, PM percentage, confidence level — shown on the face of the workpaper so a reviewer can re-derive the interval in one line. The cumulative population is built from a standardized ledger rather than a hand-massaged export, certainties are stratified automatically, and after vouching, the agent re-adds its own totals and asserts they tie before it reports done. The methodology stays the firm’s. The arithmetic just stops depending on how tired the person building column J was.

Watch the sample draw itself

The demo runs the full cycle — standardize, map, sample, vouch, tie out — on a real ledger in about ten minutes. Your parameters, your templates.

Request a demo