EDD PDF Invoices - WordPress Plugin

EDD PDF Invoices: A Practical Guide to Invoices for a Digital Store

EDD PDF Invoices addresses a specific need that matters to any digital store: after an order is paid, the customer should be able to get a document showing the seller’s details, what they bought, and how much they paid. In older installations, this was a separate PDF Invoices extension. In the current Easy Digital Downloads ecosystem, its features are part of the Invoices feature. This guide does not present the outdated extension as a new product. Instead, it shows how to maintain an existing PDF Invoices setup safely and how to configure the recommended modern option for a new store.

This guide covers more than the settings form. It starts with a check of your EDD setup and store pages, then walks through creating an invoice page, linking to it from the purchase email, choosing rules for free orders and address editing, placing a test order, and troubleshooting the full flow. It also explains where invoice delivery ends and accounting or local legal requirements begin.

The main idea is simple: an invoice does not appear automatically after installation. It needs a valid order, an accessible entry point for the customer, the store’s business details, and a test using a real use case. If any link in that chain is missing, the customer may see the wrong document, an empty page, or no link at all.

How the extension fits into the order flow

Easy Digital Downloads stores each order as a store record. It includes the customer, line items, totals, status, and other details needed to process the sale. EDD PDF Invoices is not a separate checkout system and does not replace a payment gateway. Its role is different: it takes confirmed order details and presents them to the customer in a document they can view, print, or save as a PDF.

Four parts make up this flow. First, the customer completes an order and receives an email or opens their purchase history. Second, there is the invoice page assigned in the settings. Third, there is the store’s business information: name, address, registration or tax details, logo, and any additional text. Fourth, the administrator can open the invoice from the order and compare it with the original record. Keeping these roles separate helps prevent confusion between the customer-facing document, payment settings, and a basic confirmation page.

The current option and the legacy option

For a new installation, follow the current EDD documentation for Invoices. The feature requires EDD Pro, is configured under Downloads > Settings > Payments > Invoices, uses a page containing the [edd_invoices] shortcode, and lets visitors print or download a PDF. Choose this option if you are launching a store or have not yet implemented PDF Invoices.

Treat the old PDF Invoices extension as a legacy migration case for an existing store. Its settings were under Downloads > Settings > Extensions > PDF Invoices in the older documentation. The extension added a document link to purchase history and let you insert the {invoice} tag in an email. The developer explicitly marks it as legacy and says it no longer receives updates or support. Do not assume it is compatible with a newer environment without testing it on a copy of the site.

Do not mix the two interfaces. If your admin dashboard has a Payments > Invoices section, follow the current instructions. If the store already uses the old PDF Invoices tab, record the existing settings first and test the migration on a staging site. Configuring similar features at the same time without knowing which one is active can lead to unexpected links and different document templates.

What the feature does with order data

The starting point is a completed EDD order, not a PDF uploaded in advance. The settings determine which page handles invoices, which store details are added, whether customers can edit their address, and whether invoices are hidden for zero-total orders. In the current version, the output is an HTML invoice with Update, Print, and Download PDF actions. The administrator can also view the document from the order record.

Keep this limitation in mind when setting expectations. The plugin does not turn arbitrary text from custom checkout fields into a legally compliant template, and it does not guarantee compliance with every country’s requirements. The old PDF Invoices documentation specifically says that additional custom checkout fields do not appear in templates without further development. First confirm that the built-in fields are sufficient, then consult an accountant or developer about requirements beyond the store document itself.

Who this setup is for, and when to consider another tool

EDD PDF Invoices is a natural fit for a store that sells files, plugins, courses, graphics, audio, templates, or other digital products through Easy Digital Downloads. The customer gets a familiar document for their order, and the store team does not have to create one manually. This is especially useful when customers regularly request business details, buy on behalf of a company, or need a document for their internal records.

It is also useful when customers should be able to access invoices from their purchase history and purchase email. In current EDD, purchase history is displayed with the EDD Order History block; older sites may use [purchase_history]. In either case, the goal is the same: customers should not have to contact support for a document after every purchase.

