Sprout Invoices Pro - WordPress Plugin

How to Set Up Sprout Invoices Pro for Invoices, Estimates, and Client Payments in WordPress

Sprout Invoices Pro becomes useful not when you just need to "throw together an invoice," but when the entire path from the client's request to the final payment needs to stay inside WordPress: estimate, client record, invoice, notifications, partial payments, activity history, and result verification. This guide walks through how to prepare the site, what to configure after installation, how to build a workable setup for an agency or freelancer, and where problems tend to show up most often.

This material does not replace accounting advice and does not promise that the plugin will satisfy every legal requirement in every country. Its purpose is more practical: to help you safely test the plugin on a staging site, understand the logic behind its settings, avoid mixing up similar modes, and spot in advance where you may need a payment gateway, email configuration, or a separate add-on.

Throughout the guide, I distinguish between confirmed features and cautious recommendations. Official sources confirm support for invoices, estimates, clients, notifications, payment processors, the client dashboard, recurring modes, templates, and WooCommerce add-ons. Where a source only discusses a narrow case or an older troubleshooting page, the recommendation is framed as something to verify rather than a universal promise.

What Problem the Plugin Solves and Where It Fits Best

Sprout Invoices Pro belongs to the class of WordPress plugins built for invoicing and estimates. It makes sense for sites where WordPress already serves as the operational hub: leads come in through the site, clients communicate with a manager, services are managed in the admin area, and payment needs to be tied to a specific estimate or invoice. In that setup, a separate cloud invoicing service can be redundant because client data and project history end up living in different places.

The product's strong point is the "request - estimate - invoice - payment - history" chain. Official documentation shows that the plugin can create clients, connect them to WordPress users, store invoice history, send notifications, display a client dashboard via shortcode, and configure payment processors. That makes Sprout Invoices Pro especially relevant for studios, consultants, web developers, designers, local service businesses, and B2B teams where an invoice often comes only after the scope of work has been approved.

The plugin may be overkill for a store where all sales go through a standard WooCommerce catalog and custom estimates are not needed. In that case, it is usually simpler to use invoice documents tied directly to WooCommerce orders. Sprout Invoices Pro is worth considering when you need custom invoices, private client links, partial payments, payment terms, recurring invoices, or estimates before work begins.

Another important use case is working with multiple contacts under a single client. The client documentation explains that one client record can be associated with multiple users, and notifications are sent to the linked users. For an agency, that is practical: the accountant, business owner, and project manager can all view the invoice, while private notes remain inside the admin area.

Who Sprout Invoices Pro Is a Good Fit For, and Who Should Choose Another Route

Before installation, it helps to honestly define the role this plugin will play in your system. If you only need a one-off PDF invoice every few months, most of its capabilities will go unused. But if you work with clients on a recurring basis, handle deposits, milestones, repeat services, and manual approvals, Sprout Invoices Pro makes much more sense.

Good-Fit Scenarios

The plugin is especially appropriate if you:

• Issue custom invoices for services, projects, support, or ongoing maintenance.
• Send an estimate first and then turn the approved scope into an invoice.
• Want to accept payments through the site without building a full online store.
• Use a client dashboard so clients can view their invoice, estimate, and payment history.
• Work with deposits, partial payments, or a payment schedule.
• Want to tie a WooCommerce order to a "pay later" flow or use WooCommerce checkout to pay an invoice.

When the Product May Not Be the Right Choice

There are also cases where it makes more sense to start with a different solution. If you maintain full accounting in a separate system, Sprout Invoices Pro should not become your only source of financial truth without reconciliation against your accounting software. If the business depends on complex tax requirements, electronic document workflows, or mandatory invoice formats, check the available add-ons and local compliance requirements first.

It is also worth paying attention to the state of support. On WordPress.org, you can see recent reviews that include both positive ratings and complaints about support and payment issues. That does not prove the plugin will fail on your site, but it does mean any important payment workflow needs a full test run before involving real clients: create a client, create an invoice, run a test payment, send a notification, generate a PDF, and check client access.

What to Check Before Installing It on a Live Site

Because the plugin touches money, email, client data, and public invoice links, you should not install it with an "activate it and send it right away" mindset. Your preparation needs to cover four areas: backups, a test environment, email delivery, and payment terms.

