Salesforce Development

Generating Branded PDF Invoices in Salesforce

How to build a professional, automated invoice PDF system inside Salesforce — from template design through to automatic email delivery.

8 min read April 2026 Purivo Team
Salesforce PDF Generation Visualforce Automation ERP Integration

Every company that invoices customers has to decide where invoices come from. The ERP usually handles this natively — but when Salesforce is your customer-facing system and your invoice data lives there too (whether directly or synced from the ERP), there are real advantages to generating invoices from Salesforce rather than printing them from the back-office system.

This article covers why companies build invoice generation in Salesforce, what the build options look like, and the practical considerations that matter when you're doing it for real.

Why Build Invoice PDFs in Salesforce?

The primary reasons we see companies pursue this are:

  • Branding control. ERP-generated invoices are often locked to basic formatting. Salesforce lets you build pixel-perfect branded documents that match your other customer communications.
  • Automation. Invoices can be generated and emailed automatically when a specific trigger fires in Salesforce — an order status change, a shipment confirmation from the ERP, or a scheduled batch process. No manual steps.
  • Centralized customer communication history. When invoices are emailed from Salesforce, the activity is logged against the customer record. Your account team can see that an invoice was sent, when, and to whom — without calling finance.
  • Single source of truth for the customer. If your team is already managing the customer relationship in Salesforce, having invoices originate there keeps everything in one place.

It's worth being clear about when this doesn't make sense: if your ERP already generates well-designed, automated invoices, and the problem you're solving is just branding, the cost of building in Salesforce may not be justified. The sweet spot is when you want automation + branding + integration with Salesforce activity tracking all at once.

Build Options

Visualforce Pages Rendered as PDF

Visualforce is Salesforce's server-side page rendering technology. A Visualforce page with renderAs="pdf" in its page tag renders as a PDF when loaded — and that PDF can be generated programmatically from Apex and attached to a record or emailed to a customer. This is the most flexible and cost-free approach, since it uses native Salesforce technology without additional licences.

The trade-off is that Visualforce PDF rendering has some quirks. Complex layouts, certain CSS properties, and multi-page documents with consistent headers and footers require careful testing. It's more capable than most people expect, but it's not a full HTML-to-PDF engine — some things that look right in a browser won't render correctly as a Visualforce PDF.

AppExchange Document Generation Tools

Tools like S-Docs, Conga Composer, Nintex DocGen, and similar products let you design invoice templates in a Word or HTML-based editor and merge Salesforce data into them at runtime. These are faster to set up for non-developers, handle complex layouts more reliably, and support conditional sections (show this block only if X is true) without custom Apex.

The cost is the additional licence. For companies already buying one of these tools for other documents (quotes, contracts), the marginal cost of using it for invoices is low. If you'd be buying it specifically for invoices, weigh that against the Visualforce approach.

Lightning Web Components with jsPDF

A more modern approach is to build a Lightning Web Component that renders the invoice in the browser using JavaScript and generates the PDF client-side using a library like jsPDF. This gives you full control over the design and doesn't have the rendering limitations of Visualforce PDF. The complexity is higher, and there are some nuances around embedding fonts and handling page breaks in JavaScript-generated PDFs.

Getting the Data Model Right

Before you write any template code, spend time on the data model. An invoice PDF pulls from several related objects — the invoice header, invoice line items, customer details, your company's branding assets, payment terms, and possibly shipping information. All of that data needs to be accessible from a single starting point in Salesforce.

Common data model considerations:

  • Where does invoice data live? If it's synced from an ERP, the objects and field names will reflect the ERP's structure. Know which fields map to which invoice elements before designing the template.
  • Multi-currency. If invoices can be in CAD or USD (or both), the template needs to display the correct currency symbol and handle the formatting correctly. This is frequently underestimated.
  • Company information. Your logo, address, phone number, and payment terms need to come from somewhere. Custom Metadata or a custom settings object is cleaner than hardcoding them in the template — especially if you have multiple entities or brands.
  • Due date calculation. Payment terms (Net 30, Net 60, etc.) need to be translated into an actual due date on the invoice. Verify the field exists and is populated correctly before building the template around it.

From the field: The most common late-stage problem in invoice PDF projects is discovering that a field the template needs — due date, terms description, a specific line item detail — either doesn't exist in Salesforce or isn't being populated correctly by the ERP sync. Do a data audit before designing the template, not after.

Automating the Send

The automation layer is what makes the project genuinely valuable. A PDF that someone has to manually generate and manually email is better than a Word document, but it's not transformative. The goal is: invoice is ready → PDF is generated → email is sent → activity is logged → all automatically.

1

Define the trigger

What event causes an invoice to be sent? A field change on the invoice record (Status = "Ready to Send"), a button click by an authorized user, a scheduled batch that runs nightly, or an inbound event from the ERP? The right answer depends on your process.

2

Generate the PDF

From Apex, call the Visualforce rendering engine (or your chosen tool's API) to generate the PDF as a Blob. Attach it to the invoice record as a ContentVersion so it's stored in Salesforce Files and accessible to the account team.

3

Build the email template

Create a Lightning Email Template in Salesforce with the invoice PDF attached. Merge fields pull the customer name, invoice number, and amount into the email body. Keep the email itself simple — the detail is in the PDF.

4

Send via Apex and log the activity

Use Messaging.sendEmail in Apex to send the email with the PDF attached. Log the send as an Activity against both the Invoice record and the Account so the history is visible to the account team.

Practical Notes Before You Build

  • PDF rendering in Visualforce is synchronous and governor-limited. For bulk generation (end-of-month batch), you'll hit Salesforce governor limits if you try to generate hundreds of PDFs in a single transaction. Use batch Apex with appropriate sizing.
  • Test on the final data, not sample data. Invoice PDFs often look fine until you hit a customer with an unusually long name, a line item with 40 characters in the description, or a 15-line invoice that breaks across pages in unexpected ways. Test with real data before go-live.
  • Decide on archival policy. PDF invoices stored as Salesforce Files count against your storage allocation. If you're generating hundreds of invoices per month, plan for storage costs or build an archival process.

We've built this end to end — from data model to template to automated send — for companies invoicing through Salesforce with ERP data synced in. If you're planning a similar build and want to talk through the approach, get in touch.

P
Purivo Team

Purivo is an IT consulting firm helping mid-market companies implement ERP systems, build Salesforce solutions, and connect the two. We work across the full project lifecycle — from system selection through go-live and ongoing optimization.