How a document trust score actually works: what passes, what fails, and why
A trust score on a processed document isn't a black-box confidence number. Here is what actually gets checked, and why a score starts high and only goes down.
A "trust score" attached to a processed document can mean almost anything, depending on the vendor — a vague confidence number, a marketing dial, or an actual audit of the document against real rules. The distinction matters because only one of those is useful for deciding whether a document needs a second look before it's posted.
The mechanism: start at full trust, deduct for specific failures
A well-built trust score doesn't start at zero and build up evidence of trustworthiness — it starts at the maximum score and deducts points for each specific, named problem the document actually has. This inversion matters: a document with no deductions earns full trust because nothing was found wrong with it, not because an opaque model decided it "felt" trustworthy.
Each deduction is tied to a concrete, checkable fact, not a vibe:
- A missing or invalid legal identifier (a business registration number that fails its own checksum, or is simply absent where the jurisdiction requires one)
- An invalid or missing amount or date — a document where the core numbers don't parse cleanly
- An unidentified supplier — no recognizable legal entity form attached to the vendor name
- A suspicious bank detail — an account number that doesn't validate against its own check algorithm
- Suspiciously round amounts appearing repeatedly — a pattern more consistent with an estimate than a real transaction
- A tax or VAT rate that doesn't match what's typically applied to the type of supply described
Every one of these is independently checkable against the document's own extracted content — none of them require comparing to an external database or trusting a black-box judgment call.
| Deduction trigger | What it actually catches |
|--------------------|----------------------------|
| Missing/invalid legal identifier | A business registration number absent or failing its own checksum |
| Invalid or missing amount/date | A core field that didn't parse cleanly |
| Unidentified supplier | No recognizable legal entity form on the vendor name |
| Suspicious bank detail | An account number failing its own validation algorithm |
| Repeated round amounts | A pattern more consistent with an estimate than a real transaction |
| Mismatched tax/VAT rate | A rate inconsistent with the type of supply described |
What the resulting level actually means
A reviewer doesn't want to interpret a raw number — they want an immediate read: high, medium, low. Getting there well usually means TWO related but distinct outputs, not one: a deduction-based score like the one above (useful on its own, and often surfaced as a letter grade), and a separate, structured breakdown across specific compliance axes — legal-identifier validity, tax/VAT coherence, duplicate risk, payment-detail integrity — that's what actually determines the high/medium/low bucket a reviewer sees. High means every applicable axis came back clean for that document's type and jurisdiction. Medium means a non-critical axis flagged something worth a glance. Low means an axis that matters (legal-identifier validity, a core amount that didn't parse) actually failed. Treating these as one seamless pipeline rather than two related engines feeding a shared verdict is exactly the kind of internal detail worth asking a vendor to actually explain, not assume.
Why "jurisdiction-specific" isn't a footnote — it's the whole point
A US invoice has no French-style VAT rate to validate, and a French invoice has no EIN to check. A trust score that applies the same checklist to every document regardless of where it's from either checks things that don't apply (false positives) or misses things that do (false negatives that matter more). The checks that fire for a given document should be determined by that document's own jurisdiction, not a single global rule set applied everywhere.
What a trust score is not
It's not a fraud verdict — a document can score high and still be part of a fraud pattern that only shows up across multiple documents (a duplicate, an unusual amount relative to history). Those are separate checks that compare a document to OTHER documents, not to itself, and a single-document trust score by design doesn't see that. A complete review needs both: what's wrong with this document on its own, and what's wrong with this document relative to everything else this vendor or account has submitted.
Related reading
- Vendor fraud red flags every audit should catch
- Inside a 54-point audit control framework: what auditors actually check, and why each one has a legal source
- What a health/trust score actually catches that a human reviewer misses
FAQ
Can a document with a low trust score still be legitimate?
Yes — a low score means a specific, named check failed, not that fraud is confirmed. A legitimate invoice with a genuinely unusual but real bank detail change, for example, would score low and still turn out to be entirely valid once a human confirms it. The score is a prioritization signal, not a verdict.
Does the score change after a human reviews and corrects the document?
The underlying checks are re-evaluated against the corrected data, so yes — fixing what was actually wrong (a mistyped amount, a corrected legal ID) changes the score, because the score reflects the document's current state, not a frozen first impression.
Is a high score a guarantee the document is accurate?
No — it's a guarantee that none of the specific, checkable problems the system looks for were found. A sophisticated fake designed to pass every mechanical check would still score high; the score narrows what needs human attention, it doesn't replace human judgment on documents specifically engineered to evade it.