How to build an e-signature usage and cost model

An e-signature cost model should explain how operational events become billable units without inventing prices. Public labels such as sender, envelope, request, document, or API use may not mean the same thing across proposals. This guide starts with what each vendor publishes, then gives a modeling method; it evaluates no negotiated quote.

What the vendors publish

These are the entry list prices on each vendor's own US pricing page, read on October 27, 2026. Docusign, PandaDoc, airSlate SignNow and Nitro Sign are marked as not verified: their pages were served in another currency, rate-limited our request or showed no readable number that day, and we do not fill the gap with a remembered price.

Two things stand out. First, the plan structure matters as much as the price: five senders on BoldSign Growth come to $25 a month billed yearly, while Jotform Sign's Bronze plan is a flat $34 a month for the account, and Signeasy's $10 Personal seat caps sending at five contracts a month, so it fits one occasional sender, not a team. Second, free plans exist (BoldSign, Jotform Sign), but each comes with a monthly document or envelope cap, which is the number to model, not the price.

Our pick for a small team that wants predictable cost: BoldSign, for the lowest per-user price among the prices we could verify on October 27, 2026, and a free plan to test the workflow on. Who should skip it: a team that needs the broader agreement platform and evidence package we favor in our ranking, where Docusign leads; get its US quote in writing and run it through the model below.

Buyer scenario: growth changes usage unevenly

Imagine a company with several senders, two-recipient agreements, occasional corrections, expired requests, authentication add-ons, an API workflow, and an archive. Growth adds departments and support users, while completed-document volume rises at a different rate from initiated requests.

Define the comparison period, document families, users, senders, recipients, average and exception flows, API events, authentication policy, integrations, storage, support, implementation, and exit. Obtain dated written definitions from each finalist and preserve the contractual source. Do not infer terms from a headline or third-party summary.

Decision criteria: expose every usage driver

Create rows for access, sender or seat rules, transaction units, recipients, pages or files if relevant, bulk sends, API calls, embedded sessions, webhook activity, authentication methods, templates, storage, support, implementation, migration, archive, and export. For each, record quantity, unit definition, source, date, owner, and uncertainty.

Legal and workflow design can change usage, but lower cost should not determine eligibility or evidence. ESIGN and UETA review remains specific to document, party, consent, intent, attribution, association, retention, exclusions, and governing law.

Reproducible evaluation plan

Give every finalist one synthetic operating month containing standard completions, multiple recipients, declines, expirations, recipient corrections, replacements, bulk preparation, API retries, authentication fallback, and evidence retrieval. Ask in writing how each event is counted.

Build expected, high-use, integration-failure, and growth scenarios. Change one driver at a time, keep vendor charges separate from internal labor, and ask finance to reproduce formulas. Include implementation delay and exit retrieval. This plan is proposed; no price response was assessed here.

Edge case: correction creates another unit

Suppose an invalid recipient or expired request requires replacement and is counted differently than expected. Model a period with elevated corrections, identify available usage alerts, and request written interpretation of the proposed terms.

Do not hide uncertainty in an average. Show a range and the operational action that reduces or monitors exposure. Data-quality work may lower resends, but the contract still needs a clear definition.

Add a timing view to the model. Implementation, template conversion, legal review, integration work, training, and archive design occur before stable usage; support and exception handling continue afterward; exit retrieval and overlap arrive later. A single total can hide a demanding launch period or renewal exposure. Mark fixed, variable, usage-triggered, optional, third-party, and internal items separately. Keep benefits in another table with a measured baseline rather than subtracting speculative time savings. After launch, reconcile actual operational events to billed units and investigate differences by definition, not just amount. Update the model when document families, authentication, API flows, or contract terms change.

Include sensitivity for data quality and workflow design. Better recipient data may reduce corrections, while stronger authentication or another approval may add operational steps and usage. Present those changes transparently rather than labeling them inefficient. The model should inform a compliant, owned workflow—not encourage removal of evidence or controls solely to lower a forecast.

Document every scenario assumption in a change log. When a proposal definition, contract term, document family, sender policy, authentication method, or API design changes, update only the affected drivers and retain the prior version for comparison.

Conclusion: compare dated definitions, not headlines

Choose only after applying each proposal's current definitions to identical workflows and exceptions. Preserve assumptions, source documents, ranges, and internal effort. Predictability comes from measurable drivers, transparent terms, monitoring, and periodic reconciliation—not an invented universal per-signature price.

Before modeling paid volume, check whether a free plan already covers it: free e-signature plans compared lists what each free tier lets you send.