What a docs-vs-Terms audit actually delivers — sample report inside

Last month I wrote about the most damaging bug I found not being in code — it lived between a fintech's marketing page and its own Terms of Service. Six numbers that disagreed with each other, all public, none of them typos.

Since then people keep asking the same two questions: how do I check mine, and what does a professional version of this look like. This post answers both — the second one with an actual (anonymized) sample report.

The 5-minute self-check

1. Open your homepage and copy every claim with a number or a promise in it ("unlimited", "instant", "protected", "$X cap", "SOC 2", "no fees").
2. Open your ToS and Privacy Policy in plain text (most legal pages have a raw or print view; if the docs live on GitBook, append .md to any page URL and you get clean markdown).
3. For each claim, grep the legal docs for the exact noun. "Zero hits" means one of two things: you're missing a clause, or you're making a promise the contract doesn't back.
4. Check the two places contradictions hide: the liability cap against your strongest safety promises, and the compliance section against your pricing page's badges.
5. Anything that survives step 3–4 unscathed goes in a "verified consistent" list — that list is half the value of a real audit, and nobody ever has one.

That's the triage. It catches maybe 70% of what a full pass catches — and the 30% it misses is where the expensive surprises live (payment flows with no contractual schedule, indemnification clauses that point the wrong way, privacy documents that never mention an entire product line).

What a full report looks like

I published an anonymized sample report from a real audit — an AI-email SaaS whose flagship wallet-payments feature had zero terms coverage. The structure:

• Findings with severity. Major / medium / minor, each with the marketing quote, the clause reference, and the reader impact — why an enterprise buyer's legal review would stop at this line.
• Recommended fix language per finding. Not "add a clause" but what the clause needs to define, ready for legal review.
• A verified-consistent section. The two-directional receipts: things I checked that do line up. Auditors and procurement want to see you checked both ways; a report that only lists problems reads like an attack, a report that lists both reads like diligence.
• Timestamped snapshots backing every quote, so the report stays checkable after the site changes.

When it's worth paying someone

• Before a ToS update ships. You're editing the document anyway; contradictions are cheapest to fix in the same pass.
• Before enterprise procurement or fundraising DD. Buyers' counsel will run a version of the 5-minute check. Being the one who found it first is worth real money in the negotiation.
• After shipping a payments/wallet/AI-agent feature. New money-movement surfaces are where I've found the biggest gaps — the feature ships months before the contract catches up.

I run this as a service — one product, five public surfaces, cited findings table with fix language, 72 hours, $199, pay after delivery if it's useful. Documentation review, not legal advice. The sample report shows the exact format.

But honestly: run the 5-minute check first. If it comes back clean and you don't move money, you're probably fine. If it doesn't — you want to know before your customers' lawyers do.