How to Write a Document Extraction Software RFP That Gets Real Answers

Most RFPs for document extraction software are written backward. They start by listing features the buyer thinks they need — "must support PDF, JPG, and PNG," "must export to Excel and CSV" — and then distribute that list to vendors who check every box without hesitation because, well, every tool in this category does those things. The result is a stack of proposals that all look identical, scored against criteria that never separated anyone. This article inverts that pattern: start with your documents, your team, and your error tolerance, then build questions that force vendors to reveal where they actually differ.

The Real Purpose of an RFP (It's Not What You Think)

The stated purpose of an RFP is vendor selection. The real purpose — the one that determines whether you pick the right tool or burn six months on a bad implementation — is something else entirely.

An RFP forces your organization to answer questions it has been avoiding. Which documents are you actually processing? How many? What does "accurate enough" mean for your workflow? Who will operate the tool after procurement signs the contract? If you can't answer these questions, no vendor can answer them for you — and any tool you pick is a gamble dressed up as a decision. The same principle underlies our evaluation framework for data extraction software: every criterion that matters is a question about your operation, not a feature to check off a vendor's list.

The RFP's highest-value output isn't the signed contract. It's the internal alignment document that gets created during the writing process. The questions you can't answer without internal debate are the ones that would have sunk the implementation later.

This is why most vendor-supplied RFP templates — the ones you can download from Rossum, Klippa, or any other IDP company's blog — only get you halfway. They structure the document, but they're designed to be easy for vendors to respond to. The template asks "do you support multi-page PDFs?" and every vendor says yes. What you should have asked is "we receive 40-page insurance policies with appendices, split tables, and handwritten margin notes — here are three samples — describe how your system handles page 27's continuation table when it has no header row."

The difference between those two questions is the difference between a procurement exercise and a procurement decision.

Before You Write a Single Question: Define Your Document Reality

Every document extraction RFP should begin with a section most templates skip entirely: a candid description of what your documents actually look like. Not what you wish they looked like. Not the cleanest example you could find. The median document in your incoming queue.

Collect 8-10 representative samples from your actual workflows. Don't cherry-pick the clean ones. Include:

The scanned PDF that's been printed, stamped, and scanned again at 150 DPI
The photo someone took of a receipt with their phone in a dim restaurant
The multi-page document where line items break across pages without repeating the header
The document with handwriting in the margins and overlapping stamps
The fax from 2019 that's slightly rotated and has a gray background

Annotate each sample by marking the fields you need extracted — vendor name, date, line items, totals, tax identifiers, whatever matters to your operation. This annotated set becomes the single most important appendix in your RFP. It lets vendors skip the "what do your documents look like?" discovery call and demonstrate capability directly.

If you send this appendix to five vendors and three of them say "we'll need to see these in a call," you've already learned something those three didn't want you to learn before the contract.

The 7-Section RFP Structure (and What Each Section Is Actually Testing)

Every RFP section should do two things: gather information and test a hypothesis about the vendor. If a section only gathers information, it's a form. If it tests nothing, it's wasted space. Here are the seven sections that do both — and what you're really probing with each one.

Section 1: Document Reality

What you're actually testing: Can the vendor handle your documents, not just the clean samples on their demo page?

Most RFPs open with "Company Background." Skip that. Open with your documents. Attach the annotated sample set. Require vendors to return a completed extraction for each sample document, showing exactly which fields they captured, which they missed, and how they'd handle the edge cases you annotated.

Questions that separate real tools from checkbox-fillers:

"Attached are 10 document samples from our actual workflows. For each sample, provide the extracted output for these fields: [your field list]. Mark any field you cannot extract with confidence and explain why."
"Sample #4 contains a line-item table that spans pages 2 and 3 without repeating the header row on page 3. Describe your system's approach to this scenario — does it infer continuation from layout, or does it require the header row to be present?"
"Sample #7 is a photo taken from a phone under office lighting. Does your system perform any automatic preprocessing (deskew, contrast adjustment, de-noise) before extraction? If so, describe the pipeline."

Don't ask: "Do you support JPG, PNG, and PDF?" Every tool does. This question tells you nothing.

Do ask: "Here is what our documents look like. Show us the extraction." This forces vendors to demonstrate, not claim.

Section 2: Integration Requirements

What you're actually testing: Does the extracted data land where your team actually works — or does it create a new silo?

Extracted data has a destination. It's going into your ERP, your accounting system, your database, or someone's spreadsheet. The integration question isn't "do you have an API?" — it's "does the data arrive in the schema and system my downstream process expects, without a manual reformatting step in between?"

Questions that surface real integration friction:

"We export extracted data to [system name, e.g., QuickBooks Online / SAP / NetSuite]. Describe the end-to-end path from extraction to arrival in our system — include any intermediate steps, format conversions, or manual actions required."
"If our field names don't match the destination system's schema exactly (e.g., our extraction produces 'Vendor Name' but the ERP expects 'Supplier Name'), does your system support field mapping without custom development?"
"Do you provide webhooks or event-driven triggers so our downstream system can process data as soon as extraction completes, or is export a manual step?"

Don't ask: "Do you have an API?" This is a yes/no that every vendor answers yes to.

Do ask: "Walk us through the exact path from extraction to our ERP. Where does a human touch the data?"

Section 3: Accuracy Requirements

What you're actually testing: What does "accurate" mean for your operation — and can the vendor define it in measurable terms?

Every vendor claims 95-99% accuracy. This number is almost always character-level OCR accuracy on clean text — not field-level extraction accuracy on your actual documents. It's a marketing metric, not an operational one.

The real accuracy question is: of the fields you care about, how many come back correct on the first pass, and what's the correction workflow for the ones that don't?

Questions that force numerical answers:

"For the 10 sample documents we provided, report field-level extraction accuracy — each field is either correct or it isn't. Do not report character-level OCR accuracy."
"When a field is extracted with low confidence, what happens? Describe the review interface. Can a reviewer see the original document snippet alongside the extracted value? Can they correct it inline?"
"If we identify a systematic extraction error (e.g., the system consistently misreads 'O' as '0' in invoice numbers from one specific supplier), how do we correct it permanently? Does your system learn from corrections, or do we need to configure rules?"

Don't ask: "What is your accuracy rate?" You'll get a marketing number.

Do ask: "Here are our documents. Show us your field-level accuracy. Show us how we fix the errors."

Section 4: Scalability

What you're actually testing: Does the tool's architecture match your volume trajectory — or does it hit a wall at exactly the point where automation becomes most valuable?

Scalability has two dimensions: volume (how many documents per month) and variety (how many different document types and layouts). A tool that works beautifully on 50 invoices a week might crumble at 500 — or it might handle 5,000 just as easily. The inflection point depends on the tool's architecture, not its marketing.

Questions that map to your reality:

"We currently process approximately [N] documents per month across [M] document types. We expect this to grow to [X] documents per month within 18 months. At what volume does your pricing model or processing architecture change meaningfully?"
"If we add a new document type six months in — say we bring contract extraction online in addition to invoice processing — what does the setup process look like? Do we need to train a new model, configure new templates, or simply define new fields?"
"Describe your batch processing capabilities. If we upload 200 documents at once, can we review and export all results in a single session, or does the system process them one at a time?"

Don't ask: "Is your solution scalable?" Every vendor says yes.

Do ask: "At what volume does your tool's behavior change? At what volume does your pricing model break?"

Section 5: Operational Requirements

What you're actually testing: Who in your organization will actually use this tool day to day — and does the interface match their technical comfort level?

This is the section where most RFPs quietly skip the most important question. The person evaluating tools (you, reading this) is often not the person who will use the tool every day. If your AP clerk needs a two-week training course to extract an invoice, the implementation has already failed — regardless of how powerful the engine is.

Tools in this category span a wide usability spectrum. At one end, some platforms require you to define column names in plain language and upload documents — no training, no template configuration. At the other end, you're labeling 50 sample documents per document type, training per-supplier models, and configuring extraction pipelines through admin panels that assume you understand OCR concepts. Both approaches have their place, but placing the wrong one in front of the wrong team is the fastest path to shelfware.

ImageToTable.ai sits on the low-friction end of this spectrum through its Custom Column Extraction approach: you type the field names you want — "Vendor Name," "Invoice Date," "Line Total" — and the AI locates each value by understanding what it means semantically, not by matching a template coordinate. No sample labeling, no model training. The columns you name become your output table headers. For teams without dedicated IT, this is the difference between going live in an afternoon versus waiting for an implementation project.

Questions that reveal the real user experience:

"Time a new user: from account creation to having a correctly formatted Excel file of extracted data from one of our sample documents. How long does this take? Provide a screen recording of the process."
"If an AP clerk with no technical background needs to process a new supplier's invoice format, what steps do they follow? Do they need to involve IT or configure anything?"
"Describe the correction workflow when an extraction error is found. Can the user fix it directly in your interface, or do they need to export to Excel, fix it there, and re-upload?"

Don't ask: "Is your tool user-friendly?" This is the single most meaningless question in any software RFP.

Do ask: "Record a screen capture of a first-time user processing one of our documents. Show us the full journey."

Section 6: Compliance & Security

What you're actually testing: Does the vendor's security posture match your regulatory exposure — and can they prove it with certifications, not assurances?

Security questions in RFPs tend to become a checklist of acronyms: SOC 2, ISO 27001, GDPR, HIPAA. These are important, but they're table stakes for any serious vendor in 2026. The questions that actually differentiate vendors are about architecture — where your documents live during processing, whether they're used for model training, and who has access.

Questions that reveal architectural decisions:

"Are uploaded documents used to train or improve your AI models? If so, is this opt-in, opt-out, or mandatory? Specify per deployment tier."
"Describe your data retention policy. After extraction completes, how long do our documents remain on your servers? Can we configure auto-deletion?"
"For regulated industries: do you support data residency requirements (e.g., EU-only processing for GDPR, in-country processing for specific jurisdictions)? If not available today, what is your roadmap?"
"Provide your most recent SOC 2 Type II report, ISO 27001 certificate, and penetration test summary. If these reports are under NDA, describe the process for sharing them."

Don't ask: "Do you take security seriously?" The answer is always yes.

Do ask: "Are our documents used to train your models? Where do they live? How long? Who can see them?"

Section 7: Pricing Model

What you're actually testing: Is the vendor's pricing aligned with how you actually use document extraction — or does it create perverse incentives?

Document extraction pricing in 2026 spans three orders of magnitude — from $0.01 per page on cloud APIs to $200,000+ annual enterprise contracts. The headline price is rarely the real price. Pricing models differ in ways that can quietly multiply your cost if your usage pattern doesn't match the vendor's assumptions. For a complete picture of the current pricing landscape across all tiers, see our 2026 document extraction pricing analysis.

Questions that surface the real cost:

"Provide the total annual cost for our expected volume of [N] documents per month, broken down by: base subscription or platform fee, per-document processing charges, overage rates above plan limits, per-user or per-seat fees, integration or connector fees, implementation or onboarding costs, and any minimum commitment penalties."
"If we process a document and the extraction fails or requires manual correction, does that document count against our plan limit? Do we pay for failed extractions?"
"If our volume doubles next year, does our per-document cost decrease, stay flat, or increase? Provide the price-at-scale curve for volumes of [current] / [2x] / [5x] documents per month."

Don't ask: "What is your pricing?" You'll get a starting price that excludes most of what you'll actually pay.

Do ask: "Here is our volume. Give us the total line-by-line annual cost. Give us the cost at 2x and 5x our current volume."

The Trap That Sinks Most RFPs: Feature Checklists vs Business Requirements

Every bad RFP shares the same DNA. It reads like this:

Feature	Vendor A	Vendor B	Vendor C
Supports PDF	Yes	Yes	Yes
Supports JPG/PNG	Yes	Yes	Yes
Exports to Excel	Yes	Yes	Yes
Exports to CSV	Yes	Yes	Yes
Batch processing	Yes	Yes	Yes
API access	Yes	Yes	Yes

A checklist like this produces a three-way tie on every row. It's the procurement equivalent of asking car dealerships "do your cars have wheels?" — every answer is yes, and you've learned nothing.

A feature checklist asks "what can your tool do?" A business requirement asks "here's what we need to happen — show us how your tool makes it happen." The distinction isn't semantic. It determines whether your RFP produces a decision or a pile of identical proposals.

For each row in your RFP, apply the "so what" test: if every vendor answers the same way, the question isn't doing its job. Replace it with a question that forces divergence.

Feature Checklist (useless)	Business Requirement (useful)
"Do you support PDF extraction?"	"Our invoices arrive as scanned PDFs at 150 DPI with handwritten notes in the margin. Extract these 3 sample documents and show us the field-level results."
"Do you export to Excel?"	"Our accounting team needs extracted data in an Excel file where each row is one document and each column is one extracted field. The file must be generated without manual formatting. Show us the output from our samples."
"Do you support multi-language documents?"	"We receive invoices in English, German, and Japanese — sometimes within the same supplier relationship. Extract these 2 multi-language samples and show us how non-Latin characters (kanji, umlauts) are handled."
"Is your solution accurate?"	"Report field-level precision and recall on our 10 sample documents. For any field below 90% accuracy, explain the root cause and whether your system can be configured to improve it."

This table is worth printing out and keeping next to your keyboard while you draft. Every time you write a question, ask: will this produce different answers from different vendors? If the answer is no, rewrite it until it will.

Scoring Responses: How to Weight Criteria Without Gaming Yourself

Scoring is where even well-written RFPs go wrong. The most common mistake: weighting every section equally because it feels fair. It isn't fair — it's a refusal to prioritize, and it produces the same indecision a feature checklist does.

Weight your sections based on what will actually determine success or failure in your operation:

RFP Section	Suggested Weight	Adjustment Rule
1. Document Reality (sample extraction results)	30%	Increase to 40% if your documents are highly variable (multiple suppliers, mixed formats, handwriting). This is the make-or-break dimension.
2. Integration Requirements	15%	Increase to 25% if you have a complex tech stack (ERP + CRM + custom database). Decrease to 10% if your team primarily works in spreadsheets.
3. Accuracy Requirements	20%	Increase to 30% for regulated industries or high-stakes documents (contracts, financial reports). This score should be based on actual sample extraction results, not vendor claims.
4. Scalability	10%	Increase to 20% if you're in a growth phase or plan to add document types within 12 months. For stable-volume operations, 10% is sufficient.
5. Operational Requirements	10%	Increase to 20% if your users are non-technical and have high turnover. For teams with dedicated IT support, 10% is adequate.
6. Compliance & Security	10%	Increase to 25% for healthcare (HIPAA), finance (SOC 2, GLBA), or government contractors. For standard commercial operations, 10% is sufficient.
7. Pricing Model	5%	This seems counterintuitive — shouldn't pricing matter more? No. Pricing should be a threshold, not a scoring dimension. Set a budget ceiling before you issue the RFP and eliminate any vendor that exceeds it. Among those that pass, score on capability, not price difference. Saving $200/month on the wrong tool costs far more in manual correction time.

These weights reflect a reality that most procurement processes resist: the vendor that extracts your actual documents most accurately is almost always the right vendor, even if they're not the cheapest or the most feature-complete. Everything else — integrations, compliance, usability — can be worked around. Extraction accuracy is the foundation. If it's wrong, nothing else matters.

What to Do After You Get the Responses Back

You've sent the RFP. You've received the proposals. Now the part most guides skip.

1. Score the sample extraction results first, in isolation. Before reading any marketing prose, open each vendor's extraction output for your 10 sample documents. Count the correct fields. Count the errors. Rank vendors by field-level accuracy. This is your baseline — everything else is commentary on this number.

2. Eliminate any vendor that didn't answer the actual question. If you asked "show us the extracted output for sample #4" and the vendor instead described their extraction engine in three paragraphs, eliminate them. Vague answers to specific questions during the RFP predict vague support during implementation. The RFP is a trial run of the vendor relationship — treat it as one.

3. Shortlist two vendors for a structured trial. Don't make a final decision from an RFP alone. Take the top two scorers and run a one-week trial with your actual team processing your actual documents. The RFP gets you from ten candidates to two. The trial gets you from two to one.

4. Reference-check with companies that have your document profile. Not "any customer reference the vendor provides." Ask specifically for a reference that processes documents similar to yours — same industry, same document types, similar volume. If the vendor can't produce one, that's data.

FAQ

How long should a document extraction RFP be?

5-10 pages of questions, plus your sample document appendix. If you exceed 15 pages, you're asking questions that won't differentiate vendors. The sample documents do more work than ten pages of feature checklist questions ever will.

How many vendors should I send the RFP to?

3 to 5. Fewer than 3 and you lack a real comparison baseline. More than 5 and the evaluation becomes unmanageable — you'll default to surface-level scoring because deep analysis of 7+ proposals takes weeks. Pre-screen vendors before issuing the RFP: if a vendor doesn't support your document types or exceeds your budget, don't include them in the formal process.

Should I include my budget in the RFP?

Yes. Two reasons: first, vendors that are way above your range will self-eliminate, saving you evaluation time. Second, vendors within your range can tailor their proposal to what you can actually afford rather than guessing. The fear that "vendors will charge exactly our budget" is less costly than receiving five proposals that are all 3x what you can spend.

Do I need a different RFP for different document types?

Not necessarily a different RFP, but different sample document sets. The RFP structure stays the same — what changes is Appendix A (the documents). If you're evaluating tools for both invoice processing and contract extraction, include 5 invoice samples and 5 contract samples in the same RFP. Score them separately. A vendor that excels at invoices but struggles with contracts tells you something a blended score would hide.

What if a vendor refuses to extract our sample documents during the RFP phase?

This happens, especially with enterprise vendors who want a signed NDA, a discovery call, and a proof-of-concept agreement before touching real documents. You have two choices: accommodate their process if they're clearly the best fit for other reasons, or eliminate them. Our recommendation: eliminate them. A vendor that can't demonstrate capability on your documents before the contract is a vendor that doesn't want to be evaluated on your documents. The tools that can do the work are usually willing to prove it.

How often should we update our RFP template?

Review and update your RFP questions after every procurement cycle. The questions that didn't produce differentiation, the sections where all vendors scored identically, the criteria that turned out not to matter during implementation — these should be replaced or removed. An RFP is a living document. The template you use for your third tool purchase should be substantially better than the one you used for your first.

Appendix: RFP Template Download

The 7-section structure described in this article is designed to be a starting point — not a fill-in-the-blanks form. Every organization's document reality is different, and the most valuable questions in your RFP will be the ones specific to your operation.

A downloadable RFP template based on this article's framework is in preparation. It will include the full 7-section structure with question templates, the scoring weight calculator, and a sample document preparation guide. Check back or contact us for availability.

In the meantime, here's a self-contained starting point: open a blank document, title it "Document Extraction Software RFP — [Your Company Name]," and create seven section headers matching the structure above. Under each header, write one question about your operation that you currently cannot answer without asking someone else in your company. Those questions — the ones that require internal discussion — are the real RFP. The vendor questions follow from them.

The RFP that produces the best vendor isn't the longest or the most technically detailed. It's the one that was hardest to write — because writing it forced you to understand your own operation before asking anyone else to.

The document extraction tool that fits your operation is almost never the one with the most features. It's the one whose strengths match the specific way your documents are messy, your team is structured, and your downstream systems expect data. An RFP is the tool that finds that match — if you write it to test for fit, not to collect yes/no answers.