GetPaid PDF Invoices - WordPress Plugin

A Practical Guide to Setting Up GetPaid PDF Invoices

This guide to GetPaid PDF Invoices will help you understand how to link a PDF copy to an invoice, configure document delivery for the right emails, give customers a secure way to download it, and test the full flow with a sample invoice. This second point matters specifically for this extension: it works on top of an existing GetPaid setup and turns an invoice created in the system into an attached PDF document and, if needed, a download button available to the customer.

The product page may simply promise to "send PDF invoices," but that is not enough on a working site. Before enabling it, the site owner needs to decide when a document should leave the site, who can see it in their account, what information appears in the header and footer, how to avoid sending an existing customer a document with test copy, and where to look when an email arrives without an attachment. None of these tasks requires turning the website into an accounting system, but each one affects how trustworthy the invoice feels.

The guide below covers the path from checking the core system to verifying a test email. It is designed for service sites, subscriptions, digital products, or order workflows where GetPaid already creates invoices and sends notifications. If your company has requirements for source-document formats, numbering, tax details, or electronic document exchange, confirm them with an accountant before launch. The extension creates a convenient PDF copy of invoice data, but it does not replace the accounting rules that apply in your country.

What the Extension Does and When It Makes Sense

GetPaid PDF Invoices does not create a standalone product catalog, assign tax rates, or process payments in place of the GetPaid core. Its role is narrower: it takes an invoice already created in the billing system, prepares a PDF version, and makes that file available through two straightforward channels. The first is an email that GetPaid sends to the customer. The second is the customer’s invoice history and the individual invoice page, if you enable the download button.

This separation is useful when a customer needs the document after the initial notification has arrived. For example, a studio may bill clients monthly for support work: a manager sees the payment task in the admin dashboard, the client receives an email with an attachment, and two weeks later can reopen their history and download the same PDF for payment or internal approval. The site does not need to send the file manually, and the customer does not have to search for an old email.

Another use case is a one-time invoice for a service. The provider creates a customer in GetPaid, adds an item with a description of the work and an amount, saves the invoice, and sends a notification. The recipient sees a normal email, while the PDF makes it easier to forward the document to accounting without copying information from the browser. The main value here is not flashy design. It is the fact that the same version of the invoice arrives through a clear, verifiable path.

Who Can Save Time With This Extension

It is primarily suited to WordPress site owners who already use GetPaid for invoicing and want to eliminate the manual step of turning a page into a file. That may include consultants, agencies, instructors, small recurring-service businesses, event organizers, and teams that collect payment against issued invoices. The key point is that they all share the same model: the invoice is created in GetPaid, not in WooCommerce or an external CRM.

It can also help site editors responsible for the customer-facing experience. Instead of telling someone to "open the email and print the page," they can provide one clear action: find the invoice in account history and download the PDF. When configured carefully, this can reduce requests such as "please send the document again." However, the button alone does not prove that a visitor is authorized to see the document. Checking history pages and access behavior remains the administrator’s responsibility.

When Not to Expect More Than It Provides

GetPaid PDF Invoices is not the right choice if the original requirement is a complete WooCommerce order-document workflow with invoices, packing slips, labels, warehouse printing, bulk order documents, or specialized electronic document formats. Those use cases belong to a different class of solutions because the document is tied to a WooCommerce order, not a GetPaid invoice entity. You should also not expect a complex branded-layout builder: the officially confirmed settings cover email selection, the download button, and header and footer text, rather than a full template editor.

If an invoice must include details that are not collected in the main GetPaid workflow, address that at the source: determine how line items, customer details, addresses, and taxes are created. The PDF reflects data that already exists. Trying to compensate for incomplete source data with footer text makes the document less clear and does not resolve the underlying issue.

Workflow Map: From Invoice to Customer File

Before installation, it helps to see the mechanism as a whole. An administrator or integration creates an invoice in GetPaid. The invoice has a recipient, line items, an amount, a status, and a sending history. Email settings in the core system determine which notifications exist. PDF Invoices adds a selection layer on top: you choose which available emails should include a PDF copy. When a selected email is triggered, the extension creates an attachment from invoice data and passes it to the WordPress mail system.

