Invoice Template + Late Payment Sequence

When to use this

• You are sending invoices but payments drift.
• You want a repeatable follow-up cadence that does not feel personal.

Late payment rarely requires a new personality. It usually requires a repeatable process: send invoices that can be approved, follow up on a schedule, and enforce a boundary when the account is overdue.

The preview on this page gives you two assets: a simple invoice template and a four-touch late payment sequence that escalates over time (Day 0, Day 3, Day 7, Day 14). The goal is not to be clever. The goal is to be consistent and easy to understand.

Nothing here guarantees an outcome. Use this as a default operating rhythm: clear invoice, clear due date, and follow-ups that stay procedural even when you feel awkward.

If you want the quick start path for fixing late payment, start with:

• Get paid on time (Start Here path)

Quick start (10 minutes)

If you only have a few minutes, do this. The goal is to create clarity and remove friction before you write anything longer than a few lines.

1. Confirm the invoice is valid and complete. Check the bill-to entity, invoice number, invoice date, due date, line items, total, currency, and payment method details.
2. Confirm the route. Where does the client actually process invoices: an accounts payable email, a portal, or a finance contact? If you are not sure, ask for the correct destination.
3. Pick the thread. Use one email thread per invoice so there is a clean paper trail.
4. Schedule the follow-ups. Put reminders on your calendar for Day 0 (due date), Day 3, Day 7, and Day 14. This is how you avoid improvising later.
5. Send the next message in the sequence. Keep it short and ask for a payment date when it is past due.

If the client replies with a process blocker (missing PO, vendor form, wrong bill-to entity), fix the blocker quickly and keep the follow-up cadence running. Most delays are boring.

Send invoices that get processed

Many late payments begin as small admin failures: the invoice went to the wrong inbox, it is missing a required reference, or the descriptions are too vague for approval. Your job is to make it easy to process your invoice without guesswork.

Before you send: confirm the client's process

Ask this once at kickoff (or now, if you are already mid-project):

Specifically, you want to know:

• the exact email address or portal for submission,
• any required reference fields (PO number, vendor ID, project code),
• who owns approval (name or role),
• and what the normal payment run cadence is (if they have one).

Invoice hygiene: make the document hard to reject

Your invoice should be clear enough that someone who does not know the project can approve it. Use specific descriptions tied to the agreement (not generic "services").

[ ] Invoice number is unique and consistent across email, PDF, and any portal
[ ] Invoice date and due date are present (due date is a specific date)
[ ] Bill-to name matches the client legal entity used in the agreement
[ ] Recipient is correct (accounts payable email or portal owner)
[ ] Required references included (PO number, vendor ID, project code) if applicable
[ ] Line items describe what was delivered (tied to the SOW or milestones)
[ ] Total amount and currency are correct
[ ] Payment method details are included (bank transfer / card / ACH)
[ ] Notes include how to reference the invoice number in payment details

Email hygiene: route, subject, and attachment

Treat the invoice email like a small handoff. Your subject line should make it obvious what the email is, and your first sentence should tell them the due date. If there is a portal requirement, do not assume an email counts as submission.

Subject: Invoice [1234] - [Project name] - Due [YYYY-MM-DD]

Hi [Name] - sharing invoice [1234] for [project/service]. Due date: [YYYY-MM-DD].
Payment details: [method and any link or routing info].

Can you confirm it is received and with the right team for approval and payment?

Thanks,
[Your name]

The "confirm it is received" line is doing real work. It is a gentle way to surface routing problems early (wrong inbox, missing portal upload, missing reference field) while the invoice is still fresh.

The Day 0, Day 3, Day 7, Day 14 sequence

The sequence in the preview is designed to be short. That is a feature. You are not writing a novel. You are asking for a payment date, then escalating calmly if that date never arrives.

Here is how to think about each touch.

Day 0 (due date): friendly reminder

This is a simple due-date reminder. Keep it friendly and lightweight. Include the payment details (or link) so they can forward the message to accounts payable without asking you for anything.

If you are working with a larger company, this message is also a quiet routing check. If someone replies "please send to AP" or "we need a PO," you learned something before the invoice drifts for weeks.

Day 3: past due, ask for a payment date

Day 3 is where you stop asking "status" questions and start requesting a commitment. The template asks: can you confirm when payment will be sent?

If they reply with a vague answer ("soon", "next week"), respond with a polite request for an exact day. You are not being difficult; you are making the next step unambiguous.

Day 7: action required, and the work-pause boundary

Day 7 is the pivot from "reminder" to "this requires action." The template asks them to confirm a payment date today and makes your boundary explicit:

This line matters because it turns late payment into a business process issue, not a personal negotiation. You are not threatening. You are stating what happens when an invoice is overdue.

If pausing work feels scary, make it concrete. Define what "pause" means in your own workflow: stop new work, stop delivering additional files, and stop booking new meetings until payment is received. Do not argue about it. Just name it and do it.

Day 14: final notice and escalation options

Day 14 is the "final notice" message. The template sets a date and says you will escalate via collections / small claims / platform dispute per your agreement if payment is not received by that date.