Technical Preparation

Start by installing the plugin on a site copy or a staging environment. On the live site, create a full backup of the files and database beforehand. Then make sure WordPress permalinks are enabled, the site runs over HTTPS, email is handled through a reliable SMTP plugin or mail service, and user roles do not conflict with other membership or client-portal plugins.

HTTPS matters especially on payment pages. The payment settings documentation explicitly recommends SSL if the site handles credit card information. Even if you use an offsite processor that sends the client to an external payment page, you still need a secure connection for logging into WordPress, accessing client links, and building trust in the invoice page.

Decisions to Make Before Installation

Before sending your first invoice, answer these questions:

• Will invoices be paid online, or will you record offline payments manually?
• Do you need estimates before invoices, or is it enough to issue an invoice right away?
• Will the client have a login and password, or will you send private links?
• Do you need deposits, partial payments, payment terms, or recurring modes?
• What notifications should the client receive, and who inside the company should get copies?
• Do you need a WooCommerce workflow: pay later, checkout-based payment, or importing products into an invoice?

Quick pre-launch check: if you cannot describe the client journey from initial request to paid invoice in 5-7 steps, sketch it out on paper first. Otherwise, the plugin settings will feel like a pile of unrelated tabs.

Installation and the First Check Inside the WordPress Admin

WordPress.org describes the basic installation in the usual way: upload the plugin folder to /wp-content/plugins/ and activate it through the Plugins menu. For the Pro build, a ZIP archive is typically used, so in practice the path is Plugins -> Add New -> Upload Plugin, then choose the archive, install it, and activate it. Do not include purchase steps, purchase-code entry, or license workarounds in team instructions: that is not part of the user workflow for invoicing.

After activation, the documentation sends the user to the Sprout Invoices start page. From there, the first real working step is to open General Settings. At this point, you do not need to create a real invoice yet. First verify that the admin area shows no errors, the plugin menu appears, the pages open correctly, and the notifications and payment settings are accessible.

Initial Post-Activation Check

1. Open the plugin's start page and make sure the Sprout Invoices menu is visible in the admin area.
2. Go to General Settings and review the sections for estimates, invoices, notifications, company information, and currency.
3. Create a test client using neutral details and a separate test email address.
4. Create a draft invoice, but do not send it to a real client.
5. Open the public invoice link in incognito mode to see exactly what the recipient will see.
6. Send yourself a copy of the notification, as recommended in the invoice editing documentation.

This short test immediately exposes the most frustrating problems: admin script conflicts, broken email delivery, the wrong invoice status, payment button errors, or incorrect currency formatting.

Core Setup After Installation: Company Info, Currency, Notifications, and Statuses

The settings phase should come before any real invoices. Sprout Invoices Pro uses default values for invoices and estimates, but many fields can be overridden in a specific document. The practical logic is this: first set safe global defaults, then change only what belongs to a particular client or project inside an individual invoice.

Company Information and Currency Formatting

In the company information section, fill in the business name, address, and contact details that should appear on invoices and estimates. This is not just cosmetic: clients use this information for verification, bookkeeping, and payment. If some fields are left blank, the invoice can look unprofessional or require a separate clarification email.

Currency deserves a separate check. The documentation notes that if the server has issues with localeconv(), it may return incorrect values, which is why manual formatting options exist in the settings. This matters especially on non-US sites: check the currency symbol, thousands separator, decimal separator, and symbol placement. After saving, create a test invoice for a small amount and confirm that the public page displays the amount the way your client expects to see it.

Default Terms and Notes

Default Terms and Default Notes apply to new invoices and estimates unless a different value is set in the individual document. Do not turn these fields into a wall of legal text. It is better to keep them focused on short operating rules: payment deadline, what counts as project kickoff, how partial payments are handled, and where to write with invoice questions. If terms differ for certain clients, change them in the specific invoice rather than breaking the global defaults for everyone.

Notifications and Email Format

The notifications section controls the sender name, sender email, email subjects, and message bodies. The documentation warns that if you enable HTML format without preparing the full HTML markup for notifications, the email can look broken. A practical sequence is to start with plain emails, verify delivery, and only then move to HTML templates or the HTML Notifications add-on.