A second path can work in parallel. On the invoice history page, users see their own records, and on an individual invoice page they see the corresponding download button. This is not a separate file that an editor manually placed in the Media Library. In practical terms, it is customer access to a PDF version of the invoice. That is why you should first verify the history page itself, the user, and the page assignment before worrying about the appearance of the button.

This diagram is not just a formality. When an email does not contain a file, there is no need to immediately change fonts or reinstall the extension. First determine whether the invoice was created, whether the specific notification selected in the settings was sent, and whether the email itself arrived. A step-by-step check saves time and prevents mail-delivery issues from being confused with PDF issues.

Practical rule: change only one part of the workflow at a time. First confirm that a basic email is delivered, then add the PDF attachment, then enable downloads in invoice history. That way, every outcome has a clear cause.

What to Prepare Before Enabling PDF Documents

This extension has a clear dependency chain: WordPress, the core GetPaid plugin, and your GetPaid PDF Invoices add-on must already be installed and active. Seeing a PDF settings item in the admin dashboard after activation is a useful sign, but it does not replace checking that the core system works. If GetPaid cannot yet create an invoice or send a normal notification, the PDF extension cannot fix that underlying issue.

Before enabling the feature, prepare one safe test email address that you can access. It is better to use a separate team address than a real customer’s details. Create a test user or select an existing internal account so you can later check both the email and the account history. Do not enter a random address: delivery cannot be properly confirmed if you cannot open the mailbox and inspect the attachment.

The next preparation layer is the data used to build the invoice. Open an existing example in GetPaid and review the customer name, address fields, line items, quantities, prices, discounts, and taxes if they apply to your workflow. The PDF should reflect the meaning of the invoice, so a test with incomplete data does not tell you whether the site is ready. Pay particular attention to the company name, contact information, and business details: the header and footer can add context, but they should not replace the seller’s actual information.

Check the Core Invoice History First

A download button is useful only when the user already reaches the correct history page. GetPaid settings include a history-page assignment, and the page itself uses the invoice-history mechanism. Older documentation refers to the [wpinv_history] shortcode; newer installations may offer a block or widget. The principle is the same: before launch, open the page while signed in as the test customer and make sure it displays that customer’s records only.

Do not place the history view exclusively in a narrow sidebar. GetPaid documentation specifically warns that sidebars and footers may cause responsive-layout issues. For a customer area, a dedicated page with a normal content width, a clear title, and a standard account-menu item is usually more reliable. Then sign in as the user and confirm that the link leads to the expected page, rather than to a placeholder template or a list of someone else’s documents.

Test Email Delivery Before Working With Attachments

First send a standard GetPaid test notification without relying on a PDF. Confirm that the email arrives, that the sender name and subject are recognizable, and that the recipient address matches the invoice. If the email does not arrive, the cause may be WordPress mail delivery, server configuration, or the selected email event. You cannot draw conclusions about the PDF attachment until the delivery channel itself has been verified.

For this stage, it is useful to keep a short checklist. It does not need to become bureaucracy: simply record the test invoice number, the selected email type, the recipient address, and the sending time. If you later need to repeat the check after changing footer text or updating the site, you will not have to rely on memory. Remove all test wording from the header and footer before moving on to real customers.

Installing the Extension and Reaching the First Checkpoint

Once preparation is complete, install the extension using the standard WordPress method: open Plugins in the admin dashboard, choose Add New Plugin, then Upload Plugin, select the ZIP archive you received, and complete installation. This approach does not require manually extracting the archive on the server. When WordPress displays the Activate Plugin button, activate the extension only after confirming that the GetPaid core is already enabled.

If another administrator added the product to the site, do not replace the current archive with a random copy from Downloads. In a live project, the origin of the file and compatibility with the installed core plugin matter. Create a site backup, or at least a hosting restore point, before updating the related payment functionality. This is a normal safety measure: it gives you a way back to a known state if an update causes a conflict. It does not mean that the extension is unsafe.

