Temlavo

Resources · Review policy

Configure the document’s review policy.

Choose how line-item findings, required invoice fields, and duplicate detection affect each document’s review outcome. Policy changes acceptance behavior, not extraction effort or accuracy.

On this page

Policy at a glance

Default policy
{
  "required_fields": [],
  "line_items": "advisory",
  "checks": {
    "duplicate_detection": true
  }
}

You may omit policy or individual members; the server applies defaults and returns the complete normalized policy. The accepted policy is immutable for that document.

Choose the policy before you first submit an invoice, and preserve the same submission options for retries. See idempotency guidance for request identity and recovery.

API and SDK tabs below show policy fragments. CLI commands assume temlavo is installed and INVOICE_API_KEY is set.

How policy affects the result

  • completed: A usable result with no blocking check. Warnings may remain.
  • needs_review: A usable result with at least one blocking check.
  • failed: No usable result was produced. This status is final.

A check blocks when its severity is review and its status is not pass. Other protected invoice-level checks still apply independently; completion does not certify accuracy or authorize payment.

See every check and which ones policy can change.

Line-item policy

Choose how line-item findings affect review and whether usable item-level data is required.

policy.line_items
{
  "policy": { "line_items": "advisory" }
}

policy.line_itemsstringDefault advisory

How line-item findings affect review, and whether usable line items are required.

advisoryDefault
Eligible row findings stay warnings and don't block completion. That covers line_item_arithmetic and line_items_sum_consistency failures, and row conflicts that lie wholly on line-item paths. Mixed row and invoice findings, currency inconsistencies and other protected blockers keep their severity.
review_on_failure
Row calculation failures, conflicting row values, and rows that add up to neither the subtotal nor the total require review. Missing rows alone don't. A partial or unavailable item list alone doesn’t block either.
required
Row failures block, and the result also needs complete line items: at least one row, each with a line total and a description or product code. Complete means data.line_items_status is complete; zero and negative line totals count. Which unclear row values then require review is listed under semantic_issue.

required does not independently verify that every source row was captured. All modes use the same extraction and applicable checks, on every plan.

Required fields

Require supported invoice fields your workflow depends on, in addition to Temlavo’s global critical baseline.

policy.required_fields
{
  "policy": {
    "required_fields": ["/data/invoice/purchase_order_number"]
  }
}

policy.required_fieldsarray of stringsDefault []

Invoice fields that must be present, as JSON Pointer paths such as /data/invoice/purchase_order_number. A required field that comes back null makes the document need review. See the fields you can require. They add to a baseline that is always required: /data/vendor/name, /data/invoice/number, /data/invoice/issue_date, /data/invoice/currency, and /data/totals/total. For example, PO number required → unresolved → needs_review. Paths must be unique; accepted paths are sorted.

Items
up to 17, unique

Each one of17 supported values

This cannot remove the baseline or accept arbitrary JSON paths, and does not change extraction effort. Ordinary missing optional fields do not become warnings just because they are absent.

Duplicate detection

Choose whether this submission participates in duplicate checks and duplicate history.

policy.checks.duplicate_detection
{
  "policy": { "checks": { "duplicate_detection": true } }
}

policy.checks.duplicate_detectionbooleanDefault true

Whether this document takes part in duplicate checks. false skips both duplicate checks and adds nothing to your duplicate history.

trueDefault
Runs exact_document_duplicate and possible_invoice_duplicate; a match requires review. Matching stays within the authenticated account and the supplied accounting-entity scope; without an entity, the default namespace does not cross-match a supplied entity or another account. Enabled completed and needs_review submissions enter duplicate history and failed attempts do not. History has no automatic expiry; document deletion or account closure removes the corresponding entries.
false
The checks are omitted, not returned as passes, and earlier duplicate-history entries are not erased. Use it for intentional resubmission or reprocessing. It does not change extraction or normal usage charging; an exact idempotency replay still returns the same resource.

Exact matching uses the source fingerprint. Likely matching uses normalized supplier name and invoice number from a clear invoice candidate, excluding identities affected by model issues. It is not fuzzy matching and does not match by date or amount.

The Playground, in your account or the public demo, forces duplicate detection off for repeatable testing. Evaluate duplicate behavior through an API or n8n integration.

What policy does not configure

Review Policy is not a generic custom rules engine. Global critical fields, classification, invoice-level consistency, currency/date/tax checks, protected semantic issues and processing failures keep their documented behavior. These settings do not redefine invoice.v1, certify extraction correctness or authorize payment. The checks reference lists each check and how it is controlled.

Configure it in your integration

Policy meaning is shared. These guides cover syntax and operation:

  • SDK + CLI: the SDK supports the complete model through requiredFields, lineItems and checks.duplicateDetection. The CLI exposes --line-items, repeatable --required-field and --duplicate-detection true|false.
  • Raw HTTP: send the complete policy object or selected members in the create body.
  • n8n: adapted create requests use the same API policy object. The supplied adapter exposes a saved line-item mode; other members need explicit adaptation and the same snapshot-and-reuse treatment for retries.
  • Create document API reference: exact wire parameters, defaults and request requirements.