The notification editor supports shortcodes for dynamic data. That is convenient, but it also creates room for mistakes. Before sending anything to a client, verify that the email contains the invoice or dashboard link, does not expose internal notes, and does not still use an old sender address. If you edit a notification, send a test copy to yourself and open it in both desktop and mobile email clients.

Invoice Statuses as a Control Mechanism

The status documentation shows the invoice lifecycle: draft, pending, scheduled, outstanding balance, paid, written off, and archived. For the user, these are not just labels. The status determines whether the invoice is ready for viewing, waiting for payment, carrying an overdue balance, or already closed.

Do not send an invoice to a client until you understand its status. If the invoice remains in draft status, the client may not be able to view it without logging into WordPress. If the invoice is marked as paid manually before an actual payment happens, you lose a clean test of the payment flow. For testing, it is better to use a separate client, a separate invoice, and an obvious marker in the title.

Estimates, Invoices, and Line Items: How to Build a Clear Document

In Sprout Invoices Pro, invoices and estimates are structured similarly, but they solve different problems. An estimate is for approving work when the scope and total are still being discussed. An invoice is for collecting payment on an approved scope. If you mix those up, your team may start sending invoices before approval or storing final amounts inside estimates, which complicates the client history.

Invoice Structure

The invoice editing screen includes quick actions, line items, an information block, the client, terms, notes, and history. Each line item contains a description, rate, quantity, and discount. The documentation also describes sub line-items: child entries can be dragged under a parent item so a more complex project appears clearer to the client.

That is especially useful for project-based services. Instead of one vague line like "Website development," it is better to show the structure: prototype, design, front-end build, integration, testing. The client can see how the total was formed, and you can explain budget changes more easily.

Predefined Line-Items

If you sell similar services repeatedly, set up predefined line items in advance. The documentation describes creating and managing predefined line-items through a dropdown menu. This saves time and reduces the risk of typos in service descriptions or rates.

There is no need to turn predefined items into a giant catalog. In most cases, 10-20 frequently repeated services are enough: site audit, page design, form setup, technical support, consulting, one-time customization, monthly maintenance. Everything else is usually better entered manually so the invoice stays specific.

Deposit and Partial Payment

On the invoice screen, the deposit affects the amount the client needs to pay right now. The marketplace page for Partial Payments and Deposits clarifies that the related add-on lets the client choose an amount between the minimum payment and the full balance. That is useful for upfront payments and milestone-based work, but it requires clear rules in the invoice terms.

If you use deposits, make sure to verify that after the first payment the remaining balance is displayed correctly and that the due date does not create a misleading expectation. The WordPress.org changelog includes a recent fix for partial payment and deposit calculations, so this is one of the scenarios where testing on a site copy and rechecking after updates matters most.

Payments, Deposits, and Recurring Modes Without Risky Confusion

The most common logic mistake in Sprout Invoices Pro is treating all automatic modes as if they were the same thing. In reality, recurring invoice creation, recurring payment, payment terms, and Sprout Billings solve different problems. If you enable them without understanding the distinction, you can end up with the wrong schedule, an extra invoice, or an expectation of automatic billing where nothing has actually been configured.

Payment Settings: Offsite and Credit Card Processors

In the payment settings, the documentation distinguishes between two types of processors. An offsite processor sends the client into an external payment flow or records an offline method such as check or P.O. A credit card processor accepts card payments through the selected gateway, but only one card processor can be active at a time. After choosing a processor, you need to save the settings, then fill in the specific gateway parameters, and save again.

The practical test is simple: create a test invoice, open it as the client, make sure the correct payment button appears, and complete a test or sandbox payment if the payment service supports it. If a new payment method does not appear for an existing client, check the client record: the troubleshooting documentation includes a scenario where a new processor must be enabled for a client who was created earlier.

Recurring Invoices and Recurring Payments

The official documentation explicitly warns: do not use Recurring Invoices and Recurring Payments on the same invoice. Recurring Invoices create new invoices on a schedule by copying the original document. Recurring Payments create a subscription payment through the payment gateway; when the payment is completed, an invoice is created and marked as paid.

If you need to send a client a new support invoice on a regular basis, Recurring Invoices is usually the better fit. If the client should automatically pay the same amount through a supported gateway, look at Recurring Payments, but keep the limitation in mind: the documentation says subscription payments are only compatible with Stripe and PayPal. Changes or early cancellation of a recurring payment happen inside the payment gateway, not only in WordPress.