1. Open the plugin list and confirm that GetPaid is active.
2. Upload the GetPaid PDF Invoices ZIP archive through the standard WordPress screen.
3. Click Activate Plugin and wait for the usual successful-activation notice.
4. Go to GetPaid settings and locate the PDF Invoices tab or section.
5. Without changing other settings, save this starting point and return to the test invoice.

The product documentation confirms that GetPaid > Settings > PDF Invoices appears after activation. If the section does not appear, do not try to add settings directly to the database or edit extension files. First refresh the screen, check the active plugin list, verify your account permissions, and look for an activation error. Then make sure the GetPaid core has not been disabled on the site. In most cases, the cause is a dependency or permission issue, not the contents of the future PDF.

Why the First Launch Is Better on a Copy or During a Quiet Period

The plugin can be installed on a live site, but it is still best to test the workflow at a time when you are not expecting a large batch of invoices to be sent. If real documents are being created at the same time, it is difficult to separate a test email from customer notifications, and it is easy to forget to remove temporary wording. For a site that invoices regularly, it is more practical to create one test invoice in advance, approve the PDF content, and only then enable attachments for the selected emails.

At this stage, there is no need to hunt for hidden switches or add code. The official workflow is intentionally short: the extension adds its own tab, where you choose email attachments, a download button, and two text fields. The takeaway is simple: if the tab appears, a core invoice exists, customer history opens, and a normal email is delivered, the environment is ready for detailed configuration.

Configuring GetPaid PDF Invoices: Emails, Downloads, and Document Text

Now open GetPaid > Settings > PDF Invoices. The extension has only a few settings, so a strong configuration is not about enabling as many checkboxes as possible. It depends on the purpose of each decision. First decide which emails should actually include the document. Then decide whether customers should be able to download it again. Finally, add text that helps explain the purpose of the file without overloading it with legal or internal details.

Do not select every option "just in case." If an invoice passes through multiple statuses or generates reminders, several identical attachments can confuse the recipient. Start with one notification that serves as the main invoice message in your workflow. After a successful test, you can deliberately add other emails if they are genuinely needed for customer communication.

Choosing Emails for the PDF Attachment

The Attach PDF Invoice To Emails setting lets you choose which emails should include the PDF. Official documentation notes that the list corresponds to emails configured in the GetPaid email section. Do not treat this setting as a separate mailing tool. It does not create a new reason to send an email; it adds a file to an existing notification.

For a typical service invoice, it makes sense to select the message received by the customer when the invoice is created or sent. On a test record, verify not only that the attachment is present but also that the context is right: the email should clearly identify itself as an invoice, not a reminder, administrator notification, or internal log entry. Do not attach documents to internal team emails unless there is a real need. The fewer copies of a financial document that exist in unrelated inboxes, the easier the workflow is to control.

If your setup includes reminders, decide in advance whether the reminder should repeat the PDF attachment. This can be convenient for a customer who lost the first email. For a project with frequent touchpoints, it may create unnecessary duplicate copies. The decision depends on the workflow, not on a technical limitation. Run two tests with different emails and compare what the recipient sees. Then keep only the option that matches your communication policy.

What Counts as a Successful Attachment Test

Success is not just seeing a file icon in the email. Open the attachment on a regular computer and check three things: the PDF opens without an error, the customer name and line items belong to the test invoice, and the text is not cut off or replaced with unexpected characters. Then minimize the email and return to the invoice record in GetPaid. If the PDF data differs from the original record, do not continue sending invoices: first verify which test invoice was opened and whether an older notification is being used.

The Download Button in History and on the Invoice Page

The Display Download Button setting adds a way to download the PDF in the customer’s invoice history and on the individual invoice page. This is more convenient than asking customers to keep an email for years, but it requires careful access testing. After enabling it, sign in as the test user, open invoice history, find the required invoice, click the button, and confirm that the downloaded file belongs to that user. Then sign out or switch to another test user: another customer’s invoice must not become available simply because its link is known.

