How to Send an Invoice Email (Subject Lines + Body)
By Mark Fulton · 2026-09-02 · 12 min read

Put the invoice number, the amount and the due date in the subject line, keep the body under 100 words, and attach the PDF rather than only linking to it. A subject line like Invoice #1042 | $2,400 | due Sep 12 gives an accounts-payable clerk everything they need to route the email without opening it, which is the actual job the subject line is doing. The body confirms what the work was, restates the amount and terms in one line, gives the payment method, and stops. Send it the day the work is accepted, in the client's working hours, and never bury the invoice in a project-status email.
An invoice email is not persuasive writing. It is a routing instruction. Somewhere between your outbox and the payment run, a human being has to decide which folder, which approval queue and which pay cycle this email belongs to, and that decision usually happens in under four seconds while they are triaging thirty other messages. Everything below optimises for those four seconds.
Most advice on this topic is written for a company sending invoices to other companies at volume. You are one developer sending five to fifteen invoices a month, often to a founder who approved the work personally, or to a project manager at an agency who has no authority over payment and will forward your email to someone you have never met. That forward is the moment most invoices go quiet. The emails below are built to survive it.
What makes an invoice email get processed fast?
Three things, in order of impact.
It is a dedicated email. The invoice email does one thing. It is not the email where you also mention the staging bug, ask about next month's scope, or share the Loom walkthrough. The moment an invoice shares an email with project discussion, it becomes project discussion, and project discussion does not get forwarded to finance. If you have both to say today, send two emails.
Everything a router needs is visible without opening an attachment. Invoice number, amount, due date, and the legal entity being billed. If your contact forwards your email to accounts payable with no added context, which is exactly what they will do, the forward has to stand alone.
Nothing in it invites a reply that is not payment. Questions like "let me know if this works" or "does the timing suit you?" hand the recipient an easy non-payment action. They will take it. Close with a statement, not a question, unless the question is "who should I send this to for processing?".
There is a fourth thing that matters less than people think, and that is tone. Warm or formal makes almost no difference to how fast an invoice clears. Completeness does. An invoice missing a purchase-order number gets bounced by a warm client and a cold one alike, so the details on the document itself are the real leverage. That is covered in full in what belongs on a software development invoice.
What belongs in the subject line?
Treat it as a format spec with four fields, in a fixed order, separated by pipes or commas.
| Field | Why it is there | Example |
|---|---|---|
| The word "Invoice" plus number | Makes the email searchable and filterable forever. Finance teams search by number, not by your name. | Invoice #1042 |
| The amount | Lets an approver know instantly whether it clears their own sign-off limit or needs escalation. | $2,400 |
| The due date | Puts the deadline in front of them before they open anything. Use an unambiguous format like Sep 12, never 09/12. |
due Sep 12 |
| Your business or project name, for new clients only | A first invoice arrives from an unrecognised sender. After that it is noise. | Ravenhill Dev |
So a first invoice reads:
Invoice #1042 | Ravenhill Dev | $2,400 | due Sep 12
And every invoice after that reads:
Invoice #1043 | $2,400 | due Oct 12
A few rules that come out of that spec. Keep it under about 60 characters where you can, because mobile clients truncate and the due date is the field you least want cut. Put the number first so that alphabetical and search-based sorting group your invoices together. Never write "Payment request", "Just checking in", or anything with an exclamation mark. And do not use the word "reminder" on a first send, because it trains the reader to discount the ones that genuinely are reminders later.
The date format point is worth one more sentence. 09/12 means 12 September to most of the world and 9 December to the United States, and an international client's finance team reading it the other way is a three-week delay you never see coming. Spell the month.
If you are still settling on a numbering scheme, the format you pick here should match the one on the document itself. There is a full comparison in invoice numbering for freelancers.
What do you write in the body?
Short. Here are three complete emails covering the situations that account for nearly every invoice a freelance developer sends.
1. First invoice to a new client
The one that has to do the most work, because it is also establishing how you bill.
Subject: Invoice #1042 | Ravenhill Dev | $2,400 | due Sep 12
Hi Dana,
Invoice #1042 is attached, covering the checkout API integration
signed off on 28 August. Total is $2,400, net 14, due 12 September.
Bank details are on the invoice, and it can also be paid by card
using the link at the bottom of the PDF. Billing entity is Ravenhill
Dev Ltd.
If this needs a PO number or should go to someone in accounts
payable instead of you, tell me and I'll resend it correctly today.
Thanks,
Mark
Eighty words. It names the work and the date it was accepted, which prevents the "what was this for?" round trip. It gives two payment routes. And the last paragraph is the one that earns its place: it surfaces the two most common silent blockers, a missing PO number and the wrong recipient, at the moment they cost you a day instead of a month.
2. Recurring monthly invoice
Once the relationship is established, shorter is better. Every extra sentence here is a sentence a busy person has to skim past every single month.
Subject: Invoice #1043 | $2,400 | due Oct 12
Hi Dana,
August retainer attached. Invoice #1043, $2,400, due 12 October.
Same details as last month.
Summary of the month is in the invoice line items.
Thanks,
Mark
Thirty-five words. Resist the urge to pad this with a status update. If the client wants to know what you did, it is on the invoice, and putting the work summary in the line items rather than the email means it travels with the document into their records. If you bill on a fixed monthly arrangement, the mechanics of structuring that are in how to invoice retainer clients.
3. Final invoice on a project
The one people get wrong by making it emotional. It is a handover document as much as a bill.
Subject: Invoice #1051 | final | $3,600 | due Sep 30
Hi Dana,
Final invoice for the checkout project is attached. Invoice #1051,
$3,600, due 30 September. That closes out the agreed $12,000 across
four invoices.
Handover is complete: production is deployed, the repo is
transferred to your org, and the runbook is in the docs folder.
Credentials I held have been rotated out.
Happy to keep an eye on things next month if useful, on the same
terms.
Thanks,
Mark
The reconciliation line matters. Telling them this is the last of four invoices totalling the agreed number lets an approver verify against the contract without pulling three other emails. The handover paragraph makes the invoice feel like a completion, which is psychologically much easier to approve than an isolated request for money. And the closing line is the only place in any of these three emails where selling is appropriate.
When is the best time to send an invoice?
Send it the day the work is accepted, not on a monthly billing day you invented. Every day between finishing and invoicing is a free extension of your payment terms that nobody asked you for. For milestone work, that means the invoice goes out the same day the client approves the milestone, while the value is still fresh and the approver still remembers agreeing to it.
Within the day, aim for the client's working morning, midweek. Tuesday through Thursday, before lunch in their timezone, lands the email while people are still processing rather than clearing. Friday afternoon is the worst slot available: it sits over the weekend and gets buried under Monday. Do not send at 2am your time to a client eight hours behind you, because your invoice arrives at the bottom of an overnight pile.
One caveat that beats all of the above. If your client runs payment on a fixed cycle, for example a run on the 1st and the 15th, then the only timing that matters is arriving before their cut-off with enough days for approval. Ask once, early, what the cycle is. It is a normal question and it changes your cash flow more than any subject line will.
Whatever you send, keep the sent email itself. A copy of the invoice and evidence of when you sent it is part of the paperwork trail behind your income, and the IRS guidance on recordkeeping for the self-employed is that you keep records as long as they are needed to prove the income or deductions on a return. This is general information, not tax or legal advice.
PDF attachment, link, or both?
Attach the PDF. Add a payment link inside it. That combination beats either one alone.
Attachments win because of how invoices are actually processed. Finance teams and bookkeeping tools ingest documents, and a large share of small businesses run on someone forwarding invoice emails straight into an accounting inbox where the attachment gets parsed automatically. A link-only email breaks that in one step: the file is not in the email, so the forward carries nothing, and someone has to click through, download and re-attach. Many of them will not.
Links win on a different axis. A hosted payment link inside the PDF gives an impatient founder a way to pay in ninety seconds by card, which is often faster than routing a bank transfer through a process. So put the link in the document, where it survives every forward, rather than only in the email body.
Some practical details that quietly cause failures:
- Name the file properly.
invoice-1042-ravenhill-dev.pdf, notinvoice.pdfand neverinvoice_final_v2.pdf. The filename becomes the record in their system, and three files calledinvoice.pdfin one folder is a support ticket waiting to happen. - PDF only. Never send a Word document, a spreadsheet, or a screenshot. A PDF renders identically everywhere and cannot be accidentally edited in transit.
- Watch the size. Gmail attachments over 25MB are stripped and replaced with a Drive link, per Google's documentation on attachment limits, and other providers cap lower. An invoice PDF should be well under a megabyte. If yours is not, you have an image embedded at full resolution.
- Do not zip it. Corporate mail filters quarantine archives and you will never be told.
- Do not password-protect it. It blocks automated ingestion and the password is in the same email anyway, so it protects nothing.
If a client's system genuinely cannot accept attachments from outside senders, which happens at larger companies, ask them for the supplier portal instead of fighting it. Uploading to their portal is faster than three rounds of blocked email.
Frequently asked questions
Do I send the invoice to the client or their accountant?
Send it to your usual contact and CC accounts payable if you know the address. Your contact is the one who can confirm the work happened, and finance is the one who can pay it. Sending only to finance strips the approval context and the invoice stalls. Sending only to your contact relies on them forwarding it, which is where most invoices die. If you do not have an AP address yet, ask for it on the first invoice, then use it every time after.
Should the amount be in the subject line?
Yes. The common objection is that it feels blunt or exposes the number to anyone glancing at a screen, but in practice it speeds up approval because it tells the reader immediately whether this clears their own authorisation limit or needs to go up a level. On a shared or monitored inbox, that one detail routes the email correctly on the first pass. If a specific client has asked you not to, honour that and put the invoice number and due date in instead.
What if the client says they never got it?
Resend the same invoice number, unchanged, with the original send date and time in the first line, and CC a second person. Never issue a new number for a resend, because two numbers for one debt creates a reconciliation problem that will cost you more time than the delay did. If it has happened twice with the same client, the cause is almost always a spam filter or an entity-name mismatch rather than a person, so ask them to check quarantine and confirm the exact registered name they need on the document. In the United Kingdom, the government's guidance on invoicing customers makes the same basic point that an invoice has to state clearly how much is owed and when, and a mismatch on either is a legitimate reason for a finance team to bounce it.
Follow the invoice email with what, and when?
A pre-due nudge about three days before the due date, then a short confirmation request on day one overdue, then escalation on a fixed schedule rather than on how annoyed you feel. The full six-email sequence, with the wording for each stage and who to add as a recipient at each step, is in late payment email templates for freelance developers. The important principle is that each follow-up should change exactly one thing, whether that is the recipients, the terms cited, or the consequence named. Escalating everything at once burns the whole ladder in two steps.
Generate the PDF you are about to attach
The email is the easy half. The attachment is what gets paid. Billable generates the invoice in your browser, no account and no server, and the print CSS is tuned so the PDF comes out clean on A4 and US Letter rather than looking like a screenshot of a web page. Fill in the line items, download the PDF, attach it to the email above, and send.
If you want saved clients, recurring templates and your logo on every invoice, Pro is $4/mo billed as $24 for six months, or $79 once for lifetime access. The generator itself stays free.