PandaDoc Pricing Tables: The Complete Guide to Quantities, Optional Items, Discounts and Tax

A PandaDoc pricing table is a structured block inside a document that holds your line items: each row carries a product, a quantity, a unit price, and optional discount and tax fields, and the table computes subtotals and a grand total automatically. Because the pricing is structured data rather than typed-in text, it can pull from a product catalog, respond to rules, feed approval workflows, and write totals back to your CRM.

That last sentence is the entire reason this guide exists. Most teams treat the pricing table as a formatting element: a place to make the numbers look tidy. The teams that get real leverage out of PandaDoc treat it as the data layer of the quote, and build quantities, optional items, discount limits, and tax rules into the table itself so reps stop doing arithmetic and clients stop finding errors. Pricing complexity and the fear of quoting errors came up in 28 of the 129 sales calls we analysed, and in almost every case the root cause was the same: pricing living in a rep’s head, a spreadsheet, or a free-typed text block instead of in a structured table.

Key takeaways

• Pricing table rows should come from the product catalog, not free typing. Catalog rows carry consistent names, descriptions, and prices, and they are what makes rules, reporting, and CRM sync possible.
• Quantities can be locked, rep-editable, or client-editable. Client-editable quantities turn a static quote into a mini configurator, but only make sense where unit economics hold at any quantity the client might pick.
• Optional items let the client tick add-ons directly in the document, with the total recalculating live. They are the cheapest upsell mechanism you are not using.
• Discounts belong in the table’s discount fields, with limits enforced by approval rules, never typed into a description or applied as a mystery “adjusted price”. A discount no system can read is a discount no system can govern.
• Tax should be applied by rule per row or per table, not calculated by hand. Manual tax on quotes is where the most expensive and most embarrassing errors live.
• A structured pricing table is the prerequisite for everything upstream: CPQ rules, discount approvals, deal-amount writeback to the CRM, and AI-assisted quote generation all read the table.

What is a PandaDoc pricing table and how does it work?

The pricing table is a native PandaDoc content block you drop into a document or, far better, into a template. It is made of rows and columns. Each row is a line item; the standard columns are name, description, price, quantity, and line total, and you can add columns for SKU, discount, tax, or custom fields your quotes need. Rows can be grouped into sections with their own subtotals, which is how you separate one-time fees from recurring charges, or hardware from services, on a single quote.

Two things distinguish it from a table you might draw in Word:

1. It calculates. Quantity times unit price, minus discounts, plus tax and fees, summed to section subtotals and a grand total. Change any input and every dependent number updates. The rep never touches a calculator, which matters because manual proposal building was the top pain in 82 of 129 calls we analysed, and re-keying arithmetic is a big slice of that time.
2. It is machine-readable. Because each value sits in a typed field, other systems can read and write it. The PandaDoc HubSpot integration can push deal line items into the table and write the final total back to the deal amount. Approval rules can fire on the discount field. None of that works on numbers typed into a paragraph.

Rows can be added by hand, but the right pattern on any team bigger than one is the product catalog: a central library of SKUs with names, descriptions, and list prices that reps pull into the table. Catalog rows keep naming and pricing consistent across every quote, and they are what your reporting and any future rules are built on. If your reps are typing product names into quotes from memory, fixing that is step one, before anything else in this guide.

Quantities: from locked numbers to client-driven configuration

Every pricing table row has a quantity, and the design decision is who gets to change it.

Locked quantities are set in the template or by the rep and cannot be changed by the recipient. This is the default and the right choice for scoped services: a fixed-scope implementation is one implementation, and nobody should be able to make it 0.5 of one.

Rep-editable quantities are the normal case for unit-priced items: seats, licences, devices, days. The rep sets the quantity while building the quote. If your unit price changes at volume breakpoints, that logic belongs in rules or in clearly separated catalog SKUs per tier, not in the rep’s judgement on the day.

