Document compliance checks
Tavnit's Inspector checks a set of documents against a checklist you define. It routes each uploaded file to its expected slot, extracts what the rules need, and evaluates the checklist deterministically — so the same evidence always produces the same verdict, with a report attached.
Why this is painful
Compliance review is usually a person with a checklist and a folder, confirming that the right documents are present, that the values agree across them, and that nothing has expired. It is slow, it is inconsistent between reviewers, and the evidence for why something passed is whatever that person remembers.
The failure mode is not usually a missed document. It is a value that disagrees between two documents nobody compared side by side.
What to extract
| Field | Why it needs care |
|---|---|
| Expected document slots | What the set should contain. A missing required slot is itself a finding, not just an absence. |
| Identity and entity fields | The values that must agree across documents — names, registration numbers, addresses. |
| Dates and expiry | Certificates and licences expire. Whether something is in date is a rule, not a field. |
| Amounts and declared values | Cross-document consistency checks live here: does the invoice value match the declaration? |
| Signatures and stamps present | Presence rather than content, and one of the more common manual checks. |
| Checklist outcome per item | Pass, fail or not applicable, per rule, with the value that drove it. |
What makes compliance checks hard
The real check is between documents, not inside one
Any tool can read a value off a certificate. The finding that matters is that the value on the certificate disagrees with the one on the invoice. Because an inspection collects a whole set before it evaluates, checklist rules can compare across documents rather than only within one.
Checklists branch, and flat ones hide gaps
Whether a rule applies usually depends on an earlier answer — if the goods are restricted, then a licence is required. A branched checklist expresses that directly, so an inspection asks for the licence only when it is actually needed and does not quietly mark it not-applicable.
An auditor asks how you decided, not what you decided
Evaluation is deterministic — the same documents produce the same result rather than a fresh judgement each time — and the outcome is written to a report. Combined with review, you can show which values were extracted, which rules fired and who approved the result.
How the pipeline handles it
- Collections — Mixed evidence arriving in one place gets classified and routed to the right flow before any checking happens.
- Flows — Each document type has its own flow, so a rule can reference a named field rather than searching free text.
- Human in the Loop — A reviewer signs off the inspection, and the append-only trail records who accepted which finding.
- Buckets — Outcomes over time become reportable — how many sets failed, on which rule, in which month.
Common questions
- Can it compare values across different documents?
- Yes — that is the point. An inspection collects the whole document set before evaluating, so rules can check that a value on one document agrees with a value on another rather than only validating each in isolation.
- Is the result repeatable?
- Checklist evaluation is deterministic. The same documents and the same checklist produce the same outcome, which is what makes the result defensible when someone asks why a set passed.
- What if a required document is missing?
- A missing required input is itself a finding. The inspection reports it rather than completing with a gap, and files uploaded without a named slot are routed automatically or flagged as unmatched.
Other document types
Try it on one document
Build a flow, send a real compliance check through it, and see what comes back. Free credits to start.
Start free