Template Hierarchy
Meridian runs four entities across four countries. The US and UK have their own invoice templates; India's is still on the to-do list. So what happens when each entity generates an invoice? A four-tier resolution answers it — specific wins over general, and there's always a safety net.
Access you'll need. Anyone who can open a record can generate it and read which template resolved. Setting up the templates and their scope requires the Accounting Admin v2 or Accounting Controller v2 permission set; the Accounts Payable v2, Accounts Receivable v2, and Read Only v2 sets can view templates but not change them.
The four tiers
Tier 1 — The document's own override
If someone set the record's PDF Template field, that template wins (as long as it's active). This is the per-document exception — a special layout for one key account.
Tier 2 — The entity's template
An active template scoped to the document's entity with the matching document type. The everyday winner: Meridian US invoices wear Meridian US — Sales Invoice.
Tier 3 — The territory's template
No entity template? An active template scoped to the entity's territory steps in — one "Europe" template can dress every European entity until each gets its own.
Tier 4 — The built-in default
Nothing configured at all still produces a complete, professional document from the entity's branding (the generation screen shows Default as the template). No configuration can ever leave you unable to send an invoice.
Two fine points about Tier 1 worth knowing before you rely on it. First, the override only counts while its template is active — point a document at a deactivated template and resolution quietly continues down the ladder as if the field were blank. Second, the field is guarded: it only accepts active templates whose Document Type matches the record, so an invoice cannot be dressed as a receipt by accident. An invoice shows "Selected template must match Document Type "Sales Invoice" and be active." (payment vouchers and purchase orders name their own types); a cash receipt refuses with "PDF Template must be of type "Cash Receipt"." — a rule that holds even when records arrive through imports and integrations.
The ladder at work: three Meridian invoices
Same group, same day, three different resolutions:
| Invoice | What's configured | What the generation screen shows |
|---|---|---|
| MSI001021 — NovaTech, $9,800, Meridian US | The US entity has its own invoice template | Template: Meridian US — Sales Invoice (Tier 2 — the entity's template) |
| An invoice from Meridian's India entity | No entity template yet; the territory has a regional fallback | The territory's invoice template (Tier 3) — branded paper without waiting for the entity's own design |
| An invoice where someone filled the record's PDF Template field | An explicit choice on the document | That template, by name (Tier 1) — as long as it's active and invoice-type |
And if Meridian stood up a fifth entity tomorrow with nothing configured at all? Tier 4: its invoices would still generate, complete and professional, on the entity's letterhead — the screen's Template row reading Default.
Inside a tier: the language match
When several templates exist at the same tier — say English and French invoice templates on one Canadian entity — the customer decides: generation compares the templates' Language/Locale tags to the customer's language settings, preferring the closest match (locale beats language beats untagged), then falls back to the one marked Is Default. One entity, per-customer paper, zero effort at invoice time.
Precisely: templates matching both the account's language and locale win first; failing that, a locale match; failing that, a language match; failing that, the whole pool competes. Among the survivors, Is Default breaks the tie, and among several Defaults, the oldest template wins. "The customer" means the account the paper is addressed to — the customer on invoices, credit memos, and receipts; the vendor on payment vouchers and purchase orders. If your customers' language settings aren't maintained, the tags have nothing to match against and everyone gets the Default — tag templates and keep account languages current, or do neither.
A note on statements
Statement-of-account exports resolve the same way minus the per-document override (a statement isn't a record) — entity Statement template, then territory, then the default shell. There's no language match either: within a tier, the Default (or oldest) Statement template simply wins.
Common mistakes to avoid
| Mistake | Why it hurts | Do this instead |
|---|---|---|
| Using per-document overrides as the everyday branding mechanism | Every new document needs a manual choice — forget one and it silently wears the entity or territory template instead | Configure entity/territory templates for the standing answer; reserve the override for genuine exceptions |
| Forgetting an override once it's set | The document keeps its explicit template even after you build better entity templates — one invoice stays stuck in last year's design | When retiring a template, search for documents naming it and clear their PDF Template field |
| Deactivating a template as a way to "switch off" branded output | Resolution doesn't stop — it falls to the next tier, so paper changes appearance without anyone deciding it should | Have the replacement active first; treat Is Active as a routing decision, not a pause button |
| Tagging templates by language while customer accounts carry no language settings | The match has nothing to compare — every customer gets the Default and the variants never print | Roll out account language/locale data together with the tagged templates |
| Marking several templates Default in one pool | The oldest silently wins; six months later nobody can say why paper looks the way it does | Exactly one Default per entity (or territory) and document type |
Where to go next
- PDF Template Configuration — what each template controls.
- Entity-Specific Branding — the layer that always applies, template or not.
- Generating PDFs — watching resolution happen on the generation screen.
Frequently asked questions
The Generate PDF screen names the resolved template (or Default) before rendering — generate once and read the Template row. For a standing answer, set the record's PDF Template field explicitly.
The customer-language match first; among equals, the one marked Is Default; among defaults, the oldest. Practical advice: keep exactly one Default per entity/type and the question never arises.
Because paper is legal-entity paper — letterhead, tax wording and language differ by company and country. The territory tier gives you the "one template for many entities" convenience without pretending a global document exists.
The named template is almost certainly inactive — an inactive override is skipped and resolution continues down the ladder. Reactivate the template (or pick an active one) and regenerate.
Yes — the button, posting-time auto-generation, and the Generate PDF Document flow action all run the same resolution. A document produces the same paper no matter which path generated it.
The vendor's — the match always reads the account the document is addressed to. Customers decide invoices, credit memos, and receipts; vendors decide payment vouchers and purchase orders.
Was this article helpful?