Starter
For your first email program.
$16USD / month
$192 billed yearly.
20,000 emails / month
Choose Starter- 5 brands · 3 seats
- 5 custom sending domains
- 500 email verifications/month
- $1.50 / 1,000 extra emails
Concept emails designed for Linear, Canva, Headspace, Wise and Supabase using the Nitrosend MCP.1
Make one for your brand
Paste it into Claude, ChatGPT, Cursor or any AI with the Nitrosend MCP connected, and put your own website in place of [your website]. Which assistants work?
Using Nitrosend, design and build an invoice email for my brand, in the style of the concept emails on https://nitrosend.com/transactional-email/templates/invoice-email-templates My brand's website is [your website]. Read it for my logo, colours, fonts, products and tone of voice. If Nitrosend is not connected yet, read https://nitrosend.com/SKILL.md and follow it to connect the Nitrosend MCP server (https://api.nitrosend.com/mcp), then ask me to sign in or create a free account at app.nitrosend.com. On Claude.ai use claude.ai/directory/nitrosend; in ChatGPT, install the Nitrosend app. Then write and design the email in Nitrosend and send me a test.
What the standard invoice email carries
An invoice email template is a reusable message that delivers an invoice and states what is owed, when it is due, and how to pay it. The fields are below, and finished layouts are in the invoice email examples. It is one of the transactional email templates an app sends on its own billing events.
The subject line carries the invoice number, the sending business name and the due date. That combination lets a recipient find the message later by searching any one of the three.
The opening states the invoice number and what it is for. A recipient forwarding the message to their accounts payable team needs those two facts to survive being read out of context.
Three values do the work: the total amount due, the payment due date, and the accepted payment methods. Anything that delays a payment usually comes down to one of them being absent or ambiguous.
The invoice itself attaches as a PDF. A PDF renders identically everywhere and can be filed, which an HTML email body cannot, and many finance systems expect a document to attach to the payable record.
The body still needs a text alternative alongside the HTML. RFC 2046 defines multipart/alternative as parts that are each an alternative version of the same information, ordered by increasing faithfulness, and the receiving client picks. So the amount and the due date have to be right in every part you send, not only the one you previewed.
What the overdue reminder changes
The reminder restates the invoice number, the amount and the original due date, then says plainly that it is unpaid. It follows the general email notification template shape, with the money made explicit. Being specific about which invoice and which date is what separates a reminder from an accusation.
Re-attach the invoice rather than referring back to the earlier email. The original may have gone to a person who has left, been filed, or never arrived, and re-attaching removes a round trip.
Acknowledge that payment may have crossed with the reminder. Sending a reminder to someone who paid yesterday is the common case, and a sentence allowing for it prevents an unnecessary exchange.
State the next step and the date it applies. A reminder that ends without one invites the recipient to defer the decision, which is what produces the second and third reminder.
What changes when an AI agent fills the invoice template
When a person sends an invoice, they type the amount and read it before it goes. When an AI agent sends one, the template is filled at send time. The amount, the due date and the invoice reference come from billing data, and nobody reads the result unless the process puts a check in front of it.
Nitrosend's AI agent does most of the writing for an email, and a sender can ship email directly from their own agent. For an invoice, that moves the work from writing copy to defining fields. The copy is drafted once, in the template. What changes per send is the data, and the data comes from the billing record, never from the model.
An agent also retries. A send that times out gets tried again, so every invoice send carries an idempotency key.
And an agent can change the live template. Over MCP, nitro_manage_template creates, edits or clones a reusable email template. Exact edits pass template_id, section_updates and if_version, so an edit made against an old version is rejected instead of silently overwriting a template somebody just corrected.
Data the template must resolve
Every merge field needs a defined fallback or a check, because the field will eventually be empty. An invoice email that renders a blank amount or a missing due date is worse than no email, since it creates a query rather than a payment.
| Field | Source | Fallback | Fails as |
|---|---|---|---|
| Total amount due | Event envelope, from the billing record | None. Check it is present before the send | An empty block where the money was |
| Currency | Event envelope | None. Symbol and code together | An amount with no market |
| Due date | Event envelope | A default such as "on receipt" | A query instead of a payment |
| Invoice number | Event envelope | None. Check it is present before the send | A message nobody can match to a payable record |
| Pay link | Event envelope | None. Check it resolves in the test | No route to pay |
| First name | Contact record | A neutral greeting | A missing name |
Write the fallback into the template rather than hoping the field arrives. A value that may be absent takes a default, as in {{ event.invoice.due_date | default: "on receipt" }}, so the rendered output degrades to a sentence instead of a gap.
Know which of the two kinds of field you are looking at, because they fail differently. {{ contact.first_name }} reads the contact record, which existed before the invoice. {{ event.order.total }} reads the envelope that arrived with the trigger. The first degrades to a missing name. The second degrades to an empty block where the money was.
Currency needs its symbol and its code. An amount shown without one is ambiguous for any recipient in a different market, and invoices are exactly where that ambiguity becomes expensive.
Dates need an unambiguous format. A numeric date is read differently in different markets, so the month written as a word removes a class of dispute about when a payment was actually due.
Reach all of this through the email API rather than a dashboard, which is the point of storing the template as a list of fields.
Tax authorities specify what an invoice document must contain, and those requirements attach to the invoice rather than to the email carrying it. The email states the amount and the due date. The attached document carries the fields the relevant authority requires.
The template as a shape, not a design
Almost every page on this subject hands you a picture of an invoice and tells you to personalize it. That is the wrong artifact now, because the thing filling it in is usually not a person.
A Nitrosend template is not HTML you maintain. Templates are stored as structured JSON and rendered to MJML for email client compatibility, so there is no HTML to write. Anyone after a finished HTML layout can start from the invoice email examples. What you author is an ordered list of typed sections, each with its own props. The examples in the Nitrosend docs use four types and nothing else: a header, a text block carrying the copy, a button with its text and href, and a footer.
That matters for an invoice specifically, because it turns "what should this look like" into "what does this contain, in what order". An invoice email is correct when the invoice number, the total, the due date and the payment route are present and unambiguous.
It also explains why a prompt on its own is not enough. A typed section list plus a brand already on file gives an agent a reference to work from. "Make me an invoice email" does not. The template is where the design decisions are stored, so the agent does not have to invent them per send.
It also changes who does the work. An agent with a shape to fill and a brand already on file can compose the invoice, and the shape is the part it reads to learn what is allowed. Generating an invoice email from a JSON section list is a different job from editing one in a builder, and it is the job an assistant can actually finish.
The lifecycle is ordinary REST underneath, with an MCP tool for each step.
| Step | REST | MCP |
|---|---|---|
| Create | POST /v1/my/templates | nitro_manage_template |
| Update | PATCH /v1/my/templates/{id} | nitro_manage_template with if_version |
| Test | POST /v1/my/templates/{id}/send_test | nitro_review_delivery first, then nitro_send_test_message |
| Send | POST /v1/my/messages | The app sends, not the agent |
nitro_manage_template creates, edits or clones a reusable email template. Cloning is the one worth noticing: the overdue reminder above is the invoice template with three lines changed, not a second template somebody maintains in parallel.
Then send it. The app or a scheduled job sends each invoice with POST /v1/my/messages, the transactional send, with an Idempotency-Key per invoice.
Worked example: an agent builds the invoice email
The prompt, in the sender's words: "Build our invoice email template from the billing fields and show me a test before the app sends any invoices."
Before, unguided, the agent writes the HTML inline, hardcodes a sample amount, and sends the first real invoice as its test. The first customer to see the template sees the sample.
After, the gated sequence, one call per line:
nitro_get_statuschecks account readiness and the sender identity.nitro_manage_domainssets up the sending domain, only if it is not yet verified.nitro_manage_templatecreates the invoice template with fields for the amount, the due date, the invoice number and the pay link.nitro_review_deliveryruns validation, spam analysis, preflight and previews on the template. It never sends.nitro_send_test_messageputs one genuine send of the template in front of the test recipients named innitro_configure_account. It never reaches an audience.- A person checks the test against a real invoice record: the amount, the currency, the due date, the invoice number and the pay link.
- The app or a scheduled job sends each invoice through the transactional API with an
idempotency_keyper invoice, so a retry cannot send the same invoice twice. nitro_get_insightsreports email analytics with trends, benchmarks and recommendations once invoices are going out.
Delivery events such as delivered, bounced and complained come back through email webhooks. The trigger for each invoice stays the app's own billing event. The rest of the sending surface is in the email API, and sending volume per plan is on the pricing page.
Where it goes wrong when an agent sends invoices
Each failure below repeats across sends, and each one has a check that catches it before a customer does.
- A value the model made up. An amount, due date or pay link invented by the model, or left as a raw
{{variable}}. Every value comes from the billing record, and every field has a fallback. - A retry that double-sends. A billing job that retries on a timeout without an idempotency key sends two invoices for one debt. Reusing the same key with the same payload returns the original message, and reusing it with a different payload returns
409 idempotency_conflict. - A stale edit to the live template. Two writers touching one template is the common version, and the
if_versioncheck rejects the stale write. - An approved preview that drifted. A preview link is not a snapshot. It resolves the template's current state, so the version somebody approved is not necessarily the version that sent. Review and test again after every edit.
- A paragraph in a field that expects a label. A button section has a
textprop, and a renderer prints what it is given. A sign-off in that field gives a button the width of the email. A typed field is only a constraint if something rejects the wrong shape. - Far more sections than the message needs. Left unconstrained, a model produces empty text sections, invisible spacers and dozens of blocks where six would do. Normalization when the template is saved fixes this. A longer prompt does not.
- Promotional content in a transactional invoice. An offer added to the template can turn every invoice it renders into a commercial message, as the next section explains.
- Credentials in the wrong place. Billing credentials or API keys pasted into code, prompts or logs. Keys belong in environment variables, read at send time.
Compliance and deliverability
An invoice email is transactional, and that status rests on the message's primary purpose. Adding promotional content to an invoice template is the mechanism by which a transactional message becomes a commercial one, and it changes the obligations of every invoice that template renders. The boundary itself is worth reading, since a generated message is the kind most likely to cross it by accident: see transactional versus marketing email.
The review and test gate in the worked example exists because nobody watches each invoice go out. A validation failure discovered after the due date is a payment problem, not a template problem.
Invoice mail must reach the inbox to work, so the sending domain needs SPF, DKIM and a DMARC policy like any other mail, and it should go out on the transactional stream rather than the marketing one. A filtered invoice is an unpaid invoice, and the sender learns about it only when the payment is late.
Send invoice mail from a monitored address. A recipient replying with a query about an amount is the most likely response to an invoice, and a no-reply sender turns a two-line clarification into a support ticket.
Treat the invoice as a brand moment, not a utility
Transactional email gets more deliberate attention than most mail. An invoice is opened, read carefully, forwarded internally and filed. Almost nothing else a business sends gets that much deliberate attention from the recipient, which makes it a strange thing to leave as the default output of a billing system.
The design of a transactional email is better treated as a brand moment than as a template slot, and almost none of that work needs a person. Deciding what an invoice must contain is judgment. Laying it out is not, and it has not been for a while.
That is not an argument for decoration. The amount, the due date and the payment route stay the most prominent things on the page, because the reader came to find them. It is an argument against assuming nobody is looking.
That is what the Brand Kit is for, set over MCP with nitro_set_brand_kit. It holds:
- the company name and description
- the brand, background and text colors
- the heading and body fonts
- the light and dark logo
- the physical address for a marketing footer
- a brand voice that tells the agent how to write for the business
You can set it from your own site by asking your assistant to configure it from a URL, and it is then applied automatically whenever that assistant composes an email. The invoice comes out on brand without anybody opening a layout tool.
One detail needs saying in the brief. An agent designing an email does not import images unless it is asked to, so the request has to name the logo. Images supplied through an agent do work in email designs, so asking is enough.
FAQ
What should an invoice email include?
The invoice number, the sending business name and the due date in the subject line, then three values in the body: the total amount due, the payment due date and the accepted payment methods. Attach the invoice as a PDF, include a text alternative, and send from a monitored address so a query about an amount gets a reply.
What is a good invoice subject line?
Put the invoice number, the business name and the due date in the subject. Each of the three is something a recipient searches for later, so a subject carrying all of them lets an accounts payable team find the invoice in one search, even after it has been forwarded or filed.
What is the best invoice template for sending via email?
The best one is a short template whose fields always resolve: amount with currency, due date written with the month as a word, invoice number and a pay link, each with a fallback or a check. Finished layouts are in the Nitrosend invoice email examples, and the PDF carries the fields a tax authority requires.
Can an AI agent send invoice emails?
An agent can build and test the template, but each invoice should go out from the app's own billing event through the transactional API, with an idempotency key per invoice. Before the first send, the agent runs nitro_review_delivery and sends one test, and a person checks it against a real invoice record.
Go deeper
Transactional Email
1 Linear, Canva, Headspace, Wise and Supabase are not Nitrosend customers and did not send or endorse these emails. Every image in them is concept artwork.