Client-editable quantities are the interesting one. PandaDoc can let the recipient change a quantity in the sent document, with the total recalculating live in front of them. Used well, this removes an entire revision cycle: the client who wants 12 units instead of 10 adjusts the number and signs, instead of emailing you for a new version. One hardware reseller we worked with was quoting drone equipment with accessory quantities that varied on almost every deal; making those quantities client-adjustable turned a back-and-forth into a single send.

The discipline: only make a quantity client-editable where any value the client could choose is a deal you would accept, and set minimums where that is not true. A client-editable quantity with no floor is an invitation to order one unit of something you only sell in tens.

Optional items: let the client build their own quote

Optional items are rows, or whole sections, the recipient can tick or untick in the delivered document. An unticked optional row contributes nothing to the total; tick it and the total updates instantly. PandaDoc also supports choice-based sections where the client picks one option from several, which is how you present Good, Better, Best tiers in one document instead of sending three quotes.

This is the most underused feature in the product, and it does two jobs at once:

• It is a passive upsell. Training add-ons, extended support, extra templates, priority onboarding: put them in the table as optional rows with real prices. Some percentage of clients tick them, and that percentage is pure margin on quotes you were sending anyway. The alternative, mentioning add-ons in an email after signature, converts far worse because it reopens a closed decision.
• It kills the quote-revision loop. A large share of “can you send a revised version” emails are really “can you add or remove line X”. If X is optional in the table, the client does it themselves. For teams already spending 45 to 50 minutes building each proposal, a stat one agency we spoke to put on its own quoting process, every avoided revision is real recovered time.

Two rules keep optional items honest. First, price them properly: an optional row is a real offer, and a placeholder price that later gets “corrected” burns trust at the worst moment. Second, keep the mandatory core unambiguous. The client should never be able to untick something the project cannot proceed without; scope integrity is not client-configurable.

Discounts with limits: govern the field, not the rep

The discount is the most dangerous number on a quote, and where you put it decides whether you can control it.

PandaDoc pricing tables support discounts as a percentage or a fixed amount, applied per line item or to the whole table. Use those fields, and only those fields. The anti-patterns we see in almost every rescue project: a rep lowers the unit price and the discount becomes invisible, or types “10% partner discount applied” into a description while the maths happens somewhere else, or maintains a personal spreadsheet of “real” prices. In every case the CRM records a fiction, finance cannot report on discounting, and no rule can intervene.

When the discount lives in the discount field, three controls become possible:

1. Visibility. The client sees list price, discount, and net price. A visible discount does selling work; a silently lowered price just resets the client’s anchor for the next deal.
2. Limits. This is where discount policy becomes enforceable. PandaDoc’s approval workflows can fire conditionally on the document, so a discount within the rep’s authority sends immediately while anything past the threshold routes to a manager before it can go out. We covered how to design those gates, and why they should catch exceptions rather than every deal, in our PandaDoc approval workflows setup guide.
3. Reporting. Structured discounts roll up. You can answer “what is our average discount this quarter, by rep” from data instead of folklore.

Set the limit bands in one written policy: what a rep can do freely, what needs a manager, what needs finance. Then let the table and the approval rules enforce it. Policy that lives in a handbook and not in the document system is a suggestion.

Tax by rule: the errors that cost the most

Tax is where manual quoting produces its most expensive mistakes, because a tax error is not a negotiating position, it is a compliance problem and sometimes an eaten cost.

PandaDoc lets you apply tax as a percentage per line item or on the table total, and because it is a field, it can be templated: build one template per tax context, or drive the right rate through the catalog and rules, and the rep never chooses a rate at all. That is the goal state: the rep should never be the tax engine.

The messy reality this replaces is worth naming. One reseller we worked with quotes across Canadian provinces, where GST and PST rates differ by province and some customers hold exemptions. Before the rebuild, a person applied that logic by hand on every quote, and every quote was a chance to get it wrong. After it, the rules apply the right treatment per row, exempt items carry no tax, and the delivery call included the line every implementer wants to hear: the taxation is automated now.

