The real cost of per-page pricing: what IDP vendors don't tell you at scale

A $0.10 page sounds harmless. Process a few hundred invoices a month and the bill barely registers. But when a mid-size insurer runs 500,000 pages through their IDP platform in a quarter, that dime becomes a $50,000 line item. Double the volume next year and you're looking at six figures for the same software doing the same thing.

Per-page pricing is the default model in intelligent document processing. Vendors love it because it sounds accessible. You love it because there's no big upfront commitment. But at scale, it becomes a tax on your own growth. The more documents you process, the more you pay, with no ceiling and no volume logic.

This is the part vendors skip in the sales demo.

The math breaks quietly

Most teams adopt IDP to solve a specific pain point. Maybe it's invoice processing, or claims intake, or freight document handling. The pilot runs 5,000 pages a month. At $0.08 per page, that's $400. Easy budget approval.

Then the rollout expands. New document types get added. Other departments want in. Within 18 months, volume hits 100,000 pages a month. Now it's $8,000 monthly. $96,000 a year. For context, that's the fully loaded cost of a junior operations analyst, except the software doesn't get smarter the more you pay it.

The worst part: the vendor's marginal cost to process your 100,000th page is nearly zero. Cloud compute for inference is cheap and getting cheaper. You're not paying for resources. You're paying because the meter is running.

Hidden multipliers nobody mentions

Per-page pricing has secondary costs that don't show up on the invoice.

Reprocessing. Documents fail validation. Templates change. Someone uploads a batch in the wrong format. Every reprocessed page counts again. We've talked to operations teams who estimate 8-15% of their volume is reprocessing. That's a surcharge for the system's own errors.

Multi-page documents. A 40-page insurance policy isn't 40 independent units of work. The AI reads the whole thing as one document. But you get charged for 40 pages. A single freight manifest with attachments can run 15-20 pages. The pricing model treats a one-page receipt and a 20-page contract as fundamentally different transactions, even when the processing complexity is identical.

Testing and development. Every time you configure a new document type, you run test batches. QA cycles burn pages. Staging environments burn pages. Some vendors count them. Some don't tell you until the bill arrives.

Seasonal spikes. Insurance companies see claims volume double after natural disasters. Freight companies see surges during peak shipping seasons. Per-page pricing means your software costs spike exactly when your operational costs are already elevated. That's the opposite of how infrastructure should work.

What this does to decision-making

Here's the part that doesn't show up in any ROI calculator: per-page pricing changes behavior.

Teams start rationing. They keep some document types on manual processing because adding them to the platform would push costs too high. They skip reprocessing batches that had errors because it's "not worth the pages." They avoid expanding to new departments because each one adds volume.

You bought automation software to process more documents faster. Per-page pricing punishes you for doing exactly that.

One transportation company we spoke with delayed onboarding customs declarations for six months because their IDP vendor quoted $0.12 per page and the volume projections made the business case negative. They were manually keying in customs data, paying humans to do work a machine could handle, because the machine's pricing model made automation more expensive than labor.

That's a broken incentive structure.

What good pricing actually looks like

Pricing should reward adoption, not penalize it. When a team processes more documents, costs per document should go down, not stay flat or go up.

Flat or tiered pricing models align vendor incentives with customer outcomes. You pay for the platform's capability, not for each unit of work it performs. Your cost becomes predictable. Budget planning gets simpler. And the decision to automate a new document type becomes a question of implementation effort, not ongoing cost multiplication.

At Doculent, we chose transparent pricing with no per-page fees at scale for exactly this reason. We want our customers expanding their use of the platform. Every document type they add, every department they onboard, every reprocessing run they need to do: none of it should come with a surprise bill.

Our model is built around workspaces and capabilities, not page counts. You pay for what the platform can do, not for how much you use it.

How to evaluate your current costs

If you're already on a per-page model, run this exercise:

Pull your last 12 months of page volume. Include reprocessing, test runs, and failed batches. Multiply by your per-page rate. Now project 2x volume for next year, because if your IDP adoption is working, volume should be growing.

Compare that number against flat-rate alternatives. Factor in the document types you haven't automated yet because the per-page math didn't work. Factor in the reprocessing runs your team skipped. Factor in the departments still doing manual entry.

The real cost of per-page pricing isn't just what you're paying. It's what you're not automating because the pricing model won't let you.

Stop paying a tax on your own efficiency

Per-page pricing made sense when IDP was experimental and volumes were small. That era is over. Document processing volumes are growing across every industry. The vendors who charge by the page are betting that you won't do the math until you're locked in.

Do the math now.

If you want to see what predictable pricing looks like for your document volume, request a demo. We'll model your current costs against Doculent's pricing and show you the difference. No page counters involved.