How do I get transaction price out of a PandaDoc document for ASC 606?
Read the pricing table's row-level Price, Quantity, and Discount fields from the completed document, not the template — PandaDoc's Document Details endpoint exposes this programmatically. Sum the row totals for the transaction-price basis ASC 606 needs, then handle Tax separately: it's a distinct field, generally excluded under the ASC 606-10-32-2A practical expedient.
By Zuny Fester, Head of Operations and MarketingPart of the finance integrations guide.
| Where the price data lives | The document's pricing_tables array, each row carrying Price, Quantity, Discount, Tax, Fee |
|---|---|
| How to read it back | The Document Details endpoint, called after the document is completed, not the create-document payload |
| What to exclude | Tax is a separate row field — ASC 606-10-32-2A lets an entity elect to exclude sales tax from the transaction price |
| Real risk | Multichoice pricing sections can present several options; only the row(s) the signer actually selected should count |
| Contrast | DocuSign has no equivalent structured pricing object to read this way — a separate, existing page on this site covers that gap |
What ASC 606 actually needs from a signed document
Determining transaction price under ASC 606 means arriving at the amount of consideration an entity expects to be entitled to in exchange for the goods or services promised — line by line, if the contract has multiple performance obligations. A PandaDoc pricing table is structured close enough to that shape to use directly: each row carries typed Price, Quantity, Discount, Tax, and Fee fields, not free text, which is what makes automated extraction realistic instead of a manual re-entry exercise.
Reading the data back after signature
PandaDoc's own developer documentation is explicit that pricing data is populated when a document is created, but reading it back for downstream use is a separate call — the Document Details endpoint, invoked once the document has actually reached a completed status. Reading pricing data from the create-document payload instead of Document Details risks pulling pre-negotiation numbers if the proposal changed before it was signed.
Where tax fits — and where it doesn't
A pricing table row's Tax field is a distinct value from Price, not baked into it. That separation matters for ASC 606 specifically: under the sales-tax practical expedient in 606-10-32-2A, an entity can elect to exclude taxes assessed by a governmental authority and collected from the customer — sales, use, and similar taxes — from the transaction price entirely, rather than treating tax as part of the consideration for the goods or services. Reading a row's Price and Quantity while leaving Tax out of the transaction-price calculation is usually the correct default, not an oversight, once that election is made.
Handling multichoice pricing sections
A pricing table can include a multiple-choice section where the signer picks one product or plan out of several presented options. A workflow that sums every row in that section instead of only the selected one will overstate the transaction price. Check which row(s) the signer's choice actually resolved to before summing, not every row that was ever offered.
Next step
Map the finance workflow with the most exposure and prove the automation path.
Bring the invoice, contract, payment reconciliation, or customer finance workflow you have to defend at audit. Loopfour can map the trigger, controls, integrations, and approval loop.
Worked example
A $12,000 annual plan with a 10% discount and a multichoice section
A PandaDoc proposal presents two plan options in a multichoice pricing section — a $12,000/year standard plan and a $18,000/year premium plan — plus a fixed $500 onboarding fee row outside that section. The signer selects the standard plan. The document's pricing table, read via Document Details after completion, shows the standard-plan row with Price=12000, Quantity=1, Discount={value:10,type:'percent'}, and Tax={value:8.5,type:'percent'}; the premium-plan row is still present in the underlying data even though it wasn't chosen. A workflow that sums every row in the multichoice section would double the plan revenue ($30,000 instead of $10,800 net of discount); the correct transaction price is $10,800 (standard plan, discounted) + $500 (onboarding fee) = $11,300, with the row's Tax field excluded from that figure under the sales-tax practical expedient.
Frequently Asked Questions
Sources
Related
Topic
Integrations
Every finance automation vendor publishes an integrations page: a grid of logos, a claim of "seamless" connectivity, and not much else. That page answers a marketing question — does this vendor touch…
Read moreDiagnostic
Does a DocuSign envelope carry contract-value data for revenue recognition?
No, not as a structured field. A DocuSign envelope exposes signer-facing tabs and free-form custom fields, but neither is a line-item or deal-value object — tabs collect data a signer enters or reviews, and custom fields store metadata as arbitrary strings. There is no built-in field a revenue-recognition workflow can read as "contract value."
Read moreDiagnostic
Can a PandaDoc proposal's pricing table become the AR invoice basis?
Structurally, yes. A PandaDoc pricing table stores typed rows with name, price, quantity, tax, and fee fields — real data an AR workflow can read directly, unlike a DocuSign envelope's free-text fields. The catch is timing and accuracy: the invoice basis should come from the signed document's final pricing table, not a draft version that changed during negotiation.
Read moreDiagnostic
Does sales tax calculated by Avalara count toward ASC 606 transaction price?
Not if you elect the practical expedient in ASC 606-10-32-2A, which lets an entity exclude sales, use, and similar taxes collected from a customer from the transaction price entirely. Avalara's own model already keeps tax separate — totalTax and totalAmount are distinct fields, and grandTotal is what's shown to the customer, not the revenue figure.
Read more