A good fit for the store

• The store sells digital products through EDD and already creates valid order records.
• Customers need a clear document showing the order, store details, and total.
• The team has a consistent set of business details and a logo that can be included in documents.
• The team is ready to place a test order and check the email, purchase history, and admin access.
• Customers need a self-service way to reopen the document after purchase.

When to clarify the requirements first

Do not treat EDD PDF Invoices as a complete accounting system. If your organization needs bookkeeping entries, complex numbering rules, multiple legal entities, electronic document exchange, credit notes, local document formats, or integration with specific accounting software, map out the business process first. Some requirements may call for a specialized system or a custom integration. Likewise, installing WooCommerce just to get documents makes little sense if the store already runs on EDD: it changes the entire catalog, checkout, and support model.

For a store with physical products, packing slips, and shipping, a WooCommerce-specific solution is usually a better fit. If you have no EDD orders and need standalone invoices and service quotes, a separate WordPress invoicing system may be appropriate. The alternatives below represent different ways of working, not replacements to install just in case.

Before you start: what to check before installing or enabling the feature

Preparing the store can save more time than fine-tuning the document’s appearance later. An invoice depends on an order, the email depends on mail delivery, and the invoice page depends on being assigned correctly. So start with the state of the store, not the logo. Create a restore point or work on a staging copy first. This is especially important for a legacy installation: because the extension is no longer maintained, a newer version of PHP, a theme, or another add-on may need extra testing.

A basic preflight checklist

1. Make sure Easy Digital Downloads is active and the Downloads menu appears in the admin dashboard.
2. Open Downloads > Settings > Pages and check the store’s main pages: checkout, confirmation, receipt, and order history.
3. Check at least one product: it should have a price, a file, and a clear name. A document cannot show the full customer experience without a real order.
4. Confirm which option you are using: the current Invoices feature in EDD Pro or the old PDF Invoices extension on an existing site.
5. Prepare the approved company name, mailing address, registration number, and tax number, if they need to appear on the document.
6. Prepare a small logo image and keep the original file. Do not rely on the PDF generator to shrink a large banner without losing quality.
7. Create a separate test email address for the order and make sure you can access it during testing.

Check the theme and caching as well. Caching can help with static pages, but order details, receipts, and purchase history require dynamic context. EDD’s official receipt documentation warns that aggressive caching can break document output because the system cannot tell which order to display. Do not treat caching as the default cause of every issue, but add checkout, confirmation, receipt, order history, and invoice pages to the list of pages to check carefully after enabling caching.

Business details and privacy are separate concerns

Your company name and address help customers, but do not turn the invoice into a dump of internal data. Enter only the details customers should see. If your organization uses a registration or tax number and is permitted to display it, enter it in the appropriate field. If there is no such requirement, leave the field blank rather than filling it with a placeholder. Review a test invoice as carefully as you would a checkout form: it may be sent to a customer and become part of their internal records.

The option to allow address editing also affects privacy and accuracy. In the current feature, Disable Address Editing? prevents customers from changing their name, address, and tax number when creating an invoice. Enable it when the document should reflect only the order details or your company’s rules do not allow customers to edit them. Leave editing enabled when your process allows customers to enter their company details before downloading the document. In either case, agree on the workflow with the people responsible for your documents.

Install the feature and run an initial check

The installation process depends on which option you use. In current EDD Pro, extensions and features are available through the EDD ecosystem. The documentation recommends installing and activating EDD Pro first and verifying the license. Available extensions then appear under Downloads > Extensions, where you can install and enable them. If the built-in installation does not work, the official method is to upload the ZIP file you received through WordPress’s standard uploader, not to extract files into an arbitrary server folder.

For the old PDF Invoices extension, use only a legitimate archive you already received or an existing installation. Do not edit the extension files manually or look for questionable builds. After activation, do not jump straight into styling the document. Refresh the admin dashboard, make sure EDD itself shows no errors, and find the settings path for the version you are using.

Your first checkpoint in WordPress

