How to Build a Claims Matrix (That Survives MLR)
Updated 2026-07-13 · markdown version
A claims matrix (also: claims library, core claims document) is the controlled inventory of statements a company is permitted to make about a product, each paired with its approved supporting evidence. A good one answers three questions instantly for any claim: What exactly may we say? What substantiates it? Where has it been used? Most teams build it in Excel. Most teams also discover why that breaks.
The minimum viable structure
Each row is one claim. The columns that earn their place:
| Column | Why it matters |
|---|---|
| Claim ID | Stable identifier — decks and documents reference it, not the wording |
| Approved claim text (verbatim) | The exact language MLR approved; paraphrase is where drift starts |
| Claim type | Efficacy / safety / MOA / dosing / QoL — reviewers triage by type |
| Supporting reference(s) | Full citation for each source |
| Evidence locator | Page/column/paragraph/line of the substantiating passage — e.g. Pasieka 2020/pg3/col1/para2. This is what your reviewer and VEEVA vault operator actually need |
| Status | Draft / approved / retired — with dates |
| Approved use context | Audience (HCP vs patient), geography, channel restrictions |
| Fair balance / ISI pairing | Safety language that must accompany the claim (US) |
| Version & history | What changed, when, why |
The evidence locator column is the one most spreadsheets skip and most reviewers silently rebuild by hand. Writers annotate deliverables with exactly this format — "annotated references" in US usage, "referenced copy" in UK usage — so carrying it in the matrix means the annotation is a lookup, not an archaeology project.
Referencing standards worth adopting
- Verbatim or nothing. The matrix stores approved language; any wording change is a new claim (or a new version) that re-enters review.
- One claim, one row, every source. A claim substantiated by two papers lists both locators; a "package" of claims is a deliverable concern, not a matrix concern.
- Locators to the paragraph, not the paper. "Smith 2023" is not substantiation;
Smith 2023/pg1430/col2/para2/lines1–3is. Reviewers in regulated promotion work at this granularity — your matrix should too. - Retire, never delete. A retired claim still lives in old material; deleting the row destroys the audit trail exactly when you need it.
Where spreadsheets break
- No propagation. The source of truth changes — updated PI, new data cut, retired claim — and every deck that used the old row stays silently wrong. The matrix can't tell you where a claim was used.
- No drift detection. The deck says "42%," the matrix says "38%," and nothing notices until a reviewer does.
- Version chaos.
claims_matrix_FINAL_v7_KM_edits.xlsxis a punchline because it's true. - Annotation is manual. Every deliverable's reference pack gets rebuilt by hand from the same rows.
These are database problems, not discipline problems — which is why the category is moving from spreadsheets to claim-aware tools. (Lithero explicitly markets against "claims matrix spreadsheets"; our own product, Claims, makes the matrix a live library: each claim deep-linked to its evidence locator, usage tracked across every Word/PowerPoint deliverable, revisions propagating with full version lineage, and drift caught by an agentic pre-review.)
Maintenance cadence that actually holds
- On every new data source: run new-reference triage — which existing claims does this strengthen, weaken, or retire?
- On every PI/SmPC update: mandatory matrix review; label changes are the #1 source of newly-unsupported claims.
- Quarterly: usage audit — which approved claims are actually deployed, which retired claims still appear in circulating material.
- Always: the matrix owner is named, singular, and empowered. Shared ownership is no ownership.
Build it in a spreadsheet if you must start there — the structure above works anywhere. But treat the spreadsheet as the prototype of a system, because at more than ~50 claims or 2 writers, that's what you'll need.