Resources · Checks

Every check Temlavo runs on an invoice.

Each result lists its checks in validation.checks. These 12 checks cover arithmetic, currency and dates, duplicates, document type, extraction issues, required data, and line-item coverage. Each one is marked with whether your review policy can change it.

On this page

How checks work

Every check has a status (pass, fail or not_evaluable) and a severity (info, warning or review).
A check blocks when its severity is review and its status is not pass. Any blocking check makes the result needs_review; warnings leave it completed.
When an arithmetic check’s inputs are missing or unclear, it is not_evaluable with info severity. A missing amount is never calculated and added to the result.
Money math uses exact decimals, never floating point. Evaluated arithmetic checks return the equation, the calculated value and the difference.
Field findings list the affected paths, so you can highlight the exact values in your own review screen.

Excerpt from the Total mismatch sample

{
  "code": "total_consistency",
  "status": "fail",
  "severity": "review",
  "message": "Subtotal and adjustments do not reconcile with the invoice total.",
  "paths": [
    "/data/totals/total"
  ],
  "details": {
    "equation": "subtotal - discount + shipping + other_charges + tax = total",
    "reason": "evaluated",
    "actual_total": {
      "amount": "1006.80",
      "currency": "USD"
    },
    "calculated_total": {
      "amount": "1036.8",
      "currency": "USD"
    },
    "difference": {
      "amount": "-30",
      "currency": "USD"
    }
  }
}

Branch on status, severity and validation.review_required, not on message text. New check codes may be added over time.

Arithmetic

Recalculates invoice, tax and row equations from the extracted amounts with exact decimal math.

Check	What it catches	Result
`line_item_arithmetic`Severity set by line-item policy	A row’s quantity × unit price does not equal its line total.	Warning under `advisory` (default); requires review under `review_on_failure` and `required`. Exact results and the currency’s standard minor-unit rounding are accepted. See the Row warning sample
`tax_arithmetic`Always on	A tax line’s taxable amount × rate does not equal its tax amount.	Requires review. Exact results and the currency’s standard minor-unit rounding are accepted.
`total_consistency`Always on	The invoice total does not equal subtotal − discount + shipping + other charges + tax, or the same without tax when amounts include it.	Requires review. Additions are exact, with no rounding tolerance. See the Total mismatch sample

Currency and dates

Catches mixed currencies and dates that cannot both be right.

Check	What it catches	Result
`currency_consistency`Always on	Amounts, or the invoice currency and its amounts, use different currencies.	Requires review. Amounts are never relabeled or converted.
`date_consistency`Always on	The due date is earlier than the issue date.	Requires review. Runs when both dates are present.

Duplicates

Compares each submission with earlier completed or needs-review submissions that had duplicate detection on, in the same account and accounting entity.

Check	What it catches	Result
`exact_document_duplicate`On by default · can be turned off	The same source file was submitted before.	Requires review. Returns the earlier document ID.
`possible_invoice_duplicate`On by default · can be turned off	An earlier invoice has the same supplier name and invoice number, even if it arrived as a different file.	Requires review. Returns the earlier document ID. Matching is not fuzzy and does not use dates or amounts. See the Possible duplicate sample

Document type

Checks that the upload is one invoice before its data is trusted.

Check	What it catches	Result
`document_classification`Always on	The upload may not be a single invoice.	Requires review. A clear non-invoice, such as a receipt, or an upload with several invoices fails instead and is not billed.

Extraction issues

Surfaces values the model found conflicting, ambiguous or unreadable instead of silently picking one.

Check	What it catches	Result
`semantic_issue`Severity depends on policy	The model reports printed values that conflict, or that are ambiguous or unreadable.	Conflicts and unclear values in required fields require review; other unclear values are warnings. Under `advisory`, conflicts confined to line items are warnings. Under `required`, unclear item coverage, a whole row, a row total or a row’s only usable identifier requires review.

Required data

Requires the fields every invoice needs, plus any fields your workflow depends on.

Check	What it catches	Result
`critical_field_unresolved`Always on	A field every invoice needs could not be resolved: `/data/vendor/name`, `/data/invoice/number`, `/data/invoice/issue_date`, `/data/invoice/currency`, `/data/totals/total`.	Requires review. This baseline cannot be turned off.
`required_field_unresolved`Added by your policy	A field you required, such as the PO number, due date or customer tax ID, could not be resolved.	Requires review. Choose from 17 supported fields in `policy.required_fields`. See the Missing PO number sample

Line-item coverage

Requires usable item rows when your workflow cannot accept a header-only result.

Check	What it catches	Result
`line_items_requirement`Added by your policy	No rows, an item list marked partial or unavailable, or rows missing a line total or with neither a description nor a product code.	Requires review. Runs only when `policy.line_items` is `required`.

What checks do not do

Checks compare the extracted values with each other. They do not re-read or independently verify the source document, so completed is not a guarantee of accuracy or approval to pay.
Tax arithmetic checks the math on the invoice, not tax compliance.
Amount due is not checked against the total, because payments, credits and earlier balances can legitimately change it. Row totals are not summed against the subtotal.
Review policy changes how some checks affect the outcome; it is not a custom rules engine. Configure review policy.