Sign in as a user who can manage store settings. For the current feature, open Downloads > Settings > Payments > Invoices. If you are maintaining an older site, the path in the old documentation is Downloads > Settings > Extensions > PDF Invoices. If the tab is missing, do not try to create it manually. First check that EDD Pro is active, the extension is enabled, and your site’s current version is compatible.

Before changing live settings, save a screenshot or list of the current values. This is practical, not bureaucratic. If the document changes after you update the template or address, you can restore the specific field instead of rolling back every WordPress update. On a live store, it is sensible to make changes during a quiet period because customers may open an old link while you are working.

Create an invoice page with the current Invoices feature

Create a regular WordPress page, for example titled "Invoice," and add exactly the [edd_invoices] shortcode to its main content. Then return to Downloads > Settings > Payments > Invoices, select that page in the Invoice Page field, and save your changes. The official documentation makes the dependency clear: invoices will not work if the selected page does not contain [edd_invoices]. This is the most important step, and the one that is easiest to miss.

Do not use the invoice page as a public storefront or fill it with ads, a contact form, or a long article. Customers come there for a document, so the page should be concise, clear, and compatible with the theme. If someone visits the page directly without order details, an empty page or a message that no order can be found may be expected. Test the page by following a link from an actual email or purchase history, not just by clicking View in the page editor.

Settings at a glance: from company details to the PDF button

It is easier to configure the settings in two passes. First, make sure the feature works: assign the page and save the minimum required company details. Then refine the appearance and rules until you can verify them with a test order. This order makes troubleshooting easier: changing an accent color will not fix a page that is not connected.

The page, logo, and document style

Invoice Page tells the system where to send the customer. Logo URL provides the address of the logo used on generated invoices. Open that URL in a private browser window first. If the image requires a login, uses a temporary link, or returns an error, the PDF generator may not be able to retrieve it either. The old PDF Invoices extension has an additional limitation: a logo that is too tall may not appear. Its documentation specifies a maximum height of 90 pixels, or 80 pixels for Traditional, and output at 96 dpi. For an existing legacy setup, a modest horizontal logo is safer than relying on automatic scaling.

In the current Invoices feature, choose a suitable Invoice Style and accent color. Do not choose a color just because it is part of your brand palette. Invoices are often printed, viewed on different screens, and sent to an accountant. Check the contrast of headings, the readability of totals, and make sure light text is not placed on a light background. A template controls the appearance of the document; it does not add missing legal details.

Company name, address, and registration and tax numbers

The Company Name and Address, Registration Number, and Tax / VAT Number fields make up the document’s fixed details. Enter the approved legal wording, including punctuation and line breaks. Do not copy business details from an old PDF without checking them against current company records. If the store is run by an individual who has no separate registration number, do not make one up.

It is important to distinguish fixed details from order details. This section contains the seller’s information. The customer’s name, address, and tax number may depend on the order and whether editing is allowed. Do not use the company name field for a shipping, licensing, or promotional note: it will appear on every order and quickly become confusing.

Additional text and the limits of template tags

Additional Text is suitable for a brief, consistent note at the bottom of the document, such as a neutral thank-you or a contact channel for order questions. The old PDF Invoices documentation says that HTML is not supported in Additional Notes and that template tags are allowed only in Header Message, Footer Message, and Additional Notes. This means you should not copy EDD or other extension tags into those fields without checking that they are supported.

A practical approach is to start with plain text and no variables, create a test invoice, and then add an approved dynamic tag if needed. Check the PDF after each change. Document fields are not a landing page editor: short, accurate text is more reliable than complex markup that the PDF engine may not support.

Zero-total orders and address editing

Disable Invoices for Free Purchases turns off invoice generation for orders with a total of 0. There is no universally correct setting. Enable it if free downloads are routine and customers do not need an invoice for them. Leave invoices enabled if a free order still represents a meaningful grant of access and the customer needs a record. Base the decision on your store’s process, not on a desire to reduce the number of files.

