CodeCanyon WooCommerce PDF Invoices & Packing Slips - WordPress Plugin

How to Set Up CodeCanyon WooCommerce PDF Invoices & Packing Slips for WooCommerce

CodeCanyon WooCommerce PDF Invoices & Packing Slips is not just about generating a nice-looking PDF after checkout. In a live store, it solves a more practical problem: creating a clear document for the customer, sending it with the WooCommerce email, giving the admin quick access to invoices and packing slips, and then helping verify that the numbering, taxes, addresses, line items, and extra documents all match the actual order.

This guide walks through the practical settings that matter after installation: when to enable automatic generation, how to approach invoice numbering, where to use order variables, how to verify taxes, how to work with packing slips, and what to do if the PDF is not generated or does not look the way you expected. This material is not a substitute for accounting advice and does not claim legal validity for every country, but it will help you configure the technical side of the plugin carefully and in a way you can verify.

Special attention is given to the areas where store owners most often run into trouble: generating invoices for the wrong order statuses, failing to test the email attachment, mixing up WooCommerce tax settings, adding too much product meta to the document, forgetting about the separate packing slips plugin, or trying to fix layout issues without using Preview and debug HTML.

What the Plugin Actually Automates in a WooCommerce Store

In standard WooCommerce, an order exists as an entry in the admin panel: it has a status, products, totals, addresses, payment method, shipping method, taxes, coupons, notes, and extra fields. The customer receives an email, and the admin sees the order in the list. CodeCanyon WooCommerce PDF Invoices & Packing Slips adds a document layer to that flow: a PDF invoice, a packing slip, download links, email attachments, and tools for manually regenerating the document.

The real value of the plugin becomes obvious when invoices are needed regularly, not just once in a while. If your store sells to businesses, handles repeat orders, sends documents into the customer's accounting workflow, or prints packing slips for a warehouse, creating PDFs manually becomes a source of errors very quickly. The plugin takes order data and assembles it into a single document based on a defined template.

The "order - PDF - email - account" chain

Once automatic generation is enabled, the plugin can create PDFs for orders, attach invoices to WooCommerce emails, show the customer a link on the thank-you page and in the order details, and let the admin or store manager download the file from the order list or the individual order screen. It helps to think of this as one connected process. If the document does not appear in the email but is available in the order screen, the issue is often not PDF generation itself but the email configuration or the event the attachment is tied to.

If the document does not appear anywhere, start the check earlier in the chain: is the plugin active, is its menu visible inside WooCommerce, is the required framework plugin installed, is the right order status selected for generation, is the PDF library failing because of PHP extensions, and is the template throwing a rendering error.

Who benefits most from invoice automation

The plugin is a strong fit for online stores where the customer needs a downloadable PDF document immediately after checkout or once the order moves into an active status. That may be a B2B store, a wholesale store, a store that ships physical products, a business serving customers' accounting departments, a site with repeat buyers, or a small warehouse where the packing slip helps staff assemble shipments.

For a very small store with only a few orders per month, the plugin can still be useful, but the main benefit is not time savings. It is document consistency. If every invoice is rebuilt manually in office software, different employees may use different templates, forget the number, change signatures, or lose the link back to the order. An automatic PDF reduces that kind of mismatch.

When the product may not be the right fit

You should not treat this plugin as a universal replacement for an accounting system. It generates documents based on WooCommerce order data and its own settings, but it does not turn your store into a full accounting platform. If your business needs complex journal entries, integration with local tax systems, document approval across multiple legal entities, distributed numbering across several sites, or tightly regulated electronic document exchange, you need to confirm first that the product actually supports those requirements and that your version includes them.

The safest selection logic is simple: the plugin works well as a WooCommerce document layer, but any sensitive accounting requirement should first be confirmed with your accountant and the developer's documentation. If the requirement is not documented, do not assume you will be able to "configure your way into it."

What to Check Before Installation and First Activation

Preparation is not just a formality. A PDF invoice depends on order data, tax settings, email behavior, upload folder availability, PHP version, server extensions, and admin permissions. If you do not verify those basics up front, the error will look like "the plugin doesn't work" even when the real cause is WooCommerce or the server environment.

Compatibility and dependencies

