Build an Invoice Generation Workflow in n8n

Invoicing Is a Sequence Problem, Not a Design Problem

Generating an invoice looks like a formatting job: make it pretty, drop in the line items, export a PDF. The part that actually matters is boring. The number. Invoices need a gapless, sequential ID, because that's what an auditor checks first, and that's the bit a quick script gets wrong by reaching for a timestamp or a UUID.

An n8n invoice generation workflow gets the sequence right and automates the rest: read the next number, build the document, render a PDF, store it, email the customer, log it to a register. No manual numbering, no paid document SaaS in the middle of your billing data.

This is the generation side of invoicing. The chasing-for-payment side is a different workflow, and worth keeping separate.

What You Can Automate

• Sequential numbering: read, increment, and persist a gapless invoice ID every run
• PDF rendering: HTML invoice converted to PDF on your own Gotenberg instance
• Customer storage: each PDF filed in Drive or S3 under customer and invoice number
• Auto-email: the invoice attached and sent the moment it's generated
• Register logging: a row appended to a master sheet for finance to search
• Trigger flexibility: fire from a webhook on order completion, a new Stripe charge, or a sheet row

The Invoice Pipeline

A complete generation flow runs in one pass, and the numbering bookends it:

Trigger (webhook / new order)
  → Code (read + increment invoice counter, write it back)
  → Code (build invoice HTML from line items)
  → HTTP Request (HTML → PDF via Gotenberg)
  → Google Drive (store PDF under customer/INV-0042.pdf)
  → Gmail (attach PDF, send to customer)
  → Google Sheets (append register row)

Read-increment-persist happens first so the number is locked before anything can fail downstream. If the email bounces, you still issued a valid, numbered, stored invoice.

1. Trigger and number

Whatever fires the workflow, the first real step is the counter. Read the last invoice number from static data or a single-cell sheet, add one, write it back immediately. Doing the write-back first matters: if two orders land close together, you don't want both to read the same number. In practice a queue-mode n8n with a single worker on this workflow avoids the race entirely.

2. Build the document

A Code node assembles the invoice HTML from the line items in the trigger payload: customer block, itemized table, subtotal, tax, total, the invoice number and date. Keep it as a template string with your branding. HTML is easier to maintain than a binary template and renders to PDF cleanly.

3. Render the PDF

Call a self-hosted Gotenberg or wkhtmltopdf endpoint from an HTTP Request node, posting the HTML and getting back a PDF binary. This keeps customer billing data on infrastructure you control. The paid document APIs work, but routing every invoice through a metered third party is a cost and a data-handling question you don't need to take on.

4. Store

A Google Drive or S3 node writes the PDF binary under a predictable path: customer folder, INV-0042.pdf. Predictable paths make the register's links resolvable and make a future reconciliation job trivial.

5. Send and log

Gmail attaches the PDF and sends it. Then append a register row — number, customer, amount, date, storage link — so finance has a ledger without opening Drive. That register is also what a later payment-chase workflow reads from.

Implementation Patterns

Pattern 1 — Persist the counter before you generate. The gapless sequence is the whole compliance story. Read, increment, and write back the counter as the first action, not the last. If PDF rendering fails, you've burned a number, and a small gap with a logged reason beats two invoices sharing an ID. Self-hosted n8n lets you run this workflow on a single worker so the counter never races.

Pattern 2 — Self-host the PDF step. Customer billing data shouldn't transit a third-party document service you pay per render. A Gotenberg container next to your n8n instance renders HTML to PDF for free and keeps the data in your perimeter. One more service to run, but billing data is exactly the data you want to keep close.

Pattern 3 — Register as source of truth. The append-to-sheet step isn't an afterthought. It's the ledger every downstream finance workflow reads: the payment chaser, the monthly reconciliation, the tax export. Write a complete row every time, even when the email fails, so the register never disagrees with reality.

n8n Nodes You'll Use Most

Getting Started

1. Stand up a Gotenberg container alongside your n8n instance.
2. Build the counter Code node and test that two quick runs produce consecutive numbers.
3. Write the HTML-building Code node with your branding and a sample line-item payload.
4. Wire the HTTP Request to Gotenberg and confirm you get a PDF binary back.
5. Add the Drive store and the Gmail send; check the attachment opens.
6. Append the register row and verify it matches the stored file.
7. Connect your real trigger and run one live order end to end.

For sellers fulfilling lifetime deals or one-off purchases, the LTD Launch & Fulfillment Automator wires this generate-store-send flow into the post-purchase sequence so the invoice goes out as part of fulfillment, not as a separate chore.

Generating the invoice is half the job; getting paid is the other half. Once invoices are issued, automating invoice reminders with n8n walks the escalation ladder from gentle nudge to final notice, and the broader n8n invoice automation guide covers the payment-matching side. The InvoiceChase template reads the same register this workflow writes.