Disable Address Editing? affects the customer interface: when enabled, the Update button is hidden. Consider the experience from the customer’s point of view. If the document should use details that have already been confirmed, disabling editing makes that expectation clear. If customers regularly add their company details after purchase, allowing editing may help. After choosing, test both roles: have a customer open the invoice and an administrator check the original order.

Where customers and administrators find the same invoice

An invoice’s usefulness depends not only on how the PDF looks, but also on how naturally it fits into the customer’s journey. With the current Invoices feature, customers can generate a document from purchase history. The document itself offers Update, Back, Print, and Download PDF actions. The Update action depends on the address-editing setting. Administrators can find the invoice under Downloads > Orders and in the order details on the Email tab using View Invoice.

The old PDF Invoices extension used purchase history and a Download Invoice link; the purchase email could include the {invoice} tag. The current Invoices feature documents the {edd_invoice} tag for the text version of the email. This is more than a cosmetic difference. Before replacing any tag, check which version the store uses and send yourself a test email. Do not insert both tags and hope one of them "gets picked up." The customer could receive meaningless text or two links.

Connect the invoice to the purchase email

Open Downloads > Settings > Emails. The current documentation recommends selecting the text version of the email and adding {edd_invoice} to link to the invoice generator. The system replaces it with a View Invoice link for the customer. The purchase email has its own purpose: it confirms the order, while the invoice provides a separate path to the document. Do not remove required template tags unless you understand what they do.

Check the context as well as the link itself. The email should make clear that the link opens an invoice, not another product download or the customer account. If your store supports multiple languages, test the email and document in every language you actually use. If the invoice contains non-English details, check that the PDF displays those characters correctly. The legacy PDF Invoices extension has a setting for cases where characters or non-English text render incorrectly, but enable it only after reproducing the issue in a test document.

Purchase history and guest checkout

Current EDD blocks handle logged-in and guest customers differently. The EDD Receipt documentation says that a guest customer enters an email address to verify the order, while a customer with an account is shown a login form. An invoice does not change this access behavior. Test both a regular registered customer and a separate guest checkout flow if your store allows guest purchases.

Do not publish generic direct links to document pages in your site menu. The correct entry point is purchase history, the purchase email, or an action on a specific order. That way, visitors do not have to guess which invoice to open, and support gets fewer messages saying, "The page doesn't show anything."

How Invoices works: order, rules, document, and verification

This section explains how EDD Invoices itself works, beyond memorizing menu paths. The extension does not give the administrator a separate form to fill out before every sale. Its workflow starts with an existing EDD order. That is why troubleshooting without a test order often leads to false conclusions: the system has no order context from which to get the customer, line items, and total.

The input is a completed order, not an arbitrary page

First, the customer follows the regular EDD checkout flow: they choose a digital product, complete the purchase, and receive a confirmation. The order record appears under Downloads > Orders. EDD’s official documentation says that failed or incomplete purchases can also create records, so do not use the first item in the list as your test. Find the completed test order and check its Test/Live mode, total, and email address.

At this stage, do not confuse order confirmation with invoice confirmation. The order is the store’s primary record. The invoice is a customer-facing representation of data created from an accessible order. If an administrator later edits the order, do not assume that a PDF already downloaded by the customer will update automatically. For important documents, agree on an internal correction policy and test the behavior on a test record.

The rules determine what visitors can do

Next, the settings apply specific rules. Invoice Page specifies where to open the invoice interface. The free-purchase setting determines whether an order with a zero total gets an invoice interface. The address-editing setting controls whether Update is available. Company details and style determine the fixed parts of the document’s appearance. These are not unrelated cosmetic switches; together, they determine whether a particular customer can get a document and what it contains.

It helps to record these decisions in a short team checklist: "Invoice for a free download: yes or no," "Customer can edit address: yes or no," "Assigned page," and "Who approves the business details." That way, a new editor will not change a setting based on intuition and then explain behavior that was never agreed on as part of the business process.

What customers can see: the invoice, print view, and PDF