The CodeCanyon page and the weLaunch site describe the product as a WordPress/WooCommerce plugin for generating PDF invoices and packing slips. The requirements specifically mention WooCommerce, WordPress, PHP, and the free weLaunch Plugin. In the setup documentation, the developer explicitly says that the PDF Invoices menu item should appear under WooCommerce, and if it does not, you should check whether Redux Framework is installed and active. In practical terms, that means one thing: after activation, you should see the plugin settings exactly where the documentation says they will be.

Before installation, check the following:

• WooCommerce is already installed, active, and able to create test orders.
• The user has administrator or shop manager permissions sufficient to work with orders and settings.
• WooCommerce emails are being sent successfully without the PDF plugin. An attachment will not fix a broken mail setup.
• Your tax settings are clear: whether prices are entered with or without tax, how taxes are shown in the cart and checkout, and how your tax rates are named.
• The server has the required PHP extensions for PDF generation. If the PDF library reports an error, debug mode is often the fastest way to diagnose it.
• You know which order statuses should trigger an invoice: after payment, after processing, after completion, or only manually.

Create a test order before configuring anything

Do not begin setup with a real customer order. Create a test product, place an order through the normal storefront, or add one manually in the admin panel, then make sure the order includes an address, shipping method, payment method, tax lines, and a total. That order becomes your safe control point for PDF previewing.

If the store is already live, use an order with a typical structure: one regular product, one discounted item or variation, shipping, tax, and a coupon if your store uses coupons. That will immediately show how the document behaves with real-world data rather than a perfect one-item test order.

Practical check: before enabling automatic email delivery, create one test order and save its number. You will use that number in Preview, manual generation, email testing, and tax-line troubleshooting.

A separate nuance with packing slips

One important detail appears in discussions on the developer's site: packing slips are delivered as a separate part of the package, and if you only see invoices in the admin panel, you need to check whether the second plugin from the main archive has been installed. This is not an interface bug and not a hidden tab. If your store only needs packing slips, clarify this before launch, because operations may be waiting for a different document while the admin keeps searching for it in the invoice settings.

Installation and the First Check After Activation

Installing a CodeCanyon plugin usually means uploading a ZIP file in WordPress: Plugins - Add New - Upload Plugin. If the archive contains a main package with multiple ZIP files inside, do not upload the entire outer archive as a single plugin. Extract it locally first, then upload the individual plugin ZIP files intended for WordPress. In the WordPress interface, you should see the invoice plugin activated, and if needed, the separate packing slips plugin as well.

After activation, do not jump straight into checkout testing. First, confirm that the PDF Invoices menu appears under WooCommerce. If the menu item is missing, check the dependent framework plugin, then temporarily disable conflicting admin optimizers or plugins that hide menu items by role. That is much faster than trying to generate PDFs into a void.

A safe first sequence

1. Activate WooCommerce and make sure the order list opens without errors.
2. Install and activate the PDF invoices plugin from the correct ZIP file.
3. If the warehouse needs packing slips, install and activate the separate packing slips component included in the package.
4. Confirm that the PDF Invoices settings item appears under WooCommerce in the admin panel.
5. Open the general settings, but do not enable mass attachment delivery to live customers yet.
6. Select a test order and check the preview.
7. Save the settings, create or update the PDF manually, then download the file from the order screen.

At this stage, it is important to separate PDF generation from email delivery. First, make sure the file is created and opens in the browser or in a PDF viewer. Only after that should you enable automatic email attachments. If you do it the other way around, you introduce two unknowns at once: was the document generated, and was the email sent.

Where to look for the invoice after generation

The weLaunch documentation points to several locations: the order overview in the admin panel, the single order screen, the thank-you page, and the order section in the customer's account area. For an administrator, the fastest path is the order list and the individual order screen. For the customer, the important places are the email, the post-checkout page, and the account area.

If you do not see the link in the account area, check two things: whether the option to show the invoice to the customer is enabled, and whether the document has actually been generated for that specific order. A customer cannot download a file that does not exist yet or is hidden by configuration.

Main Settings Map: What to Enable Right Away and What to Leave for Later

The plugin's settings area is broader than it looks on the first screen. It covers the general invoice creation logic, email attachments, customer visibility, tax modes, numbering, layout, header, address blocks, content text, footer, preview, and advanced CSS settings. The right approach is to build a reliable minimum first, then add styling and extra documents.

General settings

In the general settings, you decide whether the plugin should create PDFs automatically, attach invoices to emails, show them to customers, and open PDFs in the browser instead of forcing an immediate download. For a test rollout, it is usually enough to enable document generation for the selected status and allow admin viewing. Turn on email attachments and customer visibility only after the PDF already opens correctly when tested manually.