Payment Terms and Sprout Billings

Payment Terms create a payment schedule and can add a fee for late payment. The documentation also describes automation through Sprout Billings: a payment can be attempted before a due term, and if the automatic charge fails, a fee may be applied. This is a powerful mode, but it requires careful wording in the invoice terms and the client's explicit agreement to automatic charges.

For your first rollout, do not enable everything at once. Start with a manual invoice, then add a deposit, then test payment terms, and only after that move on to recurring or auto-billing features. That sequence is much easier to debug: if a payment fails, you know which layer is responsible.

Client Dashboard, Private Links, and Access to History

The Client Dashboard is one of the features that turns the plugin from a simple invoice generator into a client portal. The documentation describes an automatic page built around the shortcode [sprout_invoices_dashboard]. It displays tables for pending estimates and invoice history, and if needed you can show only estimates or only invoices through shortcode parameters.

Two Access Methods

The client can either log in as a WordPress user with the client role or open a private dashboard link. The documentation even notes that the notification for creating a new client user is disabled by default because the developer recommends the private dashboard link as the simpler access option. For a small agency, that is practical: the client receives a link and can view their documents without needing a separate explanation of how the portal works.

But a private link requires discipline. It should not be published on a public page, dropped into a shared chat, or forwarded to the wrong people. If the invoice includes sensitive commercial terms, use the login-based approach or add extra protection if your version and add-on stack support it.

How to Embed the Dashboard on the Site

1. Create a WordPress page with a clear title such as "Client Dashboard."
2. Insert the shortcode [sprout_invoices_dashboard] into the page content.
3. Test the page as a client, not as an administrator.
4. Decide whether the dashboard link should be sent automatically through notifications.
5. If you only need the invoice list, use [sprout_invoices_dashboard estimates="false"].

Result check: the test client should see only their own invoices and estimates. If a client user can see someone else's documents or admin elements, stop the rollout and review roles, associated users, and any conflicting client-portal plugins.

Templates, Invoice Appearance, and Safe Customization

Sprout Invoices Pro supports front-end template customization. That matters because the client-facing invoice is part of the public experience: it needs to be readable, branded, and stable within the site's theme. The documentation offers two levels of customization: basic appearance settings through the Customizer and deeper template overrides in a child theme.

What You Can Customize Without Code

Through the Customizer, you can change the logo, primary invoice color, header background, and similar settings for estimates. If the Customizer link is not visible, the documentation advises making sure you are viewing an invoice or estimate on the public side rather than from the dashboard. This is a common trap: the administrator edits the invoice in the backend and cannot understand why the appearance settings are not showing up.

Safe CSS Through a Child Theme

The documentation points to safe locations for CSS files inside a child theme: a global file at /wp-content/themes/[child-theme]/sa_templates/sprout-invoices.css, an invoice-only file at /wp-content/themes/[child-theme]/sa_templates/invoices.css, and an estimate-only file at /wp-content/themes/[child-theme]/sa_templates/estimates.css. Do not edit the plugin's own files: an update can wipe out your changes.

For example, if your team decides to hide the document history on the public invoice, the documentation shows that the history block can be hidden with the selector #doc_history. The safer approach is to do that only in the child theme CSS file for invoices and test it on one sample invoice first:

/* File: /wp-content/themes/your-child-theme/sa_templates/invoices.css */
#doc_history {
  display: none;
}

After adding the CSS, open a test invoice as the client and confirm that only the intended block has disappeared while the payment buttons, amount, billing details, and notifications remain visible. Rolling back is simple: remove the rule from the CSS file or temporarily rename the file. If you need deeper markup changes, use a template override in /sa_templates while preserving the folder structure from the plugin's /views directory.

Templates for Different Clients and Languages

The custom templates documentation explains that once templates are added to the theme, they can be selected from the document editing screen. That opens up several practical scenarios: a separate template for overdue invoices, a different layout for a client with special requirements, a template in another language, or a simplified document for smaller projects. Do not create too many templates at once. Start with one base template and one special-purpose template, otherwise the team will get lost when choosing them.

Practical Example: An Invoice for a Web Studio with a Deposit and Client Access