When customers follow the right path, they see a document with actions, not an arbitrary WordPress page. The current Invoices documentation lists Update, Back, Print, and Download PDF. Each button checks a different part of the flow. Back confirms that navigation works. Print checks the browser’s print view. Download PDF checks that the file is generated and opens. Update checks the access rule for customer details.

Checking a single page view is not enough. Open the PDF in a separate application and check the font, line breaks, logo, and line-item table. Then select print preview. If your template uses a subtle accent color, make sure key totals remain legible when printed in grayscale. This does not replace legal review, but it is a technical check you can perform without guesswork.

Verify the same order in the customer and admin views

The final check is specific to the EDD and Invoices connection: the administrator should be able to find the document from the same order record. The current documentation supports this under Downloads > Orders and via Downloads > Orders > Open Order > Email using View Invoice. Compare the customer’s name, line items, total, and business details with the customer-facing document. If both paths lead to the same coherent invoice, the feature is configured correctly.

If the customer and admin views differ, do not compensate by manually downloading another PDF. First check whether they refer to the same order, whether both use the same Test/Live mode, whether the customer opened an outdated email, and whether the page was served from cache. Comparing both views of the same order is the most reliable check after any settings change.

Business details, templates, and document readability

An invoice should make sense to someone other than the person who built the site. That person is usually a customer, the customer’s accountant, or a support agent. It helps to treat the data review as a small editorial process: the store owner approves the details, an editor enters them in the settings, and someone else checks the finished document. This simple second review catches address typos more reliably than repeatedly changing template colors.

Prepare a logo that will display reliably

A logo on an invoice should be functional. Use a compact horizontal or nearly square mark with a transparent or neutral background. Avoid a large promotional banner, a team photo, or a file with a tiny tagline. The image URL should be stable and accessible without logging in. If the site moved from HTTP to HTTPS or changed its media optimization setup, check the URL again rather than relying on how the image looks in the media library.

The legacy PDF Invoices extension has documented logo height and output limitations, so do not enlarge a PNG to several thousand pixels for "quality." The generated PDF may shrink it, omit it, or handle it differently. Prepare a lightweight version, upload it through WordPress, enter its URL, create a fresh test order, and download the PDF. That file is the real test, not the preview in the settings field.

Why add a separate note to the bottom of the invoice?

Additional text is useful when it is the same on every invoice and contains no variables you have not verified. It could be a short instruction to contact support with order questions or a neutral note about digital delivery. Do not use this field for several pages of refund terms, promotional copy, legally questionable promises, or HTML markup. The old documentation explicitly says that HTML is not supported in Additional Notes.

If the text needs to change based on the product, subscription status, or customer’s country, the built-in field may not be enough. Do not try to turn it into a programming language. First document the requirement, check what the current Invoices feature supports, and only then plan a separate customization on a test copy. This avoids showing customers an untested tag as literal text.

What to check in the layout before launch

• The seller’s name and address do not wrap across awkward lines.
• Long product names do not overlap the quantity or total.
• The total and currency are readable without zooming in.
• The logo does not dominate the page or push order details out of view.
• Additional text does not contain stray template tags.
• Latin and non-Latin characters render correctly in the same PDF.
• The right side of the document remains visible in print preview.

If the document looks unusual, do not start with CSS unless you have confirmed that the PDF generator applies it. In the current Invoices feature, use the built-in style and color options. Be especially cautious with the legacy version. Your theme’s CSS may change the page in the browser without affecting the generated file. Without a confirmed extension point, it is safer to offer practical guidance than to add a code snippet.

Example: sell a plugin and provide an invoice after purchase

Consider a typical store run by a WordPress developer. It sells a plugin ZIP file at a single price. After paying, the customer gets a download link and wants to send the invoice to their company’s accounting department. The goal is to let the customer download the document on their own and let the administrator see the same document on the order.

Set the goal and prepare the store

Create a test digital product with a clear name, a price, and a test file. Make sure checkout works, the purchase email is sent, and test records appear under Downloads > Orders. Create an "Invoice" page containing [edd_invoices] and assign it in Invoice Page. Enter the company name, address, and only verified required details.

