How to Attach a PDF Invoice to WooCommerce Order Emails

Sending the invoice as a separate step (or asking customers to log in and download it) is friction nobody wants. The right behavior is simple: when an order reaches Processing or Completed, WooCommerce sends its email and the PDF invoice is already attached. Here is how that works, and how to set it up without code.

Which email should carry the invoice?

WooCommerce sends different emails at different order statuses. For most stores the invoice belongs on the Processing order email (payment received) or the Completed order email (fulfilled). Pick one so the customer isn’t sent two copies. B2B and invoice-terms stores often prefer Processing; physical-goods stores often prefer Completed.

Setting it up (no code)

• Install an invoice plugin that supports email attachment, and set your business details, logo and tax info once in its settings.
• Choose the trigger email (Processing or Completed). The plugin hooks WooCommerce’s woocommerce_email_attachments filter and adds the generated PDF to that message.
• Place a test order and move it to that status. The email arrives with invoice-1234.pdf attached, no manual step.

Why deliverability gets worse when you attach

Attaching a PDF quietly changes your email from a small text message into a payload, and that has consequences most stores discover through customer complaints rather than logs. A WooCommerce install sending mail through plain PHP mail() is already fragile; add a few hundred kilobytes of attachment and you push against per-message size limits, slower SMTP handoffs, and spam filters that score attachments from unauthenticated senders more harshly.

Two fixes carry nearly all the weight. First, send through authenticated SMTP or a transactional provider rather than mail(), so your messages carry SPF and DKIM alignment and stop looking like spoofed mail. Second, keep the PDF small: a logo exported at 2000px wide and embedded at 200px is the single most common reason a two-page invoice weighs 3 MB. Resize the asset, don’t just scale it in the template.

Generate at send time, not on demand

There’s a subtle architectural decision hiding here. If the PDF is generated fresh every time someone opens a link, the document can silently change after the fact (a corrected address, a new tax rate, an updated logo), and an invoice that changes retroactively is precisely what accounting rules forbid. Generate the document when the invoice is issued, store it, and serve that stored file afterward. The version the customer received and the version in your records should be byte-identical a year later.

The same logic applies to attachment order and naming. A file called invoice.pdf is worthless in a customer’s downloads folder next to eleven other invoice.pdf files. Name it with the invoice number and your store (ACME-2026-0042.pdf), and you cut a meaningful share of “can you resend my invoice?” support requests.

The details that trip people up

Invoice numbers must be stable. The number assigned when the invoice is first generated has to be stored on the order, so that a reprint or a resend never produces a different number. Accountants and tax authorities require sequential, non-changing invoice numbers. A plugin that regenerates the number on every render is a compliance problem.

The PDF engine must not break the email. If the invoice can’t generate (a host missing a PHP extension, say), the order email must still send. Good plugins degrade gracefully to a printable HTML document instead of throwing a fatal error that stops the email entirely.

Language and currency have to render. The attached PDF should show the customer’s name, address and your currency symbol correctly in any language; see our guide on fixing invoices that don’t render Arabic or RTL text.

Test with a real inbox, not the order preview

The preview in your admin renders the document; it does not exercise the path that actually breaks. Almost every failure in this feature happens between the site and the recipient's mail server, which the preview never touches.

Three checks catch nearly all of it. Place a genuine test order and confirm the attachment arrives at an address on a major provider rather than your own domain: self-hosted mail to itself will succeed in situations where anything external fails. Check the spam folder rather than assuming non-delivery. And open the PDF on a phone, since that is where a majority of order emails are read and a document that assumes a desktop viewer is worth knowing about early.

It is also worth testing an order that exercises the awkward cases: a long product name, a customer address with non-Latin characters, and a tax line, all of which surface layout problems that a one-item test order will never reveal.

What should be free vs. paid

Automatic email attachment, the invoice itself, packing slips, delivery notes, taxes, totals and sequential numbering are table stakes; they should be in the free plugin. Reserve payment for genuine power features: bulk-printing invoices for many orders at once, custom document templates, and credit notes.

Related reading: why invoice PDFs don’t render Arabic / RTL text , sequential invoice numbering, how freemium WordPress plugins work, and bulk-printing a whole day’s invoices at once.