Glossary

Stripe Invoice Template

An invoice rendering template is a reusable Stripe object that stores default memo, footer and custom field values, plus line item grouping rules, and applies them to every invoice it is attached to.

Also called: invoice rendering template, rendering template, invoice template, rendering_options

Start a free trial View Pricing

Definition

Most invoice fields are set on the invoice. A template is the object that sets them somewhere else, once, for a whole group of customers, and then stops being visible.

Stripe describes the purpose in terms of reuse and scale: templates let you "store and reuse common values for invoice fields instead of entering them for every relevant invoice" and "store, manage, and update invoice field values that apply to large sets of customers". The examples Stripe gives are all policy rather than decoration: displaying specific footer text "for customers from a particular country", a specific memo "for customers with a particular revenue channel", and grouping line items "for customers with complex transactions".

That is why a template belongs in a bookkeeping glossary rather than a design one. It answers a specific and otherwise unanswerable question: why does this invoice say something nobody remembers putting on it? The value was set months ago, on an object that is not the invoice, possibly by somebody who has left. Nothing on the finished document records that a template was involved.

On the invoice itself, the connection lives in `rendering`, which Stripe documents as "the rendering-related settings that control how the invoice is displayed on customer-facing surfaces such as PDF and Hosted Invoice Page". That field is the only trace, and it holds an identifier rather than an explanation.

Key points

+Stores memo, footer and custom field defaults, and applies them to every invoice using the template.
+Line item grouping rules cannot be configured anywhere else.
+Can only be created in the Dashboard; the API can apply one but not create one.
+Five layers of precedence resolve into the value a customer finally sees.
+Updating a template changes all future invoices attached to it, not past ones.
+Cannot be applied through the API to subscriptions, subscription schedules or quotes.

What a template can actually hold

The field list is short and worth knowing exactly, because the boundary is where most confusion starts.

Stripe states it plainly in the setup steps: "Invoice templates support the memo, footer, and custom fields." Three fields. A template is not a PDF designer, it does not carry branding, and it does not touch amounts, tax or line data.