Steps for the administrator

1. Enable test mode under Downloads > Settings > Payments and save your changes.
2. If you use Stripe, enable its test mode separately. EDD’s documentation notes that EDD’s test mode and Stripe’s test mode are independent.
3. Open the store in a private browser window, add the test product to the cart, and complete checkout with test details.
4. After confirmation, wait for the email, open its invoice link, and confirm that it leads to the assigned page.
5. On the invoice page, check the company name, address, products, total, logo, and expected behavior of the Update button.
6. Click Download PDF, then open the file in a separate viewer rather than relying only on the browser’s built-in viewer.
7. Return to Downloads > Orders, find the test record, and open the invoice from the admin view.

What a successful check looks like

Success means the pieces match up, not simply that a button appears. The email opens the invoice for that specific order. The line items and total are correct. The seller’s details are as expected. The PDF opens, the logo is present, non-Latin characters are intact, and the back link does not lead to someone else’s order. The administrator can find the same document. Only then should you turn off test mode and begin processing live orders.

Test the entire flow. Opening the settings and seeing a saved checkbox is not enough. Check the full path: "order - email - invoice page - PDF - order record." That is how you confirm that customers will actually receive the right document.

Check the feature after changes and before launch

A digital store can process payments and deliver files while still failing to provide an invoice. Check invoice delivery separately. EDD’s official store testing guide recommends enabling test mode, placing an order, confirming that the customer receives an email and a valid download link, and checking that the order appears under Downloads > Orders as a test. For invoices, add the document page, print view, PDF download, and admin view to that checklist.

Acceptance checklist

• Order: The test record has the expected status, line items, and total.
• Email: The invoice link arrived at the test address and does not appear as a raw template tag.
• Page: The invoice opens from the email or purchase history, not only when you view the page manually.
• Document: The seller’s name, address, tax details, and additional text match the approved information.
• PDF: The file downloads and opens with readable text, logo, and totals.
• Customer access: The address-editing setting provides or restricts access as expected.
• Admin access: The document is available for the same test record under Downloads > Orders.
• Free order: If relevant, the zero-total rule has been checked separately.

Test again after updates

After updating WordPress, EDD, the theme, payment gateway, caching system, or email delivery setup, run at least a brief test. You do not need to redesign the document each time. Place a controlled test order and check the critical steps. This is especially important if the store still uses the old PDF Invoices extension: the official documentation says updates have stopped, so continued compatibility is not guaranteed.

Keep a brief team log with the check date, who performed it, which use case was tested, a link to the test order, and what was checked. Do not include customers’ full personal details. The log makes future troubleshooting a comparison with a known working setup instead of guesswork.

Maintain legacy PDF Invoices and plan the transition

The reason to transition is not that the old document suddenly stops existing. The developer has incorporated its features into the current Invoices feature and says that legacy PDF Invoices no longer receives updates or support. For an existing site, the goal is to move toward the current feature without disrupting order history.

Take inventory before changing anything

Gather the facts: where the old feature is enabled, which settings path it uses, which tag appears in the email, what the purchase history page is called, which business detail fields are filled in, whether there are custom changes, and who receives the documents. Also note whether you use special numbering, additional checkout fields, or a non-English PDF. The old documentation already warns that custom checkout fields are not added to the template by default. That detail may matter during migration.

A safe transition plan

1. Create a staging copy or a maintenance window where you can reproduce an order without affecting customers.
2. Record the existing settings and create a test PDF with the old option as a reference.
3. Confirm that the current Invoices feature is available with your installed version of EDD Pro.
4. Create a new Invoice Page with [edd_invoices], but do not switch the live email to it until you have tested it.
5. Enter the business details manually, checking each field against an approved source rather than assuming similarly named fields match.
6. Place a test order and check the email with {edd_invoice}, purchase history, PDF, and admin access.
7. Agree on the change with support and accounting, then switch the live workflow during a planned maintenance window.

