Use Cases & Examples

Enterprise Feature

This feature is available in Unstract Cloud Edition and Unstract On-Premise Edition.

This page collects common Look-Up scenarios with sample templates you can adapt. Each example shows the problem, a working template, the variable mappings to wire up, and any reference files you'd need.

If you're new to Look-Ups, start with Vendor name canonicalization. It's the most common starting point and demonstrates every moving part.

1. Vendor name canonicalization

Single variable, with reference file.

Your accounts-payable workflow extracts vendor names from invoices, but the same vendor appears under many spellings (ACME Corp, Acme Corporation, acme inc.). Your ERP needs the canonical name from the vendor master.

Reference file. vendor_master.csv, your list of approved vendors with canonical names (and optionally aliases, IDs, payment terms).

Source prompt. A prompt named vendor_name that extracts the vendor name from the invoice.

Look-Up template:

You are matching a vendor name extracted from an invoice to our
canonical vendor master.

Extracted name: "{{input.vendor_name}}"
Vendor master:
@vendor_master.csv

Return only the canonical vendor name from the master that best
matches the extracted name. Match on full names, common aliases,
and minor spelling variations. If no confident match exists,
return the extracted name verbatim. Do not invent a match.

Variable mapping. vendor_name points to the vendor_name prompt.

This is a good first Look-Up to build because it has one variable, one reference file, and a clear fall-back rule, and it works in both standard and Single Pass modes.

2. GL account / cost-center coding for invoice line items

Multi-variable, Single Pass required, with reference file.

Each invoice line needs to be coded to a general-ledger account and a cost center based on the line description and the vendor. The mapping rules live in your accounting policy.

Reference file. chart_of_accounts.md, your account list with descriptions of what each account is used for, plus any vendor-specific rules.

Source prompts. A vendor_name prompt and a line_description prompt.

Look-Up template:

Determine the correct general-ledger account code for this
invoice line.

Vendor: "{{input.vendor_name}}"
Line description: "{{input.line_description}}"

Chart of accounts and coding rules:
@chart_of_accounts.md

Return a JSON object with two keys: "gl_account" (the account
code) and "rationale" (one short sentence explaining why this
account was chosen). If the line cannot be coded confidently,
return "gl_account": "UNCODED" and explain in the rationale.

Variable mappings. vendor_name points to the vendor_name prompt; line_description points to the line_description prompt.

Single Pass required

This template uses two {{input.X}} placeholders, which makes it a multi-variable Look-Up. Enable Single Pass extraction in the project settings before publishing, or runs and Export will both be blocked.

3. HSN / tariff code classification

Single variable, with reference file.

Customs and shipping documents describe goods in free text ("5kg organic basmati rice, vacuum packed"), but your customs broker needs a specific HSN/HS tariff code from a controlled list.

Reference file. hsn_codes.csv, the relevant slice of the HSN code book for your industry, with code, description, and any internal notes.

Source prompt. A product_description prompt.

Look-Up template:

Classify the product description below to the most accurate HSN
code from our reference list.

Product description: "{{input.product_description}}"
Reference HSN codes:
@hsn_codes.csv

Return only the HSN code (no description, no commentary). Choose
the most specific code that fits the description. If two codes
are equally plausible, prefer the more specific one. If no code
in the reference fits, return "UNKNOWN".

Variable mapping. product_description points to the product description prompt.

tip

Keep the reference list scoped to your industry (food, electronics, textiles, and so on) rather than uploading the full HSN codebook. Smaller, focused reference data produces noticeably better matches and lower token usage.

4. ISO country & currency code normalization

Single variable, no reference file.

Documents mention countries and currencies in dozens of forms (USA, United States, U.S.A., the States; $, USD, dollars). Your data warehouse expects ISO 3166-1 alpha-2 country codes and ISO 4217 currency codes.

Reference file. None. This mapping is universal knowledge the LLM already has reliably.

Source prompt. A country_text prompt (or currency_text, and so on).

Look-Up template:

Convert the country reference below to its ISO 3166-1 alpha-2
country code.

Country: "{{input.country_text}}"

Return only the two-letter uppercase ISO code (for example "US",
"IN", "DE"). Handle common variations, abbreviations, and
informal references. If the input is ambiguous or doesn't refer
to a country, return "XX".

Variable mapping. country_text points to the prompt that extracts the country reference.

The same pattern works for currencies (USD, EUR, INR), units of measure (kg, lb, oz), or any other well-known controlled vocabulary. Use a Look-Up rather than a regular prompt so the Raw and Enriched values are both retained for auditing.

5. Status / category vocabulary normalization

Single variable, no reference file.

Documents use inconsistent wording for the same status. Your reporting layer wants exactly four values: PAID, PARTIAL, OUTSTANDING, OVERDUE.

Reference file. None. The vocabulary is small enough to define inline in the template.

Source prompt. A status_text prompt.

Look-Up template:

Normalize the status text below to one of our four standard
status values.

Status text: "{{input.status_text}}"

Allowed values:
- PAID: fully paid, settled, cleared, payment received in full
- PARTIAL: partially paid, deposit received, advance taken
- OUTSTANDING: unpaid, due, awaiting payment, not yet due
- OVERDUE: past due, late, in arrears

Return only one of the four values above. If the text is
ambiguous or doesn't describe a payment status, return
"OUTSTANDING".

Variable mapping. status_text points to the status prompt.

This pattern works for any controlled vocabulary: document classifications, urgency levels, sentiment categories, dispute reasons. Bake the rules into the template itself; no reference file needed.

Tips for writing reliable Look-Up templates

A few patterns pay off across all Look-Ups.

Always include a fall-back rule. Tell the LLM exactly what to return when no confident match exists. For example: return the input verbatim, return "UNKNOWN", return "UNCODED". Without one, models hallucinate.

Be explicit about the output shape. Vague instructions yield verbose responses that downstream systems can't parse. Concretely:

• State the expected form. For example, Return only the canonical name, Return a two-letter ISO code, or Return a JSON object with keys "gl_account" and "rationale".
• Forbid extra commentary. Phrases like no explanation, no description, or do not include reasoning keep responses tight.
• Match the prompt's Enforce Type. If the prompt is set to JSON, instruct the template to return a JSON object so type conversion lands cleanly.

Quote variable values in the template. Wrap placeholders in quotes ("{{input.foo}}") so the LLM treats them as the input being processed, not as instructions.

Scope reference files tightly. A 1 MB chart of accounts focused on your business produces better, cheaper matches than a 9 MB enterprise-wide ledger dump. The smaller the relevant context, the better the LLM does.

Test before linking. Use the test panel on the Look-Up detail page to iterate against ad-hoc values before linking to a prompt or running a full project.

Reuse Look-Ups across projects. A vendor-canonicalization or country-normalization Look-Up is the same logic everywhere. Define it once, link from many prompts and projects, and version it in one place.