The content and placement of the button are determined by the theme and by how invoice history is displayed on the site. Do not fix the first styling conflict by editing plugin files. First check the block width on a phone, the presence of long labels, and the theme’s own styles. If the page contains several similar buttons, add clear plain-language text nearby in the account interface instead of misleading users with the label. This product guide does not promise a specific button appearance because it depends on the site theme.

An important practical choice: an email attachment and a history button solve different problems. The attachment is useful for the first contact and for forwarding the document. History is for repeat access and self-service downloads. On a mature site, it often makes sense to enable both paths, but test each one under a customer account first.

Headers and Footers Without Damaging the Invoice

The Header Message and Footer Message fields are intended for text at the top and bottom of the PDF invoice. Documentation allows basic HTML tags, but that is not an invitation to paste in a large block of markup. It is safer to write one or two short sentences: for example, explain the document’s purpose, tell customers how to get in touch about the invoice, or add a neutral note about company details. Long copy, complex lists, and decorative blocks increase the risk of poor page wrapping and make the PDF harder to read.

For testing, first leave the header empty and add one sentence to the footer. Create a new test invoice, open the file, and check that the message does not overlap the totals. Then add a short header only if it genuinely helps. If the text includes links, a phone number, or an address, confirm that they are correct and do not point to a temporary resource. Do not use footer text to disclose payment details that should exist only in the main invoice record or approved business details.

Why Font Sub-setting Exists and When to Enable It

The Enable Font Sub-setting option is designed to reduce PDF size when using fonts with Unicode support. According to the developer’s description, the mechanism includes only the characters actually used in the document and is especially useful when required characters are not supported by base fonts. This relates to file size and character coverage, not header styling.

For non-Latin text, testing is more important than assumptions. First generate a PDF containing non-Latin characters in the customer name, line-item description, and footer message. If the file opens correctly and looks normal, compare the practical value of reducing file size with your own workflow. A smaller file can be useful when you send many emails. If enabling the setting produces missing characters or unexpected formatting, turn the setting off, save your changes, and repeat the same test. The rollback is straightforward: return the setting to its previous state, while the test invoice remains your control record.

Do not judge language support from a single invoice containing only Latin characters. For final verification, use the kinds of characters your customers actually use, but keep personal data out of the test record.

Configuration summary: choose one verified email type, enable the customer download path only after access testing, keep header and footer copy brief and approved, and test the font setting with the required character set. That foundation is enough to move on to how the PDF relates to the source invoice and customer history.

What Data Appears in the PDF and Why the Source Invoice Comes First

GetPaid PDF Invoices does not work as an independent document editor. It is a representation of an invoice created in the core system. That means PDF quality starts not with font selection but with the invoice record: the recipient, line items, quantities, prices, discounts, taxes, status, and related notes should all be reviewed before sending. If a customer sees an incorrect name or an outdated item in the file, the issue is usually in the source data rather than in the PDF.

GetPaid documentation for creating a first invoice helps illustrate this sequence. In the invoice section, you can select an existing user and populate their saved information, or create a new user. Items are added to the invoice, and recalculation is used after changing data that affects the total. This approach is useful for PDF testing: do not test the file with a nearly empty draft. Instead, build a record that resembles a real document while using safe sample data.

A Minimum Set for a Control Invoice

Create one test invoice with a clear service name, two different line items, quantities, a total, and a test customer. If your actual workflow uses discounts or taxes, add them only when you understand why they should appear in the document. There is no need to model the entire business in one test. The goal is to create an invoice detailed enough to check line wrapping, totals, business details, and fonts.

After changing a country or another setting that affects calculations, do not rely on an old total. Core GetPaid documentation mentions the Recalculate Totals button for recalculating after changes, including cases where the user’s country matters to the calculation. Before resending a notification, save the invoice, open it again, and compare the total with what you expect to see in the PDF. This step is especially important for services with different rates and for invoices edited after their initial creation.