Do not promise that the new PDF will look identical to the old one. Changing the feature and template can change the layout. A successful migration means the right customer can access the document, it contains accurate details, and an administrator can reliably verify it. If a business-critical custom element is not supported by the documentation, treat it as a separate development task rather than inserting arbitrary code into the extension files.

A short video about the EDD setup flow

Easy Digital Downloads’ official video about the initial setup wizard provides useful context for the sections on business details, payments, email, and store testing. It does not replace this invoice guide, but it can help you verify the basic EDD setup before configuring documents.

Move from legacy PDF Invoices to current Invoices without losing control

EDD PDF Invoices has one limitation that affects the migration plan more than the choice of invoice color: official materials mark it as legacy, and Easy Digital Downloads recommends Invoices for new installations. So a migration is not just a matter of replacing one menu label with another. An existing setup may already have an email, a purchase history link, a familiar admin view, and customer requirements for business details. The goal is to preserve a clear path for customers and make the document verifiable, not simply to get a new PDF.

The right time to migrate is not only after something breaks. It may make sense when launching a store, when the old settings screen has become a source of uncertainty, when you need to follow current EDD documentation, or when the team wants a consistent workflow for the invoice page and emails. That does not mean an existing store must change its workflow as soon as an update is installed. If the old document still does the job, first map out the current flow and prepare a safe test on a staging copy.

Document the customer journey, not just the settings screen

Start with one paid test order and follow the steps as a customer would. Record when the document appears: in the email, purchase history, on a dedicated page, or in the order record for the administrator. Also note who can open the link: a guest with an email address, a logged-in user, or a store employee. This gives you behavior to compare instead of relying on memories of what the old PDF looked like.

A small table in a working note is enough: event, expected action, data source, and how to verify it. For example, the event order paid should lead to an email with a valid link; the action customer opens the document should show that customer’s order; the action administrator checks the order should make it possible to compare the total, line items, taxes, and business details. Do not include assumptions such as "the invoice is always available to everyone." Instead, note which test will confirm access.

Pay particular attention to the fields users consider part of an invoice: store name, mailing address, tax registration number, logo, customer details, currency, discount, tax, and total. EDD builds the document from order information and store settings, so changing a single setting will not necessarily fix older purchases. Compare the new workflow using a new test order, not just a saved PDF from the past. That makes it easier to distinguish a template change from differences in the order data itself.

Create a dedicated page and define who owns each part of the flow

For the current Invoices feature, the official documentation uses a page containing the [edd_invoices] shortcode. This is not a static storefront page; it is where customers open a document in the context of a specific order. Create it on a staging copy, give it a clear permalink, and do not judge the result by opening the page in the editor without following a link from an order. Without that context, the system cannot know which purchase the invoice should show.

Next, assign an owner to each part of the flow. WordPress handles the published page and permalinks. Easy Digital Downloads stores order data and manages the customer flow. The Invoices settings determine what appears on the document. The email service delivers the message but does not create the invoice. A caching plugin may affect which version of a dynamic page visitors see. Keeping these roles clear helps prevent a common mistake: changing the document template when the real problem is an undelivered email or a cached page.

If the site has legally required business details, do not copy them from an old document without checking. Verify them against the store’s approved information and with an accountant or attorney familiar with your jurisdiction. The plugin helps present order data in a clear document, but it does not determine which fields your business is required to include. Never test real customer information in a publicly accessible staging environment. Use safe test names and addresses if the staging site is accessible from the internet.

Check the email tags before switching to the new workflow

The purchase email is the most sensitive part of a migration. The EDD documentation specifies {edd_invoice} for the current Invoices feature; legacy PDF Invoices used {invoice}. The tags serve similar purposes, but you should not treat them as interchangeable without checking which feature is active. Open the email template on a staging copy, find the old tag, and note its current position: next to the order total, after the file list, or in a separate help section.

Then choose one clear line of copy, such as a brief note that the invoice is available through the link in the email. Do not put competing links to the old and new documents side by side unless you are running a strictly limited parallel test. Customers do not need to know the migration history; they need one working path. After replacing the tag, save your settings and place a new test order that sends an email to a separate test inbox. A template preview is useful, but it does not prove that a link will be generated in a delivered message.