If your store sends the document only after payment, do not enable generation for a status that may occur before payment. Questions about invoices for failed orders have come up in discussions, and the developer pointed users to the settings that control which statuses generate invoices. The practical point is simple: the document should not go out before the business event you consider the trigger for invoicing.

Invoice numbering

Numbering is one of the most sensitive sections. The plugin supports its own number format, prefix, date, and sequence. In practice, that means the format should be agreed on before mass generation begins, especially if the store is migrating from another solution and wants to continue an existing sequence. In comments related to the documentation, the developer confirmed that you can define a starting number, but changes like that are best tested on a test order first and should not be applied to old orders without a backup.

Do not change the numbering scheme on a live store just to make it look nicer. First, write down the current logic: what counts as the invoice number, what counts as the order number, whether a prefix is required, what happens with refunds, what to do with canceled orders, and how accounting searches for the document. If you are not sure, use a clear format and do not regenerate numbers in bulk without a separate review.

Layout, fonts, and basic readability

In the Layout section, you can adjust spacing, font family, font size, color, and line height. Do not try to build a complex branded document on day one. The first good PDF should be boring but readable: the logo is in place, addresses do not overlap, the product table does not break, tax lines are visible, the total is easy to read, and the footer does not jump to a new page for no clear reason.

If the document needs to support multiple languages, check the character rendering right away. In discussions, the developer confirmed RTL and Korean support, but the actual result depends on the selected font and the PDF library. For Cyrillic, Arabic, Korean, or other character sets, test more than just the heading. Check the product name, address, city, shipping method, and any custom fields as well.

Header, address, content, and footer

The header is a good place for a logo, administrative information, a page number, or recurring text. The address blocks work with order data and custom HTML. The content section controls the introductory and closing text, while the footer usually holds business details, bank information, VAT information, or short payment terms. The documentation shows that order variables are inserted with double curly braces, for example {{billing_first_name}}, {{billing_last_name}}, {{payment_method_title}}, or {{shipping_method_title}}.

Do not overload the address blocks with everything at once. On the left, the customer name and address are usually enough. On the right, the document number, order date, customer number, or a short internal note is typically all you need. If you try to place the logo, long text, bank details, and payment terms in the same block, readability suffers. Company details are usually better placed in the header or footer than in the middle of the address area.

Additional PDF documents attached to email

The weLaunch documentation includes a separate article about custom PDF documents: in the general settings, you can attach up to three additional PDFs to emails along with the invoice. That can be useful for return terms, a warranty reminder, instructions for a digital product, or a delivery-related document. Still, it is better to enable this only after you have checked email size and the customer experience.

If you attach a large instruction PDF to every email, some mail systems may handle the message less reliably. For heavier documents, it is usually safer to provide a link to an instruction page instead of attaching the file to every order. Attachments make the most sense for short required documents that genuinely need to travel with the invoice.

Order Variables and the Invoice Template: How Not to Break the Document with Data

The strength of the plugin is that the template can use order data. But this is also where many documents turn into chaos: the store owner sees a list of variables and tries to output everything available. A good invoice does not need to show every WooCommerce field. It should show what the customer, the manager, the warehouse, and accounting actually need.

What data is available

The invoice data fields documentation lists a broad set of order fields: ID, invoice number, status, currency, discount totals, shipping, tax, grand total, customer details, payment method, shipping method, billing and shipping fields, custom meta keys, and other values stored in the WooCommerce order. Variables are inserted with curly braces such as {{billing_company}}, {{billing_email}}, {{customer_note}}, and so on.

The key practical takeaway is this: if the data is not in the order, the variable will not magically create it. For example, if checkout does not collect a separate VAT number, you cannot output it correctly unless a real field is stored in the order. If the customer did not fill in the shipping company, displaying that variable will simply leave an empty space. That is why you should inspect the order first and only then adjust the template.

The minimum set for a clear invoice

For most stores, the following is enough:

• The invoice number and the order number, if they are different.
• The order date or document date, if it is available and required by your process.
• Seller details: business name, address, tax ID, and contact information.
• Customer details: name, company, address, email, or phone number, if needed.
• A product table with item name, quantity, price, discounts, taxes, and totals.
• Payment method and shipping method, if they help validate the order.
• A short closing note with payment terms or a brief message.

