The per page tax: how legacy VDR pricing penalizes LMM diligence

TJ Moruzzi
Published At Sun Jun 07 2026

Legacy virtual data room pricing penalizes the deals that close fastest. The vendor wins when your deal stalls. Read that twice.
This post walks the math on a typical $30M LMM deal, the three pricing anti-patterns to walk away from in 2026, and what flat-fee pricing changes for the seller and the banker.
The math
Take a $30M LMM sell side deal. The data room runs 90 days from launch to close. Standard load:
- 18,000 pages of documents (TTM financials, contracts, HR, IT, environmental)
- 28 buyers signing NDAs and entering the room
- 12 GB of total storage
- Active Q&A module
On legacy enterprise VDR pricing, the bill looks like:
| Line item | Math | Cost | |---|---|---| | Base subscription, 90 days | flat | $4,500 | | Document upload fee | 18,400 pages × $0.85 | $15,640 | | Per-user fee | 28 buyers × $150 | $4,200 | | Storage overage | 12 GB × $200 | $2,400 | | Q&A module add-on | flat | $1,800 | | Total | | $28,540 |
That's $28K to store PDFs and let buyers read them. On a $30M deal that's roughly 0.1 percent of headline. For a tool category that has been commoditized for a decade.
The three pricing anti-patterns
Three pricing models I want every LMM banker to walk away from:
Per page
The $0.85-per-page rate is the legacy enterprise standard. Each page uploaded into the data room incurs a fee. Some vendors charge once at upload; others charge monthly until removed.
The economic problem: per-page pricing penalizes thorough diligence. The more documents the seller loads (pre-launch readiness, supporting schedules, historical comparables), the higher the bill. The pricing model rewards under-prepared rooms.
The correct incentive is the opposite. Sellers who load comprehensive rooms close faster and retrade less. The vendor should charge nothing extra for that.
Per gigabyte
Per-gigabyte pricing shows up in midmarket vendors. Each GB of storage incurs a monthly fee.
The economic problem: per-GB penalizes large files. Engineering and CAD-heavy industrials, manufacturing businesses with technical specs, healthcare deals with imaging files all get hammered for being themselves. The deal doesn't pay the vendor more if the files are bigger; the vendor just charges more.
Per user
Per-user pricing charges for each buyer or buyer-side counsel that enters the room. Common in legacy enterprise vendors, sometimes paired with per-page.
The economic problem: per-user penalizes broad processes. The seller's banker wants to invite the right buyers. Adding a buyer should be a strategic decision driven by deal economics, not by VDR billing. Per-user pricing introduces friction that doesn't serve the deal.
What good pricing looks like
The alternative is flat-fee per deal:
- Unlimited pages
- Unlimited users
- Unlimited storage
- Q&A included
- Bill is the bill, regardless of timeline
On the same $30M deal, flat-fee pricing costs $2K to $5K depending on vendor and term. That's 6 to 15x cheaper than legacy enterprise pricing on a typical deal, and the math gets better as deals run longer or load heavier.
Why the pricing model matters
The pricing model is a product decision. When the vendor's revenue is rewarded for the wrong outcome (slower deals, more pages, more users), the product itself usually optimizes for the wrong outcome too. Legacy enterprise VDRs have built features that justify the pricing: extensive admin overhead, complex permission schemas, expensive support tiers.
A vendor priced flat-fee has different incentives. The product gets cleaner because the vendor wants the deal to close fast. The seller gets the same security and the same audit logs without the bill creep.
This is not a hypothesis. Compare the legacy enterprise VDR product page to a modern flat-fee VDR product page. The legacy page leads with admin features and security ribbons. The modern page leads with deal speed and clean UX.
What changes for the banker
If you are a sell side banker running 6 to 12 deals a year, the pricing model affects:
- How aggressively you load rooms. With flat-fee, you load everything pre-launch. With per-page, you load conservatively and add as buyers ask.
- How many buyers you invite. With flat-fee, you invite the right buyers. With per-user, you sometimes hold buyers off the room until they look serious.
- How long deals run. With flat-fee, the bill is the bill. With per-day or per-page, you have a hidden incentive to wrap quickly that may conflict with seller-favorable timing.
None of these conflicts should exist. The VDR is infrastructure. The banker should not have to think about its pricing model during a live deal.
What changes for the seller
The seller pays the VDR bill (sometimes split with banker or buyer). On a $30M deal, the difference between $28K and $3K is small relative to the deal but it's real. More importantly, the seller's banker is freed up to make deal decisions without VDR billing entering the calculus.
What to ask any VDR vendor
When evaluating a VDR for the next deal, ask:
- Is this priced flat-fee or by usage?
- If usage-based, what specifically am I being charged for (pages, users, GB, time)?
- Does the bill grow if the deal runs long?
- Is Q&A included or extra?
- Are there overage fees for storage or pages over a cap?
- What's the actual all-in cost on a typical $30M LMM deal with 25 buyers?
Get the answer to question 6 in writing. Compare to the legacy bill above. Decide accordingly.
Tools and references
Compare the all-in pricing on your next deal at lockroom.com/pricing. Flat-fee per deal, unlimited users, unlimited storage, unlimited pages.
For diligence prep that fills the data room with the right content, see the Sell Side Diligence Prep Checklist.
Bottom line
Per-page, per-user, and per-gigabyte VDR pricing penalize the wrong things. The seller pays more for being prepared, for inviting the right buyers, and for running diligence at the right pace.
Pricing is a product decision. When the vendor's revenue grows when your deal stalls, the product probably reflects that.
Pay for outcomes, not for using the tool.