Practical guidance:

• Tax per line, not per total, whenever items differ. Mixed quotes, such as taxable hardware plus differently-treated services, need row-level tax. A single rate slapped on the total is only correct when everything on the quote is treated identically.
• Handle exemptions structurally. An exempt client should get a template or rule path where exempt items carry no tax, not a rep remembering to zero a field.
• Know when to escalate. If you are selling into many jurisdictions with real complexity, PandaDoc’s native fields hand off to dedicated tax engines; at that point you are firmly in CPQ territory, which is the next section.

When pricing tables need CPQ on top

Everything above is available in a well-built pricing table. The ceiling arrives when the logic between the fields gets conditional: selecting product A must add product B, price depends on a formula across other rows, tiers swap whole sections in and out, or a 60-month pricing model has to be assembled from data that currently lives in Excel and the CRM, a pattern we met at a telecoms services firm whose quotes combined both. One prospect we scoped needed around 80 documents a day generated against rules like these; no rep-maintained table survives that.

That conditional layer is exactly what PandaDoc CPQ adds on top of pricing tables: rules that add, remove, show, hide, and reprice line items based on selections, formula-driven pricing, and discount ladders wired to approvals. The pricing table is still the foundation; CPQ is the logic that operates on it, which is why a clean catalog-driven table is the prerequisite, not an alternative. If your stack is HubSpot-first, our blueprint on PandaDoc CPQ inside HubSpot covers how the two connect end to end.

The same is true in the other direction: a pricing table only performs inside a template that reps cannot break. Locked layouts, consistent branding, and the table wired into the right PandaDoc template structure is what makes all of this usable at speed. And sequencing the whole build, catalog first, templates second, rules and approvals after, is the core of a proper PandaDoc implementation.

Frequently asked questions

Which PandaDoc plans include pricing tables?

Pricing tables are a core feature available across PandaDoc’s paid plans. The advanced layer on top of them, rule-based CPQ behaviour, formula pricing, and conditional approvals, is gated to higher tiers. Feature packaging changes, so verify the specific capabilities you need against PandaDoc’s current pricing page before designing a quote process around them.

Can the client change quantities or select options after I send the quote?

Yes, if you configure it. Quantities can be made recipient-editable and rows or sections can be marked optional or multi-choice, with the total recalculating live in the document. Nothing is client-adjustable unless you make it so; locked rows stay locked.

Should discounts be applied per line item or on the whole table?

Per line when the discount genuinely belongs to specific items, such as a hardware promotion that should not discount services. On the table total when it is a deal-level concession. Either way, use the discount fields rather than editing unit prices, so the discount stays visible, reportable, and governable by approval rules.

How does the pricing table interact with our CRM?

Through the native integrations. With HubSpot, for example, deal line items can populate the table when the document is created, and the finished total writes back to the deal amount, so pipeline reporting reflects what was actually quoted. This only works cleanly when rows come from a catalog and totals come from the table’s own fields.

Can PandaDoc pricing tables handle recurring and one-time charges on one quote?

Yes. The standard pattern is separate sections, one for one-time fees and one for recurring charges, each with its own subtotal so the client sees setup cost and ongoing cost distinctly. Multi-year or usage-based structures beyond that usually call for the CPQ layer and, past a point, a dedicated billing tool.

Build the table once, quote from it forever

A pricing table built properly, catalog rows, deliberate quantity permissions, priced optional items, discounts in governable fields, tax by rule, turns quoting from arithmetic into selection. Reps assemble instead of calculate, clients configure instead of email, and every number on the quote is data your CRM and your rules can see.

If your quotes involve real pricing logic, volume tiers, bundles, discount policy, or multi-jurisdiction tax, this is the exact ground our PandaDoc CPQ implementation service covers: we design the catalog, build the tables and rules, and wire the approvals so the maths is never the rep’s job again. Book a call and bring your ugliest quote; it is usually the best requirements document we could ask for.