If your store ships products, do not mix billing and shipping data without a reason. The billing address is often what the invoice needs, while the shipping address is more relevant for the packing slip or logistics. You can show both in one PDF, but separate them visually so the warehouse does not mistake the billing address for the delivery destination.

Custom fields and caution with meta data

weLaunch states that you can use standard WooCommerce order data and custom meta keys. That is useful for VAT numbers, booking times, delivery dates, attendee details, RRP fields, or any other data added by third-party plugins. But a custom field should be checked on three levels: whether it is actually saved in the order, what the meta key is called, and whether it is available at the moment the PDF is generated.

If a field outputs nothing, do not start by editing the HTML. First open the order and confirm that the value is really there. Then use Preview on an order where that field is populated. If the field comes from a third-party plugin and uses a different storage format, you may need an official filter hook or help from the developer.

When a filter hook makes sense

The weLaunch documentation lists filters that let you modify invoice data, order data, product lines, and the HTML of individual elements. That is no longer a store-manager setting. It is developer-level work. A good use case for a filter hook is outputting an extra value that exists in order meta but is not exposed through a standard variable.

Do not drop PHP snippets into your theme at random. If there is a documented hook, use a child theme or a snippets plugin, test it on a staging copy first, and then on a single order. After verification, always open the PDF, the email, and the order screen. If a PHP error appears, roll back the snippet before it affects new orders.

Taxes, Rates, and Total Lines in the PDF Invoice

The tax side of the setup should not be handled inside the PDF plugin in isolation from WooCommerce. The plugin pulls data from the order, and the order calculates taxes based on WooCommerce settings: whether tax calculation is enabled, how prices are entered, which address is used for tax calculation, how prices are displayed in the cart and checkout, and how tax totals are displayed. That means a PDF issue often starts not in the template, but in the store's core tax settings.

What to check in WooCommerce

WooCommerce recommends enabling tax calculations in WooCommerce - Settings - General, then configuring the Tax section. That is where you define prices entered with tax, calculate tax based on, shipping tax class, rounding, display prices in shop, display prices during cart and checkout, and display tax totals. For PDF invoices, the cart display mode and tax total display mode are especially important.

The weLaunch tax documentation for PDFs explicitly says that if you use different tax rates, you should configure checkout price display as excluding tax, set display tax total to itemized, and give each tax rate a unique name. That makes it possible to show separate rates in the PDF instead of one unclear combined tax line.

When you need a separate tax line

If the customer needs to see tax as a separate line, check how WooCommerce displays tax in the cart and during checkout. In the weLaunch article about tax as a new line, the recommendation is to change Display prices during cart and checkout to Excluding Tax. After that, a separate tax line should appear in the PDF. But before making that change, discuss it with your accountant. Your store may need to present prices differently depending on your market or sales model.

Do not use the PDF as the place to patch incorrect tax logic. If the order total is wrong, a polished PDF will only preserve that mistake in a formal document. First make sure the WooCommerce order itself is correct, then verify the PDF.

Testing different tax scenarios

For testing, create several orders: a product with the standard rate, a product with a reduced rate, an order with shipping, an order with a coupon, and an order with different tax classes. Open the PDF for each order and check whether the subtotal, shipping, tax, discount, and total match the order screen. If the store sells only within one jurisdiction, this check is faster. If you sell internationally, your test set should reflect real customer addresses.

If the tax name in the PDF is wrong, check the tax rate name in WooCommerce. If tax amounts differ by a few cents, review rounding and any mixed price-display modes. WooCommerce specifically warns that combining different tax display settings can lead to unexpected rounding behavior.

Preview and Manual Regeneration: How to Safely Get the PDF into Production Shape

The plugin includes an important Preview feature: you can choose an order ID and see what the PDF will look like. This is not just a cosmetic option. It is the main setup tool. Without Preview, you are forced to evaluate the document only after creating an order and downloading the file, which slows everything down and increases the risk of sending customers an unfinished template.

How to use Preview

Start by selecting a test order with real products, an address, shipping, and tax lines. Then change only one part of the template at a time: header, address, content, footer, layout, or CSS. After every change, save the settings and open Preview. If you edit five areas at once, you will not know which setting broke the table or shifted the address block.

In Preview, do not look only at the first page. A long order may push the product table onto the next page. The header and footer should behave predictably, and the total should not end up detached from the table. If your store often sells bundles with many line items, test with an order containing 10 to 20 rows, not just one product.