Customer Notes Versus Internal History

The GetPaid invoice record distinguishes between a customer note and a private note. The first may become part of communication with the recipient, while the second is intended for the team. Do not use a test email as proof that a private note is hidden in the PDF: inspect the generated file itself, and do not put anything in internal notes that would be unsafe to show the customer. The practical principle is simple: internal history helps the team reconstruct what happened, while the customer document should contain only approved information.

If a manager changes data after sending, agree on a repeat-verification rule. In some workflows, creating a new invoice is enough; in others, an updated notification must be resent. This organizational decision depends on the company’s accounting process, but the technical control is always the same: open the final invoice in GetPaid, generate a new test PDF, and compare the key lines. Do not promise customers that a file they downloaded earlier will update automatically without verification.

Invoice Status and Customer Expectations

An invoice has a status in the admin dashboard. A new document is normally marked as awaiting payment, although the exact workflow depends on selected payment methods and internal rules. The PDF attachment does not override that behavior and is not confirmation that money has been received. Do not describe an invoice as paid in email copy or footer text while the main record is still awaiting payment. Otherwise, the customer receives conflicting signals: one view says payment is pending, while the attached file sounds like a receipt.

For a successful test, it helps to create two control situations: a new invoice still awaiting customer action and a record that has already moved through your normal process. There is no need to artificially alter financial data. It is enough to see how the relevant record appears in history and how the PDF relates to it. This helps site editors explain the difference between invoice history and payment confirmation.

Invoice History Access: Customer Convenience and Boundary Checks

The extension provides a download button in history and on the invoice page, but access to those places is based on core GetPaid settings and the site’s sign-in model. Core documentation describes the history page as the place where the current user sees their own invoices. Your control test should therefore work in both directions: make sure the owner of the test invoice can see it and another user cannot get the same result.

Do not confuse convenience with open access. On sites where an invoice contains contact or payment information, you cannot publish a history link in a general guest menu without testing it. Review GetPaid sign-in and payment settings, the site policy, and actual behavior in a separate browser window. If your workflow requires customers to sign in, verify that rule before enabling the download button. If the business deliberately uses a different access process, document it with the responsible employee and test that exact workflow.

Test Under Three Roles

The most useful check takes only a few minutes. Open history as an administrator and make sure you know which test invoice you are looking for. Then sign in as the invoice owner, find it, download the PDF, and compare it with the admin-dashboard data. After that, use a second test user or a signed-out session. The required invoice must not become "visible to everyone" because of caching, a saved session, or overly broad access permissions.

When caching is in use, do not draw conclusions from a single window where you were recently signed in as an administrator. Open a private window or a different browser because account pages often require separate cache behavior. This is not a claim that a particular caching plugin is incompatible with GetPaid. It is a safe check for a personalized page: the output should depend on the current account, not on HTML previously stored for another user.

How to Record the Outcome Without Excess Personal Data

For an internal check, it is enough to record the test invoice number, the user role, and the outcome: "can view and download," "cannot view," or "page asks the user to sign in." Do not attach real customer PDFs to broad internal correspondence. If you need to keep an example, use a sample name and address. This discipline helps diagnose settings without distributing documents more widely than necessary.

At this stage, it is especially useful to distinguish symptoms from causes. The symptom "the button exists but the file is not found" relates to PDF generation or its link. The symptom "the button is visible to the wrong user" relates to access. The symptom "history is empty for the owner" may point to page assignment, sign-in behavior, invoice creation, or the selected customer. When these cases are not mixed together, the fix becomes more predictable.

Result check: a good customer workflow works without administrator involvement: the user signs in to their account, finds the invoice, understands the button’s purpose, downloads the PDF, and sees the same key information as in the notification.

After that, you can move to a complete working example. It connects invoice creation, email selection, the PDF attachment, history, and post-send verification into one repeatable sequence rather than a set of isolated switches.

Practical Example: A Monthly Support Invoice