Use this when you have already asked politely and clearly, and you need the next step to be defined. Keep it factual. Keep it in writing.

Note: escalation mechanics vary by jurisdiction, contract terms, and platform rules. Keep the message aligned with your agreement and your real next step.

Follow-up operating rhythm

A good follow-up system runs even when you are busy. That means the rhythm cannot depend on motivation. It needs a few defaults you follow every time.

• Calendar it at send time: schedule Day 0, Day 3, Day 7, Day 14 reminders as soon as the invoice is sent.
• Keep one thread per invoice: replies stay in one place.
• Ask for a payment date: when the invoice is past due, do not accept an endless status loop.
• Follow up when a promised date slips: if they give you a date and miss it, follow up immediately after the miss.
• Run a weekly AR review: one short weekly block to review outstanding invoices, next follow-up dates, and any blockers.

If you think your issue is bigger than one invoice and may be a pattern, use this checklist template to diagnose what is happening:

• Late payment patterns (template)

How to stay procedural (not emotional)

Most freelancers do not struggle with writing emails. They struggle with what the email represents: confrontation, fear of losing the client, or shame about money. The fix is to turn "chasing" into a routine.

Use these rules as guardrails:

• Assume process before malice. Missing paperwork and routing mistakes are common. Ask the question that surfaces them.
• Be short on purpose. Short messages are easier to forward internally and easier to answer with a payment date.
• Do not over-apologize. You are not asking for a favor. You are asking for the invoice to be paid.
• Use the same sequence every time. Consistency protects you from making exceptions you regret later.
• Write like you will reread it later. Keep your tone calm and factual so it holds up if the situation escalates.

When to pause work

The template introduces the work pause boundary on Day 7: if payment is delayed, you will pause work until the account is current. That is the moment your process stops being a suggestion.

Pausing work is cleanest when it is already part of the agreement. If you need language or structure, use:

• Statement of Work (SOW) Template

And if you want the clause-level rationale, read:

• Freelance contracts: the clauses that matter

Practical guidance (keep it boring):

• Pause future work first (new deliverables, new scope, new meetings), then decide how you handle active delivery.
• Keep the explanation short: the invoice is overdue, you are pausing until the account is current, and the timeline shifts accordingly.
• Do not mix the payment pause with a bunch of other frustrations. One issue per email.

What to document

Documentation is not about preparing for a fight. It is about keeping the situation simple: one place to see what is owed, what was sent, what was said, and what the next step is.

At minimum, keep this for each invoice:

• invoice number, amount, invoice date, and due date
• who it was sent to (email or portal), and when
• the invoice PDF or portal submission confirmation
• the follow-up dates you used (Day 0, Day 3, Day 7, Day 14)
• any promised payment dates, and whether they were met
• any blockers the client mentioned (PO, vendor setup, approval owner)
• the moment you paused work (if you did) and what you paused

Invoice #: [1234]
Client: [Client name]
Amount: [Amount + currency]
Due date: [YYYY-MM-DD]
Sent to: [AP email or portal]
Sent on: [YYYY-MM-DD]
Status: [Sent / Past due / Promised / Paid]
Last follow-up: [Day 0 / Day 3 / Day 7 / Day 14]
Next follow-up: [YYYY-MM-DD]
Notes: [PO needed? who owns approval? promised pay date?]

FAQ

Do I really need to send a Day 0 email?

If you already sent the invoice earlier, Day 0 is not "sending the invoice." It is a due-date reminder. It keeps the due date visible and makes it easier for the client to route payment internally without digging through old threads.

What if the client says they never received the invoice?

Treat it as a routing problem first. Re-send the invoice, confirm the correct accounts payable destination, and ask whether a portal upload or reference field is required. Then continue the cadence from there.

What if they say they need a PO number or vendor onboarding?

That is a process blocker, not a negotiation. Ask who owns it, what information they need from you, and the expected timeline. Document the blocker in your log so you are not guessing later.

Should I call instead of emailing?

Calls can help when email is bouncing between people, but keep the paper trail. If you call, send a short follow-up email summarizing what was agreed: who owns approval, and the payment date.

When should I pause work?

The default in this template is Day 7: you ask for action and you state that if payment is delayed you will pause work until the account is current. If you plan to pause, make sure your agreement supports it and that you apply it consistently.

What if I am on a platform that holds payments?

Use the platform's process. The Day 14 template includes "platform dispute" as one escalation option. Keep your messages aligned with the platform rules and keep everything in writing.

Should I add late fees?

Only if it is in your agreement and compliant with your local rules. If you are not using late fees, a work-pause rule is often the simpler boundary to enforce operationally.

How do I prevent this next time?

Prevention is upstream: confirm the invoicing process at kickoff, use a SOW with explicit payment terms, and keep your follow-up cadence scheduled. For the full maintained system, read:

• Invoicing and getting paid on time

How to customize

1. Set due dates and payment methods clearly.
2. Adjust language to match local rules for late fees and collections.

Related Codex pages