Test of Design

Test of design checks whether a control, as written, is built to catch a specific error, separate from whether it was actually followed on real invoices.

Twitter LinkedIn WhatsApp
Ask AI: ChatGPT Claude Gemini Grok
Test of Design

Test of design is an audit procedure that evaluates whether a control, as it is written and structured, is capable of preventing or detecting the specific error it is intended to catch, independent of whether anyone actually followed it. It sits upstream of the more familiar question of whether a control worked in practice. In service vendor invoice review, the distinction decides whether a missed charge means the rule was wrong or the rule was ignored.

A control that is followed perfectly can still miss margin drift if it was never built to test the clause the drift comes from. Test of design separates that failure mode from a compliance failure: it asks whether the control's logic covers the risk, not whether staff executed it correctly on any given invoice. The mechanism that produces the gap is coverage, not diligence.

1. What does a test of design actually evaluate?

A test of design evaluates the structure of a control on paper: what it checks, what data it uses, and what it is built to catch. It does not evaluate whether the control was performed on any real invoice. A control can be logically sound and still leave gaps if the clause it targets is narrower than the risk it is meant to cover.

The reviewer traces the control back to the specific contract clause it is supposed to enforce and confirms the two actually match. A control that checks unit price only tests unit price, nothing else in the clause it sits under.

2. How does it differ from a test of operating effectiveness?

A test of design asks whether the control could work if performed exactly as written. A test of operating effectiveness asks whether it was performed, consistently, on real transactions over a real period. The two answer different questions and a control can pass one while failing the other, which is why audit programs run them separately rather than treating one as a proxy for the other.

A design pass with an effectiveness failure points to training or staffing. The reverse points to the control itself, not to the people running it.

3. Why does a well-designed control still miss margin drift?

A well-designed control tests exactly the clause it was written for and nothing else. Contracts carry many separate terms, and each one needs its own control to be tested at all. A gap in coverage, where a clause has no corresponding control, produces drift that no amount of compliance with existing controls will ever catch.

Rate checks, volume tiers, rebate triggers, and index escalation formulas each require a distinct test, not one shared check applied across all of them.

4. How is test of design used in a margin drift diagnostic?

A diagnostic starts by mapping every contract clause against the controls that exist to test it, before asking whether those controls were followed. Clauses with no matching control are flagged first, since compliance testing on a nonexistent control returns nothing. This ordering separates a coverage gap from a compliance failure early, which changes what fixes it.

The mapping step is fast and structural. It does not require sampling invoices to begin producing findings, which is why it runs first.

For the wider pattern this sits inside, start with the margin drift guide.

5. Frequently Asked Questions (People Also Ask)

What is a test of design in plain terms?

A test of design checks whether a control, as written, is capable of catching the error it is meant to catch. It asks whether the rule is right, not whether someone followed it. A three-way match control can be well designed and still miss a surcharge that never appears on the purchase order.

How is test of design different from test of operating effectiveness?

A test of design asks whether the control could work if followed exactly. A test of operating effectiveness asks whether it actually was followed, on real invoices, over a real period. A control can pass design and fail effectiveness, or the reverse: a poorly designed control followed perfectly still misses what it was never built to check.

Why does test of design matter for margin drift specifically?

Margin drift often survives because a control was never designed to test the clause that produced it. A rate card check that only validates unit price will pass every invoice even when a minimum commitment shortfall is accumulating underneath it, because that clause was outside the control's design.

Does a passed test of design mean the invoice is correct?

No. It means the check, if performed, would catch the class of error it targets. Whether that check was actually run on a given invoice is a separate question, answered by a test of operating effectiveness, not by the design test.

Who normally performs a test of design: internal audit or an external reviewer?

Either can. Internal audit teams run design tests as part of standard control assessments. An external contract compliance review runs the same logic against a specific vendor population, often surfacing gaps a generic internal control walkthrough was not scoped to find.

Can a control be well designed but still leak margin?