Manual creation, update, and download

From the order screen, you can create, download, or update the PDF. This is useful when you have changed the template and want to rebuild the document for a specific order. But updating an old invoice may be sensitive from an accounting perspective. If the document has already been sent to the customer and entered into accounting, do not update it without understanding the consequences. For a test order, that is safe. For a real order, it is a process question.

During implementation, it helps to keep a separate checklist:

• The PDF opens without errors in the browser or PDF viewer.
• The file downloads from the order list.
• The file is available from the order screen.
• The customer link appears only in the places where you enabled it.
• The email includes the attachment only for the intended WooCommerce email events.
• Regenerating the PDF does not break the document number or content.

A good sign that you are ready: the store manager can open an order, download the PDF, and explain why the document contains that specific number, those tax lines, and those addresses.

Packing Slips and the Warehouse Workflow

The product name includes Packing Slips, but a packing slip serves a different purpose than an invoice. The invoice is for the customer and accounting. The packing slip is for the warehouse, the picker, or the admin handling fulfillment. That means its structure can be simpler: products, quantities, variations, shipping address, internal notes, and, if needed, no prices at all.

When the packing slip matters more than the invoice

If your store sells physical products, the packing slip helps prevent fulfillment mistakes. Warehouse staff can see what goes into the package, how many units, which product variation was selected, and whether there is a customer note or a shipping-specific instruction. For this kind of document, prices and tax lines are not always necessary. In some cases, price information actually gets in the way, especially if the slip is used by a third-party warehouse or placed inside the box.

If your workflow needs only the warehouse document, verify that the separate packing slips plugin from the main package has been installed. In weLaunch comments, users were told directly that packing slips are a separate plugin inside the downloaded package. This matters for troubleshooting: if the Packing Slips item is missing, it may not be a settings problem at all, but simply an uninstalled component.

What to show in a packing slip

For a packing slip, the useful fields are the shipping address, product name, SKU, variations, quantity, weight or size-related notes if your store uses them, and internal instructions. If your orders include paid options such as engraving, color, size, or bundle selection, check how those meta values appear. Overly detailed meta data can make the document too long, but hiding all meta data may remove information the picker actually needs.

Keep invoice settings and packing slip settings separate based on purpose. If the invoice is heavily branded, that does not mean the warehouse slip should look the same. The warehouse needs a large clear table, readable quantities, and minimal decorative text.

Bulk download and printing

The plugin can download invoices or packing slips from the order list, including in bulk. For a warehouse, that is convenient: filter orders by status, download a batch of documents, print them, and hand them over for picking. But the bulk workflow requires disciplined use of statuses. If canceled, failed, or unpaid orders slip into the selection, the documents may be unnecessary or misleading.

Before daily printing begins, define a simple rule: which status means "ready to pick," who moves the order into that status, when the slips are downloaded, and what happens if the order changes afterward. Technically, the PDF can be created quickly, but the process needs to prevent duplicate printing and outdated documents.

Practical Example: Set Up an Invoice for a Test Order and Verify the Email

Below is a simple implementation example for a typical store: after a paid order, a PDF invoice should be created, the customer should be able to download it from the email or account area, and the manager should see the document on the order screen. The goal is not to create a perfect legal template, but to build a working, verifiable workflow.

Goal

Create a PDF invoice with the store logo, customer details, a product table, a tax line, a grand total, and a short closing message. The document should be downloadable from the order screen and attached to the WooCommerce email only after manual verification has passed.

Preparation

Create a test product with a price, enable the required tax rate, place a test order, and make sure the order contains a billing address, customer email, payment method, shipping method, and the status you plan to use for generation. If WooCommerce emails are not working yet, fix email delivery first without involving the PDF plugin.

Setup steps

1. Open the PDF Invoices settings under WooCommerce and enable PDF generation for orders, but do not enable customer attachments until you have verified the output.
2. In the numbering section, define a simple format that is easy to distinguish from the order number, if your workflow requires that.
3. In Layout, choose a readable font size and spacing. Do not shrink the text just to make room for the logo.
4. In Header, add the logo or store name along with a short operational note.
5. In Address, place customer details using the variables {{billing_first_name}}, {{billing_last_name}}, {{billing_company}}, {{billing_address_1}}, {{billing_postcode}}, {{billing_city}}.
6. In Content, add a short introduction and, if needed, the lines {{payment_method_title}} and {{shipping_method_title}}.
7. In Footer, move the seller's business details and bank information there if they need to appear in the document.
8. Open Preview, select the test order ID, save the settings, and inspect the PDF.
9. Create or update the PDF from the order screen and download the file.
10. Only after the download succeeds should you enable the attachment for the required WooCommerce emails and send a test message to your own address.