Check the email as a customer would: Is the link text visible? Does it remain easy to find on a mobile screen? Does the address open the right order? Is the path clear if the customer has signed out? Then check the same order as an administrator in EDD. If the link is missing, do not add a URL manually to the template. First confirm that the feature matching the tag is enabled and that the test order reached the state required to create a customer invoice.

Run the side-by-side test on a staging copy only

A safe migration is a short acceptance test, not an instant switch on the live store. On a staging copy, create at least three new orders: a regular paid order, a discounted order, and a zero-total order if your catalog supports that use case. For each order, check payment, product line, total, email, invoice link, PDF download, and printing. If Disable Invoices for Free Purchases is enabled, test the zero-total order explicitly rather than leaving it as an accidental exception.

It is useful to test failure cases as well as the expected flow. Open the link in a clean browser window, try the guest path using the expected email address, and test the logged-in customer path. If the staging site uses caching, temporarily configure exclusions for checkout, confirmation, purchase history, and invoice pages according to the caching solution’s documentation. Then clear only the cache relevant to the test and repeat the flow. Do not clear everything or disable all plugins on the live site just to test one PDF.

Compare the outcome against a few checks: the document belongs to the right order; the customer gets only the access path they are entitled to; the total and line items match the order; the business details are readable; the PDF opens after download; and the email does not contain an outdated tag. If any answer is no, leave the live store on the old workflow and record the specific symptom. "Invoices are broken" is not useful. "The guest order email shows the tag as text and does not generate a link" tells you what to investigate next.

Move changes over in small, reversible steps

Once the test workflow is stable, break the live migration into short stages. First, save a copy of the current email text and a list of the settings. Then publish the prepared page, enter the verified business details, and activate the new workflow during a scheduled maintenance window. Place a fresh internal test order right afterward. Do not use old documents as your only benchmark: they were generated from earlier data and may reflect a previous configuration.

Schedule a short monitoring period after launch. The person responsible for the store should know where to open an order, where to find the invoice link, and what information to request if a customer reports a problem. The order number, email address used, and description of the step where the issue occurred should be enough. Do not ask customers to send extra payment details or post order information in a public ticket.

The rollback plan should be specific. If a test order does not generate a working document after you enable the new flow, restore the saved email template and the last confirmed extension state, record the time and symptom, then continue investigating on a staging copy. Do not delete pages, orders, or PDFs to "clean up" the problem. That removes evidence you need for comparison. Reversibility matters more than speed: one verified customer path is more valuable than several untested switches.

When it makes sense to keep the legacy setup temporarily

It can make sense to keep EDD PDF Invoices temporarily if the store depends on a nonstandard but confirmed working flow that requires development to reproduce, or if the migration affects required business processes during a busy sales period. This is not an argument against updating indefinitely. It is a reason to gather the requirements first: which business details are required, which emails change, how guests are handled, who approves the document, and which order will be used to verify it.

If you need a field that is not available in the documented interface, do not add arbitrary PHP to the extension files. Any customization should use a documented extension point, be tested on a copy, and have a rollback plan. If there is no confirmed extension point, ask a developer to handle the work using a description of the customer flow and acceptance tests. That turns a vague request to "make a different PDF" into a measurable task: what information goes into the document, where customers get it, and how the team will verify it.

When EDD PDF Invoices is a good fit

EDD PDF Invoices is useful when an Easy Digital Downloads store needs a clear path from a paid digital order to a customer document. For a new setup, choose the current Invoices feature, create a dedicated page with [edd_invoices], enter only verified business details, agree on whether customers can edit their address, and test the full flow from the purchase email to the downloaded PDF.

If the store already uses the old PDF Invoices extension, do not make a risky decision based on one settings screen. First document the current flow, check the logo, emails, and any special requirements, then recreate the workflow in a test environment. Once it passes consistently, you can download the latest version of EDD PDF Invoices and apply this guide to your store’s specific setup.