Let's walk through a specific scenario. A web studio wants to invoice a client for landing page development: part of the amount is paid as a deposit, and the remainder is due after approval. The client should receive a link, be able to view the invoice in the dashboard, and the manager should verify the email and payment status before anything goes to the real customer.

Goal

Create an invoice that includes clear work items, is tied to the client, shows the deposit due now, is sent through a notification, and opens correctly via the client link.

Preparation

Before you start, company info, currency formatting, default terms, notification sender name and email, and at least one payment processor or offline payment method should already be configured. You also need either a test client user or a test private link.

Steps

1. Create the client in the clients section or directly from the invoice edit screen through the add-client dialog.
2. Create a new invoice and give it a clear subject, for example "Landing page development."
3. Add line items: prototype, design, page build, form integration, testing.
4. If some work is grouped, use sub line-items so the parent row shows the total for that block.
5. In the information block, check the status, due date, client, invoice ID, PO Number if needed, tax, and total discount.
6. Set a deposit or minimum amount if your version and add-ons support that feature.
7. In Terms, state that the deposit starts the work and the remaining balance is due after approval.
8. Save the invoice and send yourself a copy of the notification through a test send or to a designated test recipient.
9. Open the public link in incognito mode and verify the amount, payment button, terms text, and overall appearance.

Verification

After a test payment or a manual status update, check Payment Admin. The Payment Admin documentation explains the pending, authorized, and void statuses, and also shows that transaction data helps you interpret the payment. The invoice history should include events such as creation, notification sending, viewing, status changes, or payment.

A Detail That Often Gets in the Way

If the email was sent but the client says the link will not open, first check the invoice status. A Draft or Temp-like status can block viewing for an unauthenticated user. If the PDF renders as the site's homepage, the PDF troubleshooting documentation points to a common cause: the PDF service cannot access the estimate or invoice, often because of the document status.

WooCommerce and Lead Forms: When Integrations Actually Matter

Sprout Invoices Pro can be used as a standalone invoicing plugin, but part of its real value comes from integrations. The official product page and marketplace mention Gravity Forms, Ninja Forms, Formidable, WooCommerce, and payment add-ons. The important thing is not to enable integrations just to have them enabled: each one should support a specific user path.

Submitting an Estimate Request Through a Form

In the base setup, Sprout Invoices offers the shortcode [estimate_submission]Thank you![/estimate_submission] for estimate submission forms. If you need a more complex brief with conditional logic, file uploads, service selection, and redirects, then form-builder integrations may be worth considering. The Gravity Forms documentation outlines the flow: map form fields to Sprout Invoices data, create an estimate, create a client, and if needed redirect the user to the new document.

There is one specific trap here: the Gravity Forms documentation notes that the form's AJAX setting is not compatible with the redirect option for a new invoice or estimate. If the client is not redirected to the created document after form submission, check that setting first instead of immediately blaming the theme or cache.

WooCommerce Pay Later and Checkout

WooCommerce Invoicing Integration lets you add a flow where the buyer chooses invoice-based payment, and Sprout Invoices creates an itemized invoice tied to the order. The add-on documentation describes configurable Title, Description, and Instructions fields, as well as the {invoice_url} tag for the invoice link. That is useful for wholesale accounts, B2B orders, or any sales process where the final amount is confirmed by a manager.

The WooCommerce Checkout add-on solves the reverse problem: using WooCommerce checkout as the payment path for outstanding invoices. After checkout is completed, an order is created, and when the order reaches complete status, the payment appears in Sprout Invoices and is linked to the invoice. This makes sense if you already trust WooCommerce payment gateways and do not want to configure a separate payment processor just for invoices.

Troubleshooting Common Sprout Invoices Pro Issues

Below are the problems most often tied not to a single specific bug, but to status settings, email delivery, payment processors, client roles, JavaScript conflicts, and recurring logic. Start troubleshooting with a reproducible test: one separate client, one separate invoice, one payment method, and one notification.

The Payment Button Does Not Appear on the Invoice

Symptom: the processor is enabled in settings, but the client does not see a payment button on the invoice. Possible causes: the processor was not saved a second time after its settings appeared, the client record was not updated after adding a new payment method, the invoice is not in the correct status, or the selected processor does not fit the current scenario.

