Company Name Canonicalization Prompt Template

This prompt is designed for CRM integrators, data engineers, and identity resolution pipeline operators who need to convert inconsistent, noisy company names from model outputs into a single, reliable canonical legal entity name. The core job-to-be-done is to take a raw company name string—often containing trade names, abbreviations, legacy suffixes, or subsidiary designations—and map it to a standardized, deduplicatable record suitable for ingestion into a system of record like Salesforce, HubSpot, or a master data management (MDM) platform. The ideal user is someone building an automated data pipeline where AI models extract company names from emails, contracts, or web forms, and those names must be cleaned before they can be used for account matching, reporting, or routing.

Use this prompt when you have a reference list of known legal entities and need to perform fuzzy matching against it, or when you need to enforce suffix standardization (e.g., 'Inc.' vs. 'Incorporated'), entity type normalization (e.g., 'LLC' vs. 'L.L.C.'), and subsidiary-to-parent resolution. The prompt is particularly effective as a post-extraction repair step in a broader output validation pipeline, where a prior model has already attempted to extract a company name but produced a non-canonical form. It is not a replacement for a dedicated entity resolution service or a vector search over a company database; it is a prompt-level normalization layer that reduces the error rate before records hit those systems.

Do not use this prompt when the input is a completely unknown entity with no reference list, when the legal entity structure is ambiguous and requires human legal review, or when the cost of a false match is high and cannot be mitigated by a downstream human approval step. This prompt is also not suitable for real-time, sub-100ms latency requirements without caching, as the fuzzy matching and reasoning steps add non-trivial token processing time. For high-risk financial or compliance workflows, always pair this prompt with a human review queue and log every canonicalization decision with its confidence score and evidence for auditability.

This prompt template accepts a raw company name string extracted from a model output and returns a canonicalized version suitable for CRM ingestion. It standardizes suffixes (Inc., LLC, Ltd.), normalizes entity type variations, resolves common abbreviations, and optionally matches against a provided reference list of known legal entities. The template is designed to be dropped into a post-generation repair pipeline where company names arrive in inconsistent formats from upstream extraction or generation steps.

codeCopy
You are a company name canonicalization engine. Your job is to normalize a raw company name into its standard legal entity form.

INPUT COMPANY NAME:
[INPUT]

REFERENCE COMPANY LIST (optional, for fuzzy matching):
[REFERENCE_LIST]

NORMALIZATION RULES:
1. Expand common abbreviations: Corp -> Corporation, Inc -> Incorporated, Ltd -> Limited, LLC -> Limited Liability Company, Co -> Company.
2. Standardize suffix placement and punctuation: remove trailing periods after suffixes, ensure consistent comma placement before entity type.
3. Normalize entity type variations: 'LLC' and 'L.L.C.' both become 'LLC'; 'Inc' and 'Inc.' both become 'Inc.'.
4. Remove noise tokens: trailing whitespace, double spaces, leading/trailing special characters.
5. Preserve case as provided unless the reference list specifies a different casing.
6. If a [REFERENCE_LIST] is provided, attempt fuzzy match against it. Return the matched canonical name if confidence is high. If no match or low confidence, return the normalized form.
7. For subsidiaries and trade names, if the parent entity is identifiable, note the relationship in the output.

OUTPUT SCHEMA:
{
  "input_name": "[original input]",
  "canonical_name": "[normalized name or matched reference name]",
  "match_source": "normalized" | "reference_list" | "reference_list_fuzzy",
  "match_confidence": 0.0-1.0,
  "normalizations_applied": ["list of specific normalizations performed"],
  "subsidiary_of": null | "[parent company name if detected]",
  "trade_name_of": null | "[legal entity name if input is a trade name/DBA]",
  "warnings": ["any ambiguity flags or low-confidence notes"]
}

[CONSTRAINTS]
- Do not invent company names. If the input is ambiguous, flag it in warnings.
- If the input appears to be a person name rather than a company, set canonical_name to null and add a warning.
- If the input is empty or only whitespace, return canonical_name as null with an appropriate warning.
- Do not change the legal entity type unless you have evidence from the reference list.

[EXAMPLES]
Input: "Acme Corp"
Output: {"input_name": "Acme Corp", "canonical_name": "Acme Corporation", "match_source": "normalized", "match_confidence": 0.95, "normalizations_applied": ["expanded Corp to Corporation"], "subsidiary_of": null, "trade_name_of": null, "warnings": []}

Input: "Google"
Reference List: ["Google LLC", "Alphabet Inc."]
Output: {"input_name": "Google", "canonical_name": "Google LLC", "match_source": "reference_list", "match_confidence": 0.98, "normalizations_applied": ["matched to reference list entry"], "subsidiary_of": "Alphabet Inc.", "trade_name_of": null, "warnings": []}

Adapt this template by adjusting the [REFERENCE_LIST] to your CRM's known entity catalog. For high-volume pipelines, consider pre-loading the reference list into a vector store and using retrieval-augmented generation instead of inline listing. If your use case involves legal or compliance workflows, add a [RISK_LEVEL] parameter that triggers human review for low-confidence matches. The output schema fields can be extended with legal_jurisdiction, registration_number, or duns_number if your downstream system requires them. Always validate the JSON output against the schema before ingestion, and log any warnings for operational review.

This prompt is designed to sit inside a post-generation repair loop, not as a standalone normalization service. The typical integration pattern is: a model generates a raw company name string, your application extracts it, and this prompt is called to canonicalize it before the name enters your CRM, CDP, or identity resolution pipeline. The prompt expects a reference list of known legal entity names for fuzzy matching, plus optional context about subsidiaries, trade names, and the industry domain. Without a reference list, the model will still normalize suffixes and entity types, but it cannot resolve 'Google' to 'Google LLC' with high confidence—it will guess. For production, always provide a reference list sourced from your system of record.

Wire the prompt into a validation harness that checks the output schema before accepting the result. The expected output is a JSON object with fields: canonical_name (string), match_confidence (float 0-1), matched_reference_entity (string or null), normalization_actions (array of strings describing what was changed), and warnings (array of strings for ambiguous cases). After the model responds, validate that canonical_name is non-empty, match_confidence is a number between 0 and 1, and normalization_actions is an array. If validation fails, retry once with the validation error appended to the prompt as a correction hint. If the retry also fails, log the raw output and escalate to a human review queue. For high-volume pipelines, set a confidence threshold (we recommend 0.85 for fully automated ingestion) and route low-confidence results to a review UI where an operator can accept, override, or reject the canonicalization.

Model choice matters here. Use a model with strong instruction-following and JSON output support—GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro are good defaults. Avoid smaller models for this task because suffix standardization rules and subsidiary resolution require precise reasoning. If you are processing batch records, implement chunking with 50 records per request to stay within context limits while keeping per-record cost low. Log every canonicalization result with the input, output, confidence score, and whether it was auto-accepted or reviewed. This log becomes your audit trail for data governance and helps you tune the confidence threshold over time. Do not use this prompt for real-time user-facing name entry—it is designed for backend batch or async repair workflows where a few seconds of latency is acceptable.