Result verification

Open the PDF and verify it against the order data, not just by asking whether it "looks good":

• The invoice number is not empty and matches your numbering scheme.
• The customer, address, and company are pulled from the correct billing or shipping fields.
• The products, quantity, discount, shipping, tax, and total match the order screen.
• The tax rates are labeled clearly and are not merged into one confusing block if you use multiple rates.
• The PDF opens after download and does not report file corruption.
• The WooCommerce email arrives once and contains the expected attachment.

A nuance that often appears after launch

If the customer does not receive the attachment after you enable email delivery, do not change the PDF template. Check which email event the attachment is tied to, what status the order has, whether the WooCommerce email itself is being sent, whether the mail server has attachment limits, and whether an SMTP plugin is interfering. If the PDF downloads from the order but never arrives by email, generation is working and the problem is in the delivery chain.

Safe Improvements to Appearance and Data

The plugin supports advanced settings and customization. But a safe enhancement is very different from random tweaking. It is small, reversible, tested on a single order, and based on a documented mechanism: advanced custom CSS, order variables, or official filter hooks. The options below are limited to cases confirmed by the weLaunch documentation and do not require editing the plugin core.

Align the price and quantity columns

weLaunch provides a CSS example for centering the price and quantity columns in Advanced Settings. This makes sense when the product table looks uneven and the totals are hard to scan. Add the CSS in the plugin's advanced settings, not in the theme's general CSS, because this is about the PDF template.

table th.th-showPrice,
table td.td-showPrice,
table th.th-showQty,
table td.td-showQty {
  text-align: center;
}

The check is straightforward: open Preview for an order with multiple items and confirm that the alignment changed only in the intended columns. If the whole document looks worse, remove the CSS from Advanced Settings and go back to the previous version.

Hide unnecessary meta options in the product line

If a third-party plugin adds many options to the product, the PDF can become long and hard to read. In the weLaunch documentation, a similar case is handled by hiding .wc-item-meta. This works only if all of that meta data is truly unnecessary on the invoice. For a packing slip, the same CSS may be risky because the warehouse could lose important order details.

.wc-item-meta {
  display: none;
}

Before applying it, compare two documents: the customer invoice and the warehouse packing slip. If the meta data is important to either process, do not hide it globally without separate validation. A longer document is better than removing the size, color, personalization, or a key picking instruction.

Add an extra price or RRP through a hook

For developers, weLaunch shows an example using the woocommerce_pdf_invoices_product_price_html filter to add an RRP/UVP value from product meta to the item price. This is useful if the store stores an additional price in a meta key and wants to display it in the PDF. Code like that belongs in a child theme or a separate safe plugin, not in the product's own files.

For a practical guide aimed at store managers, it is enough to understand the principle: if the data already exists in the product or order, it can be displayed through a built-in variable or a documented hook. If the data does not exist, you first need to configure how it is saved in WooCommerce. Any PHP snippet should be tested on a staging copy and a single test order, not on a stream of live orders.

Emails, the Customer Account, and Roles: Where the Customer Actually Sees the Document

Once the template is configured, one important user-facing layer remains: how the customer and the admin actually receive the PDF. For the store owner, this may look like a single option such as "attach invoice to email," but for the customer the path includes several touchpoints: the post-order email, the thank-you page, the order section in the account area, and sometimes a resent email after a status change. If those points are not thought through in advance, the document may be generated but the user still will not know where to find it.

Which WooCommerce emails should receive the attachment

In WooCommerce, different emails correspond to different order events. The customer may receive a message after the order is created, after payment, after processing, or after completion. The admin receives separate notifications. Do not attach the PDF to every email just because the system allows it. If the invoice should be sent after payment is confirmed, it makes sense to tie it to the email that goes out after the correct status, not the very first order-created notification.

For testing, create a separate customer email address, place an order, and save every message. Then verify not just whether the attachment is present, but whether the email itself makes sense. For example, if the message says "order received" while the PDF already looks like a final invoice, that may not match what accounting expects. If the "order completed" email is sent after shipment, the invoice may fit better there, but everything depends on your store's process.