Imagine a small agency website that bills an ongoing customer for support and consulting. The customer already has an account on the site, and a manager creates one invoice each month with several line items. The goal is not to automate accounting in its entirety. It is to ensure that the customer receives a readable PDF with the selected notification and can later download the same document from account history.

This example is useful because it covers every part of the extension. There is input data: a customer, line items, and approved text. There is GetPaid behavior: creating and sending an invoice. There is the PDF Invoices output: an attachment and a download button. Finally, there is verification: the email, the file, and the user’s history should all contain the same clear information. If a mismatch appears at any stage, do not send the next real invoice until you identify its cause.

Goal and Test Setup

The goal is to send a test invoice called "Monthly Website Support" to a monitored address, receive it as a PDF attachment, and download the document again after signing in as the same user. Prepare a test account, access to its mailbox, active GetPaid, active PDF Invoices, a working history page, and a selected email type in Attach PDF Invoice To Emails. Put a neutral test sentence in the footer in advance, one that can later be easily replaced with approved copy.

Before beginning, decide which information you will compare. For example: the test customer name, two line items, the total amount, invoice number, footer text, and document date if it is shown by the core invoice. The purpose of this list is not to inspect every pixel. It protects you from a misleading test. Without predefined reference points, you may open a good-looking PDF and fail to notice that it was attached to the wrong email or displays an earlier invoice.

Step 1. Create a Meaningful Test Invoice

In the GetPaid invoices area, begin creating a new record. Select the test customer from the list and, if the system offers to populate saved user data, use it only after checking that it is current. Add the first item for the monthly service, then a second item, such as an additional consultation. Use sample amounts and do not enter a real customer’s personal data.

After adding the items, review the quantity, price, and total. If you changed user information or settings that affect the calculation, use the standard recalculation feature and review the total again. Add a customer note only when it is genuinely needed in the email, and use an internal note for the team. Do not turn notes into a duplicate of business details or an instruction the customer should see in the PDF if a more appropriate place already exists for it.

Step 2. Link the PDF to the Selected Notification

Before sending, reopen GetPaid > Settings > PDF Invoices and confirm that the correct email type is selected. Do not change header text, line-item order, and notification type at the same time: if the attachment arrives incorrectly, you will not know which change mattered. Save the settings, return to the test invoice, and use the standard sending action supported by your workflow.

After sending, do not rush to create a second invoice immediately. Open the invoice log or notes, if available in your installation, and record that the action was performed. Core GetPaid documentation states that notes may record invoice or reminder sending. This is a useful comparison point for the mailbox, but it does not replace actually opening the email that arrived.

Step 3. Check the Email and the PDF Itself

In the test inbox, find the required notification by subject and recipient. Confirm that the PDF is attached to this specific email. Download the attachment to disk, open it in a standard PDF viewer, and compare it with your checklist. The customer name, two line items, totals, and footer message should match the test record. Check non-Latin characters, long lines, and wrapping. If the document contains an error, save it as evidence of the test, but do not forward it to real customers.

Also check the file size as a practical symptom. A small document usually opens quickly and is easy to forward, but there is no universal "correct" size. If the file is unexpectedly large and contains text with nonstandard characters, compare the outcome with the Enable Font Sub-setting setting. Change that option separately, create a new control PDF, and verify that readability has not suffered.

Step 4. Repeat the Path From the Customer’s Perspective

Sign out of the admin dashboard and sign in as the test user. Open the invoice history page, find the record you created, and use the download button if it is enabled. Compare the new file with the attachment from the email. In a verifiable workflow, they should refer to the same invoice and should not contradict each other. Then open history as a second test user or in a private signed-out window to see the access boundary.

If the history page does not show the button, do not conclude that the PDF is not being generated. First check whether Display Download Button is enabled, whether you opened the current user’s actual history page, and whether the test invoice is present there. If the email contains the attachment but the button is missing, that is already a useful finding: file generation works, and you should look at display settings or the customer path.

Step 5. Turn the Test Into a Repeatable Procedure