Check Payment Settings, then open the client record and the invoice itself. If the payment method was added after the client was created, follow the troubleshooting logic from the documentation: update the client record and make sure the required payment method is enabled for that client. If this is a credit card processor, remember that only one such processor can be active at a time.

Emails Are Not Arriving or Look Broken

Symptom: the invoice was created, but the client does not receive the notification, or the email looks broken. Possible causes: WordPress email is not being delivered, the from email is incorrect, HTML format was enabled without proper markup, the notification is disabled, or a shortcode was removed from the template.

First verify delivery through your SMTP log or a test send. Then open the notification template and make sure the subject, message body, and shortcodes are still in place. If you use the HTML Notifications add-on, save your own edits before loading templates: the documentation warns that uploading HTML templates replaces existing notification customizations.

The PDF Shows the Homepage or an Old Invoice Version

Symptom: the PDF does not match the invoice, or the homepage appears instead of the document. PDF troubleshooting points to two common causes: the service cannot access the estimate or invoice because of its status, or the cached PDF needs to be refreshed. Check the document status and save the estimate or invoice in the admin area to reset the cached PDF.

Line Items Cannot Be Added or the Edit Screen Breaks

Symptom: buttons on the edit screen do not work, line items cannot be added, or the interface appears partially broken. The JavaScript errors documentation ties these symptoms to theme or plugin conflicts that interfere with jQuery. It also lists a specific workaround for Advanced Custom Fields Pro: fields created for invoices, estimates, or clients should not use Stylised UI.

Check the browser console, temporarily disable recently added plugins on the staging site, and switch to a default theme for testing only. Do not disable everything on the live site without a rollback plan.

Recurring Invoices Are Not Being Created as Expected

Symptom: duplicate invoices appeared, or an invoice was not created when expected. Start by checking which mode is enabled: Recurring Invoices or Recurring Payments. The documentation separately warns against using both modes on the same invoice. If duplicates appeared after an update, the recurring duplicates troubleshooting page explains the scenario where a missed invoice is restored and recommends voiding one of the new invoices instead of simply deleting it without adjusting the start date.

The Currency or Amount Looks Wrong

Symptom: the currency symbol is incorrect, decimal places are missing, or the amount is formatted oddly. Start with the currency formatting options in General Settings. If the client has a separate currency format configured, confirm that it is not overriding the default. Use advanced filters from older troubleshooting examples only if the interface settings do not solve the problem.

Verifying the Result Before Sending Invoices to Clients

The final check should mirror the real client path, not just the administrator's confidence that "the invoice exists." For a payment-related product, that distinction matters: the problem may only appear in the public link, the email, the user role, the payment gateway, or the PDF.

Control Run

1. Create a test client with a separate email address that does not belong to the administrator.
2. Create an invoice with multiple line items, terms, a due date, and a clear status.
3. Open the invoice in incognito mode and review the public view.
4. If the client dashboard is enabled, log in as the client user or use the private URL.
5. Send the notification to yourself and verify the subject line, link, amount, and sender note.
6. Run a sandbox or test payment, or manually record an offline payment on the site copy.
7. Check Payment Admin, invoice history, and the document status.
8. If PDF is used, update the invoice and download the PDF after saving.

After this kind of run-through, you can give the team a short operating instruction: who creates the client, who checks line items, who sends the notification, who confirms payment, and who archives or writes off the invoice. Without clear role assignment, even a good plugin turns into manual confusion.

When Sprout Invoices Pro Is the Right Choice

Sprout Invoices Pro is worth using if you want to keep client invoices, estimates, notifications, and payment history close to your WordPress site instead of spreading them across a separate service. It fits agency and service work especially well: the client submits a request, the manager prepares an estimate, an invoice is created after approval, the client pays a deposit or the full amount, and the team can see the full activity history.

Before going live, do not stop at simply activating the plugin. Check company info, currency formatting, notifications, invoice status, the payment processor, the client dashboard, PDF output, and recurring logic if you need it. For complex payment setups, start with a test scenario and no real clients, then move to the live process only after that.

If this workflow is the right fit after testing, you can get the WordPress version and run one final test on a site copy: one client, one invoice, one notification, one payment method, and one result check. That kind of rollout takes more time than a basic installation, but it significantly lowers the risk of errors on the day a real client sees the invoice.