The [customize invoices](https://docs.stripe.com/invoicing/customize) guide adds the account-level view of the same three. The memo is "included in invoice PDFs, invoice emails, and the Hosted Invoice Page", and a template value "replaces the default memo on invoices using a template". The footer is "an optional footer text block" that is "often used for contractual or legally required text", with a named example of "legally required company registration information, such as a UK Companies House registration number". Custom fields "allow you to provide up to four key-value pairs that display in the invoice header".

Then there is a fourth capability that is not a field at all, and it is the reason a template is sometimes the only option. Stripe lists it among the things templates are for: "Configure Line Item Grouping rules, which can’t be set outside of invoice rendering templates". Grouping is defined by Common Expression Language rules on the template, and there is no per-invoice equivalent. If you want grouped line items, you want a template, and no amount of work on the invoice itself will get you there.

Branding, by contrast, is elsewhere entirely. Logos, icons and colors are account-wide Branding settings, so two customers on different templates still receive documents with the same logo.

Dashboard only, which surprises API-first teams

This is the constraint most likely to derail a plan, and Stripe states it without qualification: "You can create invoice rendering templates only in the Dashboard. You can’t create them using the API."

So the object is split across two surfaces. Creation and editing are a Dashboard task, done under Billing settings in the Invoices Templates tab. Application is available through the API: a draft invoice takes `rendering[template]` with a template id, and a customer takes `invoice_settings[rendering_options][template]` to apply one "to all future invoices associated with that customer, including subscription-generated invoices".

A second API limit sits next to it: "You can’t use the API to apply invoice templates directly to subscriptions, subscription schedules, or quotes." Stripe names the workaround in the same breath, which is to attach the template to the customer instead, or apply it to invoices while they are still drafts. Applying a template to a subscription is possible, but the Dashboard is the only place to do it.

For anyone provisioning customers programmatically, the practical shape is that template ids are configuration rather than something your code creates. They get made once by a human, and your integration references them.

Five layers decide what the customer sees

Memo, footer and custom fields can each be set in more than one place, and Stripe publishes the resolution order. It is longer than most people assume, running from highest priority to lowest:

1. On the invoice (Dashboard or API), or on the subscription (Dashboard only). 2. A template applied to the invoice (Dashboard or API), or a template applied to the subscription (Dashboard only). 3. A template attached to the customer (Dashboard or API). 4. Invoice settings on the customer (API only). 5. Invoice settings on the account (Dashboard only).

Stripe summarises the behaviour as "defined invoice settings always apply unless overridden by a higher-priority setting", and spells out the consequence for one-off work: to create a single invoice that overrides the customer’s attached template, "you must either apply a different template to the invoice or set the invoice values directly".

Two things follow that are worth holding onto.

The first is diagnostic. When a field shows the wrong value, the question is not "what is on the invoice" but "which of five layers won". A blank field on the invoice does not mean the value came from the account default; it may have come from a template two levels up. The template preview has this same trap built in, and Stripe warns about it directly: previewing a template against a real invoice id shows "the invoice’s footer, not the template’s footer" if that invoice sets one, because "any values set directly on that invoice override the corresponding template value".

The second is about blast radius. Because layers 1 and 2 include settings that are Dashboard-only, an integration reading the API alone cannot always see why a value resolved the way it did. Anyone debugging from API responses should expect a Dashboard-set subscription value to be invisible to them.

Editing a template is a change to every future invoice

A template is a live object, not a snapshot taken at attach time, and that distinction is the one with accounting consequences.

Stripe: "When you update or replace a template, the new values apply to all future invoices associated with the template." The example given is a customer template whose new value then "applies to all future invoices for that customer’s existing subscriptions unless the subscription template overrides it".

So a one-line footer edit made to fix one customer’s paperwork propagates to every customer sharing that template on their next invoice. For a footer carrying "contractual or legally required text", that is a broader change than the edit feels like, and it is worth checking who else is attached before saving.

The scope is future invoices only. Documents already issued keep the values they were finalized with, which is the correct behaviour for an issued document and also means a template edit is never a way to correct an invoice already in a customer’s hands. That correction is a credit note or a revision, not a settings change.

One related freeze is worth knowing because it bounds the whole exercise. Custom fields inherited onto a draft can be modified "while the invoice is still a draft", but Stripe states that "after the invoice finalizes, you can’t update the custom fields", and the same restriction applies to the footer. Finalization is the moment the template stops mattering for that invoice.

Where a template sits relative to everything else on the invoice

It helps to be exact about what a template is not, since several nearby settings look like they belong to it and do not.

Payment methods are configured separately. The invoice template does hold the account default for which methods are offered, but the resolution of that list is its own mechanism, covered in [Stripe payment settings](/glossary/stripe-payment-settings).

PDF page size is not a template field. Stripe documents it as `rendering["pdf"]["page_size"]` on the invoice, set per invoice through the Invoice Editor’s advanced options or the API, with a default of "A4 for customers with a Japanese locale and Letter for customers with other locales".

Tax IDs are account-level, managed under Billing settings, with their own hard constraint: "After you add a tax ID, you can’t change the ID or type. To update a tax ID, delete it and add a new one."

And the numbers on the document come from somewhere else again. Invoice numbering is decided by prefix and sequence settings rather than by anything a template holds.

What remains, once those are set aside, is a small and specific object: three text fields and a grouping rule, applied by inheritance to a set of customers.

What reaches QuickBooks from a templated invoice

Acodei’s product documentation does not cover invoice templates or invoice rendering, and this entry does not claim otherwise. There is no documented behaviour for reading a template, resolving its precedence, or carrying a memo, footer or custom field into QuickBooks.

What is documented is the line data. When a Stripe invoice is finalized, Acodei creates a QuickBooks invoice reproducing every line item, and tax lines, as the account’s mapping settings allow, with each line using the product returned by Multiple Product Mapping if that is enabled and the default product otherwise.

So the sync’s documented scope and the template’s scope do not overlap. A template governs three text fields and how lines are displayed to the customer; the documentation describes the lines themselves being reproduced. If you need a value that currently lives on a template to be present in QuickBooks, confirm it in your own file rather than assuming, and treat a line item as the reliable carrier.

For the documented account of what carries into the QuickBooks invoice, see the invoice sync feature page.

Want to see this on your own Stripe data?

Start a free trial

Frequently asked questions

What is a Stripe invoice template?

An invoice rendering template is a reusable object that stores default values for an invoice’s memo, footer and custom fields, and that carries line item grouping rules. Stripe describes templates as a way to "store and reuse common values for invoice fields instead of entering them for every relevant invoice" and to "store, manage, and update invoice field values that apply to large sets of customers". Once attached, it applies to every future invoice for that customer or subscription.

Which fields can an invoice template set?

Three, plus one rule. Stripe states that "invoice templates support the memo, footer, and custom fields". Templates also configure line item grouping, which Stripe notes "can’t be set outside of invoice rendering templates". Templates do not carry branding, amounts, tax, PDF page size or tax IDs, all of which are configured elsewhere.

Can I create an invoice template with the API?

No. Stripe states that "you can create invoice rendering templates only in the Dashboard. You can’t create them using the API." The API can apply an existing template, either on a draft invoice through the rendering template parameter or on a customer through invoice settings rendering options, but the template itself has to be created and edited in the Dashboard.

Why does my invoice show a footer I did not set on it?

Because a lower-priority layer supplied it. Stripe resolves memo, footer and custom fields across five layers: the invoice or subscription first, then a template applied to the invoice or subscription, then a template attached to the customer, then invoice settings on the customer, then invoice settings on the account. Stripe puts it as "defined invoice settings always apply unless overridden by a higher-priority setting", so a blank field on the invoice means the value came from further down the chain.

What happens to existing invoices when I edit a template?

Nothing. Stripe states that "when you update or replace a template, the new values apply to all future invoices associated with the template". Already-issued invoices keep the values they were finalized with. The corollary is that an edit intended for one customer reaches every customer sharing that template on their next invoice, so check who is attached before saving.

Can I apply a template to a subscription through the API?

Not directly. Stripe states that "you can’t use the API to apply invoice templates directly to subscriptions, subscription schedules, or quotes". The documented alternatives are to attach the template to the customer, which applies it to all their future invoices including subscription-generated ones, or to apply it to invoices while they are still in draft status. Applying a template to a subscription is possible in the Dashboard.

Does Acodei carry template values into QuickBooks?

Acodei’s product documentation does not cover invoice templates or invoice rendering, so there is no documented behaviour to describe either way. What is documented is that a finalized Stripe invoice creates a QuickBooks invoice reproducing every line item and tax lines as your mapping settings allow, with each line using the product from Multiple Product Mapping if enabled and the default product otherwise. If a value you rely on lives on a template, confirm it in your own QuickBooks file rather than assuming.

What customers say about running Stripe through Acodei

★★★★★

“If you're testing out all the different Stripe/QuickBooks integration apps right now, let me save you some time. This one is the best one by far.”

RyanOwner at Indie Music Academy