Once the workflow works, create a short internal rule for the manager: check invoice data, choose the right sending action, do not change template text without a test, and open the PDF before resending if there is any uncertainty. This does not require technical expertise. What matters is that the person understands the difference between editing an invoice, configuring the attached PDF, and granting the customer download access.

Scenario summary: a working chain looks like this - an accurate invoice, a selected notification, an openable attachment, customer-accessible history, and a permissions check under another role. If one part fails, do not compensate by manually sending the file. A manual resend may help one customer, but it conceals a defect that will recur with the next invoice.

Keeping the Document Consistent Without Invented Customizations

PDF Invoices has confirmed built-in ways to present the document cleanly: a header message, a footer message, and font subsetting. That is sufficient for most sites where the document needs to be clear and consistent with the core invoice. Do not assume that a flexible field editor exists or use random code snippets from another plugin. The extension’s publicly confirmed feature set is the one described above.

If you need to change the branded presentation, start with core GetPaid data: the store name, address, logo, and workflow pages. In core settings, these details belong to the overall configuration rather than to an individual PDF. Then add brief approved header or footer text and create a control document. This order preserves one source of data and does not turn the PDF into a special exception that must be maintained separately.

No code is required for a safe improvement. One practical option is to prepare approved footer text in a separate internal document, test it on a sample invoice, and then paste it into Footer Message. If the outcome is unsuitable, restore the previous verified wording and repeat the test. This rollback is reversible, does not touch WordPress files, and does not create update conflicts.

Post-Launch Verification: More Than Checking for an Attachment

The task does not end after the first successful email. PDF Invoices affects invoice data, notification delivery, and the customer’s account path, so it is helpful to verify the outcome through several independent signs. One sign answers "was the PDF created?", another asks "did it arrive with the right email?", and a third asks "can the user obtain their document again?" If you look at only one of these, it is easy to mistake a partial setup for a finished one.

For a recurring workflow, maintain a small log of control tests. It only needs the test invoice number, user, selected email, attachment state, history-button status, and the outcome of a check under another role. Do not store complete PDFs or real customer addresses in this log. Brief notes make it possible to compare outcomes after updating WordPress, GetPaid, the theme, or mail settings.

Four Levels of Verifiable Output

The first level is the source invoice. Open it in the admin dashboard and confirm that it has the correct customer, service lines, and total. The second is the email notification. Find the email at the control address, confirm that it includes an attachment, and open it. The third is the document. Check readability, header and footer text, characters, wrapping, and consistency with the control invoice. The fourth is user history. Sign in as the owner, download the file, and then repeat the check without that account.

These levels are convenient to follow in the same order after small changes. For example, you changed the footer text. There is no need to guess whether it will apply to future documents: create a new test invoice, send the selected notification, open the attachment, and download the document from history. An old file is not reliable evidence for a new setting, so use a new test record for verification.

Comparing Data and Readability

When comparing the PDF with the invoice record, do not turn the task into a visual-design review. Compare what actually affects the customer: the recipient, line items, quantities, amounts, total, and approved messages. Then assess readability: make sure no line is cut off, no characters are missing, and no long phrase has become an unreadable block. A small screen is convenient for checking whether the file opens, but the final decision on a document is better made after viewing it in a standard PDF reader.

If the site uses multiple languages or customers often provide names with national characters, create two test data sets rather than one. Use typical non-Latin characters in the first, and use characters and longer strings typical for your audience in the second. This does not guarantee support for every possible language, but it identifies character-set problems faster than a test using a short name made only of Latin letters.

What to Check After Updates

Updates to WordPress, the GetPaid core, the PDF Invoices extension, the theme, or the mail layer can affect display and delivery. You cannot claim that every update will necessarily cause a problem, but a short regression check after noticeable changes is sensible for a financial workflow. Create a test invoice, send it to the control inbox, and repeat the same four levels. This takes less time than handling a customer request after the first live document fails.