Yes. A well-designed control tests exactly the clause it was built for, but a contract has many clauses. Volume tiers, rebate triggers, and index escalation formulas each need their own control. A gap in coverage, not a design flaw in an existing control, is a common source of drift.

What is an example of a test of design failure?

A control requires AP to check the invoiced rate against a rate card. If the rate card on file is outdated, the design itself is flawed: it points staff at the wrong reference, so even perfect compliance with the control produces a wrong invoice.

Where does test of design fit in a margin drift diagnostic?

Early. Before checking whether invoices were actually correct, the diagnostic maps which contract clauses have a control designed to test them at all. Clauses with no corresponding control are flagged first, because no amount of compliance testing will catch what nothing was built to catch.

1. What does a test of design actually evaluate?

A test of design evaluates the structure of a control on paper: what it checks, what data it uses, and what it is built to catch. It does not evaluate whether the control was performed on any real invoice. A control can be logically sound and still leave gaps if the clause it targets is narrower than the risk it is meant to cover. The reviewer traces the control back to the specific contract clause it is supposed to enforce and confirms the two actually match. A control that checks unit price only tests unit price, nothing else in the clause it sits under.

2. How does it differ from a test of operating effectiveness?

A test of design asks whether the control could work if performed exactly as written. A test of operating effectiveness asks whether it was performed, consistently, on real transactions over a real period. The two answer different questions and a control can pass one while failing the other, which is why audit programs run them separately rather than treating one as a proxy for the other. A design pass with an effectiveness failure points to training or staffing. The reverse points to the control itself, not to the people running it.

3. Why does a well-designed control still miss margin drift?

A well-designed control tests exactly the clause it was written for and nothing else. Contracts carry many separate terms, and each one needs its own control to be tested at all. A gap in coverage, where a clause has no corresponding control, produces drift that no amount of compliance with existing controls will ever catch. Rate checks, [volume tiers](/glossary/volume-tier), [rebate triggers](/glossary/rebate-gap), and [index escalation formulas](/glossary/index-escalation-misapplied) each require a distinct test, not one shared check applied across all of them.

4. How is test of design used in a margin drift diagnostic?

A diagnostic starts by mapping every contract clause against the controls that exist to test it, before asking whether those controls were followed. Clauses with no matching control are flagged first, since compliance testing on a nonexistent control returns nothing. This ordering separates a coverage gap from a compliance failure early, which changes what fixes it. The mapping step is fast and structural. It does not require sampling invoices to begin producing findings, which is why it runs first. For the wider pattern this sits inside, start with the [margin drift](/insights/margin-drift-spend-leakage-guide) guide.

Questions & Answers

What is a test of design in plain terms?

A test of design checks whether a control, as written, is capable of catching the error it is meant to catch. It asks whether the rule is right, not whether someone followed it. A three-way match control can be well designed and still miss a surcharge that never appears on the purchase order.

How is test of design different from test of operating effectiveness?

A test of design asks whether the control could work if followed exactly. A test of operating effectiveness asks whether it actually was followed, on real invoices, over a real period. A control can pass design and fail effectiveness, or the reverse: a poorly designed control followed perfectly still misses what it was never built to check.

Why does test of design matter for margin drift specifically?

Margin drift often survives because a control was never designed to test the clause that produced it. A rate card check that only validates unit price will pass every invoice even when a minimum commitment shortfall is accumulating underneath it, because that clause was outside the control's design.

Does a passed test of design mean the invoice is correct?

No. It means the check, if performed, would catch the class of error it targets. Whether that check was actually run on a given invoice is a separate question, answered by a test of operating effectiveness, not by the design test.

Who normally performs a test of design: internal audit or an external reviewer?

Either can. Internal audit teams run design tests as part of standard control assessments. An external contract compliance review runs the same logic against a specific vendor population, often surfacing gaps a generic internal control walkthrough was not scoped to find.

Margin Drift Resources