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 policy before the first logical submission 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 declared finding under the document’s policy. Warnings may remain.
needs_review: a usable result exists and at least one finding requires review.
failed: no usable result was produced.

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.

Line-item policy

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

[data-code-tabs-interactive] { display: none !important; }

API

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

SDK

{
  policy: { lineItems: 'advisory' }
}

CLI

temlavo process invoice.pdf --line-items advisory

policy.line_items

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

Value	What it does
`advisory`Default	Keeps eligible row-local arithmetic failures and conflicts as warnings. Only findings wholly localized to eligible line-item paths qualify; mixed row/invoice findings, currency inconsistencies and other protected blockers keep their severity.
`review_on_failure`	Makes applicable row calculation failures or conflicting row values require review. Does not require rows to exist; partial or unavailable optional line items alone do not block completion.
`required`	Preserves blocking row failures and requires minimum usable data: At least one public row exists and `data.line_items_status` is `complete`. Every row has a non-null public `line_total`; zero and negative totals count. Every row has a non-blank description or product code. No blocking or unresolved material row issue prevents acceptance. Unresolved coverage, a whole row, its total or all usable identifiers requires review. Optional quantity, price, unit, discount or row-tax ambiguity alone is not promoted.

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.

[data-code-tabs-interactive] { display: none !important; }

API

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

SDK

{
  policy: {
    requiredFields: ['/data/invoice/purchase_order_number']
  }
}

CLI

# Repeat --required-field for each field you need.
temlavo process invoice.pdf --required-field /data/invoice/purchase_order_number

policy.required_fields

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

Value	What it does
`[]`Default	Adds no requirements. The global baseline still requires supplier name, invoice number, issue date, invoice currency and total.
Array of supported field paths	Adds those fields to the baseline. If a required field cannot be resolved, the result requires review. Paths must be unique JSON Pointers from the allowlist; accepted paths are sorted. PO number required → unresolved → `needs_review` See supported invoice fields

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.

[data-code-tabs-interactive] { display: none !important; }

API

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

SDK

{
  policy: { checks: { duplicateDetection: true } }
}

CLI

temlavo process invoice.pdf --duplicate-detection true

policy.checks.duplicate_detection

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

Value	What it does
`true`Default	Runs exact-document and likely-invoice duplicate checks. 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; failed attempts do not. History has no automatic expiry; document deletion or account closure removes the corresponding entries.
`false`	Skips both duplicate checks and does not add this submission to duplicate history. Earlier duplicate-history entries are not erased. Disabled checks are omitted, not returned as passes. Use 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 private account Playground 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.

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.