There is another technical point here: mail services handle attachments differently. If the PDF is large because of logos, product images, or extra documents, the email may be delayed, sent to spam, or blocked on the recipient side. That is why, after enabling attachments, you should test delivery to a normal mailbox, a corporate mailbox, and, if possible, review the SMTP logs. You need to confirm not only "sent" but "received with attachment."

The customer account and the thank-you page

Showing the PDF in the account area is convenient for repeat downloads. The customer does not need to hunt down an old email or contact support when they need the document again. But this only works when the order is linked to an account or WooCommerce correctly displays the order details. Guest-order behavior may be different, so test both scenarios: an order placed by a logged-in user and a guest order, if your store allows purchases without registration.

The thank-you page is useful immediately after checkout, but it should not be the only place where the document exists. The customer may close the page, the email may arrive later, or the invoice may not be generated instantly if you tied generation to a later status. That is why your email copy and support responses should use a simple message: the document is available in the email and in the order details once it has been created for that order.

Administrator, shop manager, and warehouse staff

In the WooCommerce admin panel, orders are visible to administrators and shop managers. For the PDF workflow, that means not every site user should see the documents, but the manager handling the order should be able to download and update them. If your store uses separate roles for warehouse staff, support, or accounting, check their access separately. Hidden menu items, role managers, and custom restrictions can create a situation where the admin sees everything but the manager on shift cannot download the packing slip.

Separate responsibilities clearly. The store manager may create or update the PDF if the order total changes. The warehouse may download or print the packing slip for fulfillment. Accounting may verify the document number and total lines. Support may tell the customer where to download the document. If every role relies on the same PDF as a "universal document," it quickly accumulates too much text for some users and not enough information for others.

How to avoid repeated emails and confusion after an order changes

Changing an order after an email has been sent is a normal situation: the customer updates the address, the manager adds an item, a refund is issued, or shipping changes. At that point, you need to know whether the PDF updates automatically, whether someone must click update invoice manually, and whether a new email will be sent to the customer. If the process is undefined, staff can end up sending two different documents with the same number or forgetting to update the invoice after the total changes.

Define an internal rule before launch. For example: if products, shipping, tax, or the total changes, the manager updates the PDF and adds an order note. If only an internal note changes or the status changes without a financial impact, the PDF stays untouched. If the customer needs a new file, one designated employee sends the email, not everyone who happened to open the order. This is an operational rule, but without it, technical automation creates a real risk of duplication.

Pre-launch check: modify a test order after generating the PDF, update the document manually, and see what happens to the number, the file, the email, and the link in the customer account. This one test immediately shows whether the store is ready for real order edits.

Common Issues and Troubleshooting

PDF invoice issues rarely have one universal cause. The same symptom can come from an order-status setting, a missing PHP extension, a broken template, WooCommerce email behavior, excessive meta data, or an uninstalled packing slips component. That is why troubleshooting should move from the simple checks to the more complex ones.

The PDF Invoices menu is not visible in WooCommerce

Symptom: the plugin is active, but the expected PDF Invoices item does not appear under WooCommerce in the admin panel. Possible causes include the required framework plugin not being active, a permissions conflict, or a failure in loading the admin settings.

Check the plugins list and make sure the dependent components are active. Then sign in as an administrator, not under a restricted manager role. If the menu appears after disabling an admin role manager or menu optimizer, the cause is access control, not PDF generation.

The PDF is generated but not attached to the email

Symptom: the file is available from the order screen, but the customer email arrives without the PDF. Possible causes include the attachment not being enabled for the correct email event, the order being in the wrong status, the WooCommerce email itself not being sent, or the SMTP service stripping attachments.

Start by downloading the PDF from the order. If the file exists and opens correctly, generation is working. Then send a WooCommerce test email without the PDF and verify delivery. After that, check which emails the invoice is attached to. Do not change the document template until you have shown that the problem is actually in generation.

The PDF does not open or appears corrupted

Symptom: the file downloads, but the PDF viewer reports an error. In documentation comments, the developer recommended enabling MPDF debug mode and looking for the generation error. Another reported issue involved the missing mbstring PHP extension.

Enable debug mode in Advanced Settings, open the HTML output or PDF library message, and check the server extensions. If the problem began after adding custom HTML, CSS, or a PHP snippet, temporarily remove those changes and rebuild the PDF. If the default template works, the issue is in the customization.