Before an update, record a clear baseline: which emails are selected, whether the download button is enabled, what text appears in the header and footer, and whether font subsetting is enabled. You do not need to export technical settings if your workflow does not require it. An internal list of approved values is enough. After the update, compare it with the interface rather than relying on an editor to remember every small checkbox.

Email, Attachments, and Sender Reputation

A PDF attached to an email passes through the same delivery mechanism as the rest of the site’s notifications. A good extension configuration therefore does not replace proper WordPress mail setup. If regular messages go to spam, are delayed, or never arrive, fix the sending channel first with your hosting provider or the person responsible for email. Reactivating PDF Invoices rarely changes the outcome in that situation.

When testing, review the email subject, sender name, sender address, and presence of the attachment. If the customer has a strict email policy, agree in advance which message will serve as the main one. Do not send several identical test invoices to a customer’s work address just to "test delivery." Use a monitored team inbox, and send customers only the workflow you have already verified.

Attachments increase email size. For a typical invoice, this should not be an issue on its own, but a very large PDF is inconvenient to forward and may run into mail-server limits. This is where testing Enable Font Sub-setting with the actual document language is appropriate. Do not remove important data to make the file smaller, and do not make arbitrary font changes that are not available in the product settings.

Caching and Customer Pages

Invoice history and an individual document page are personalized parts of the site. When a user reports seeing an outdated or another person’s output, first reproduce the situation in a private window and under different accounts. If incorrect HTML repeats, add the history page to the list of pages that need review in your caching solution’s settings. Treat this as a careful site configuration step, not as a claim of formal incompatibility with every caching plugin.

Your post-cache-clear test should be specific. Sign in as the owner of the test invoice, open history, download the document, sign out, and repeat the path without authentication. If one change resolves the issue, do not immediately make several more "optimizations." Record the working outcome. If it does not, restore the last questionable setting and move on to diagnosing sign-in behavior, page assignment, or invoice data.

A Working Discipline for Teams That Invoice Regularly

For a solo site owner, the setup may be a one-time task. For a team, a brief procedure is useful so the document does not depend on one manager’s memory. It can include three parts: who checks data before sending, who may change global PDF settings, and where test outcomes are recorded after updates. This does not add needless bureaucracy. It protects a recurring operation from an unnoticed accidental change.

For example, the manager can be responsible for the contents of a specific invoice: the customer, line items, amounts, and correct sending action. The site administrator can be responsible for the email list, download button, and approved header and footer text. If a customer says they did not receive the document, the team should not start by changing every setting at once. First, check a test invoice and the mailbox, then determine whether the issue involves delivery, data, the PDF, or access.

A good rule is not to use extension settings as a place for temporary messages about a specific customer. Header and footer text is shared by future documents. If you temporarily add a project name, internal phone number, or draft wording there, it may appear on the next invoice. For individual context, use the data and notes of the relevant invoice where the core GetPaid workflow supports it.

Summary: a repeatable process is more valuable than a one-time attractive PDF. It includes checking the source invoice, selected email, openable file, customer history, and a short test after significant updates.

When GetPaid PDF Invoices Is a Good Choice

This extension is justified when you already have a clear GetPaid process: a staff member creates an invoice, the customer receives a notification, and later returns to their history if needed. In that setup, the PDF does not become a separate manually managed file. It is a convenient copy of the same document. The strongest configuration is usually not the most complex one: one deliberately selected email, a download button enabled after testing, brief document text, and a control invoice for regular checks.

Before getting started, answer four questions. Is the correct invoice being created in GetPaid? Is the selected notification delivered to a control address? Does the PDF open with the required characters and amounts? Can the invoice owner download it from history while another user cannot? If each question has a verifiable answer, the extension is ready for careful use. If not, return to the specific part of the workflow rather than trying to replace system verification with manual file delivery.

Once the environment is prepared, settings are verified, and the test workflow has been completed, you can download the GetPaid PDF Invoices archive and repeat the sequence described above on a site copy or during a controlled period. Start by configuring one workflow, verify the email and customer history, and then apply the rule to recurring invoices. This approach keeps the document clear for the customer and manageable for the team.