Taxes appear as a single line or do not match expectations

Symptom: the PDF does not show separate tax rates, the rate names are unclear, or the totals do not match what accounting expects. Possible causes include WooCommerce tax display settings, non-unique tax names, mixed inclusive and exclusive modes, rounding, or the wrong tax calculation basis.

Open WooCommerce - Settings - Tax and review display prices during cart and checkout, display tax total, and the tax rate names. Create one test order with a single rate, then another with two rates. If WooCommerce already shows the amount incorrectly, the PDF plugin should not be your first place to fix it.

Packing slips do not appear in the interface

Symptom: invoices work, but packing slips cannot be downloaded. In discussions, the developer explained that packing slips are a separate plugin inside the main package. Check whether the second component from the downloaded archive is installed.

If the component is installed, verify which document is available on the order screen and in the order list. If you only have the invoice but the warehouse needs a packing slip, do not try to turn the invoice into a warehouse document with CSS. Configure the separate document or install the required component.

The document shows too many lines from third-party product options

Symptom: the product line becomes overly long because of Extra Product Options or a similar extension. One possible cause is that all product meta options are being output into the PDF. weLaunch suggests hiding .wc-item-meta with CSS, but that solution is not always appropriate.

Before hiding anything, check which meta data matters to the customer and the warehouse. If it is just decorative technical data, hiding it may be fine. If it includes size, color, delivery date, personalization, or a booking slot, hiding it will make the document worse. In that case, you need a more targeted template or developer-level customization.

Images in the PDF show up as a red X

Symptom: the logo or product image does not render and appears as a broken image. Possible causes include an image URL that is not accessible to the PDF library, a server restriction, hotlink protection, an SSL issue, or a path that the browser can open but the server-side PDF generator cannot fetch.

Check whether the image opens by direct URL without authentication, use a file from the media library, temporarily disable external-access protection, and test the PDF with a simple small logo. If debug mode shows a file-loading error, fix image accessibility, not the font size or the table layout.

How to Evaluate the Result Before Using It on Real Orders

Before enabling the plugin in your live order flow, run a small acceptance check. This is not a full site test. It is a review of one specific document process. The more carefully you do it, the fewer surprises your customers and managers will face.

A control set of orders

Create or select several orders that reflect real store scenarios:

• One simple product without a discount.
• A product with a variation or custom option.
• An order with a coupon.
• An order with shipping and shipping tax.
• An order with two tax rates, if that happens in your store.
• A long order with many line items.
• An order where the billing address differs from the shipping address.

For each order, download the PDF, check the email, open the customer's account area, and confirm that the document is available exactly where it should be. If the store has a warehouse workflow, print the packing slip separately and hand it to the person who actually fulfills orders. They will usually spot missing SKU data, variations, or shipping details faster than anyone else.

What counts as a successful launch

Success is not "the PDF looks nice." Success is when the document accurately reflects the order, the manager understands how to update it, the customer gets the file without extra effort, and any sensitive tax or accounting requirements have been validated outside the plugin. If, after testing, you still cannot explain exactly when the invoice is created, which emails receive the attachment, and why the number uses that format, then the launch is not ready yet.

A good final question is this: what happens if the order changes after the invoice is created? If you do not know the answer, test a manual update on a test order and define an internal rule. For example: if the products or total change, the manager updates the PDF manually and leaves an order note. If only an internal note changes, the PDF is left alone.

When CodeCanyon WooCommerce PDF Invoices & Packing Slips Is a Good Choice

This product is worth using if you need a manageable PDF document workflow directly inside WooCommerce: the invoice is created from the order, can be attached to email, shown to the customer, downloaded by the admin, configured through template blocks, and reviewed through Preview. It is especially useful when the invoice and the packing slip need to be part of the normal order-processing workflow rather than a manual file created after the sale.

Before launch, follow a short path: install the correct components, verify the menu, create a test order, configure numbering, output the required variables, validate taxes against WooCommerce, test Preview, downloading, the email, and the customer account. If that path works without issues, you can download the installation package and move on to a careful rollout in your live store.

If, however, you need more than just a PDF - for example, a complex accounting integration, distributed numbering across multiple sites, specific electronic standards, or mandatory exchange with an accounting system - do not stop at a good-looking invoice. First verify support for the required workflow in the documentation, contact the developer, and compare alternatives. A good PDF plugin should support the process, not hide unclear accounting requirements.