Table and spreadsheet retrieval data for RAG

Why table retrieval needs its own test data

Table retrieval needs dedicated data because the errors that break tabular RAG rarely show up in prose-only benchmarks. Enterprise RAG benchmarks already include financial reports among corporate documents [1], and financial reports are a table-heavy document type. In FinanceBench, a retrieval-augmented configuration failed or refused 81% of a 150-case sample of questions over company filings, which points to retrieval over table-heavy documents as a weak link [2].

The failure modes are specific. A chunker splits a balance sheet across two chunks and strands the header row, so the numbers lose their column meaning. An embedding model matches "Q3 operating expenses" to a narrative paragraph instead of the table that holds the figure. A workbook with twelve monthly tabs returns the March sheet when the user asked about May, because the tabs share nearly identical text.

Reading comprehension over tables is a separate problem. FinQA pairs expert-written questions over financial reports with gold reasoning programs, so you can check arithmetic step by step [3]. It does not tell you whether your retriever found the right table among thousands, which is why the corpus and the relevance labels matter as much as the questions.

What a usable table retrieval corpus contains

A usable corpus ships the tables in their native containers, the questions, and labels that point to an exact location. For spreadsheets that means the original .xlsx or .xlsm files, not CSV exports, because sheet names, merged headers, named ranges, hidden tabs and comments are retrieval signals that a flat export destroys.

Ask for these components:

• Native files: .xlsx workbooks, PDF or HTML reports with embedded tables, and any database extracts, each with a stable doc_id and version.
• Table-level metadata: file name, sheet name, table caption or title row, header rows, units and currency, reporting period and the A1-style cell range of each table. See metadata a licensed RAG corpus should ship with for the general field list.
• Questions: written or harvested from real usage, typed as lookup, aggregation, comparison across periods, or cross-table join.
• Gold labels: one or more gold tables per question, the cell range that holds the evidence, and the final answer with its unit.
• Distractors: prior versions, drafts and sibling tabs that look similar but give the wrong answer. Our guide to superseded versions and near-duplicates covers how to label them.
• Unanswerable items: questions whose answer is not in any table, to test abstention, as described in unanswerable questions in RAG evaluation.

Table detection is its own preprocessing step. TableSense showed that finding table regions inside spreadsheets is a nontrivial detection task [7], and SpreadsheetLLM argues that spreadsheets need specialized encoding before language models can use them well [8]. If your pipeline detects tables automatically, the gold labels should still be expressed as cell ranges in the original sheet, so you can score your detector and your retriever against the same ground truth. For detection-focused data, see messy multi-table spreadsheets for table detection.

Labeling: score retrieval and answering separately

Separate scoring works when every question carries both a retrieval target and an answer target. Retrieval metrics such as recall@k and MRR are computed against the gold table IDs, while answer accuracy is computed against the value and unit. Without the split, a correct answer pulled from a lucky narrative mention hides a retriever that never found the table.

Three granularities are worth labeling, from coarse to fine:

1. File or sheet: did the retriever return the right workbook and tab?
2. Table region: did it return the right table among several on that tab?
3. Cell range: did the evidence passed to the generator include the cells that hold the answer?

Relevance labels can often be derived from artifacts the supplier already has. The SQL-Schema-Retrieval dataset recasts text-to-SQL data as a retrieval task by reading table and column references out of gold SQL queries [4]. In an enterprise setting, the same idea applies to saved queries, BI dashboard definitions, report formulas that reference other sheets, and analyst tickets that cite a specific workbook. Those references give you relevance judgments grounded in real work rather than annotator guesses.

For human or model-assisted labeling options, see buying relevance judgments (qrels).

Record schema for a table retrieval test item

A test item should be a single self-contained record that links a question to its gold evidence and its distractors. JSON Lines works well for this: UTF-8, one valid JSON object per line, easy to stream and diff [10].

Illustrative example: invented to show structure; it does not describe an available dataset.

{"qid": "q-00417",
 "question": "What was total freight cost for the Midwest region in May, in USD?",
 "question_type": "lookup",
 "gold": [{"doc_id": "wb-ops-2025-v3", "sheet": "May", "table_id": "t2",
           "range": "B4:H19", "evidence_cells": ["F12"]}],
 "answer": {"value": 48210.55, "unit": "USD", "period": "2025-05"},
 "hard_negatives": [{"doc_id": "wb-ops-2025-v2", "sheet": "May", "reason": "superseded version"},
                    {"doc_id": "wb-ops-2025-v3", "sheet": "Apr", "reason": "sibling tab"}],
 "answerable": true,
 "source_split": "test",
 "pii_treatment": "carrier contact names replaced with tokens"}

Describe the dataset itself with a machine-readable card. Croissant, a schema.org-based JSON-LD vocabulary, can describe the files, the record structure and the fields above, which makes the corpus easier to load and audit across tools [9].

Public benchmarks versus licensed enterprise workbooks

Public benchmarks are a good baseline but rarely match the workbooks a finance or operations assistant will face. Filings-based sets such as FinanceBench and FinQA give you clean, published financial tables [2][3]. Text-to-SQL benchmarks bring database realism: Spider 2.0 contains 632 problems over databases drawn from real applications [5], and BIRD stresses dirty values and the need for external knowledge [6]. If your task is finding the right tables and columns in a warehouse, see schema linking and schema retrieval data, which is a different problem from finding a sheet in a document store.

Illustrative example: invented to show structure; it does not describe an available dataset.

Before reusing public sets in a product, check their terms; our guide to public retrieval datasets that allow commercial use walks through the common licenses.

Sourcing questions to ask a supplier of spreadsheets

The supplier questions that matter most concern provenance, structure and what was removed. Use this checklist before you commit to a pilot.

Illustrative example: invented to show structure; it does not describe an available dataset.

De-identification deserves special care with tables. Replacing a customer name in a header can break the join a question depends on, and rounding figures breaks exact-match scoring. Our guide to de-identifying a RAG corpus without breaking retrieval covers consistent tokenization. For licensing clauses specific to retrieval use, see RAG content license terms.

How SourceX approaches table and spreadsheet requests

SourceX sources operational datasets from US companies and manages the commercial process, including licensing and ongoing purchases. Relevant categories include finance and legal workflows, documents, and support and sales histories, but they are sourced on request rather than held in stock, and a request does not guarantee a match.

You describe the tables and questions you need; SourceX looks for US businesses that hold them, and every release is approved by the supplying company. Datasets are rights-reviewed for ownership and consents and delivered under a license defining records, uses, term and delivery. Personal details such as names, emails, phones and account numbers are removed or replaced before delivery, the method is recorded and a sample is checked, though no method is perfect.

If you want to start a request, describe your table retrieval needs on the buyers page. For training rather than retrieval testing, see the owner pages on licensing spreadsheets and financial models and spreadsheet and financial model datasets, and the broader RAG content licensing guide.

Source table and spreadsheet retrieval data

SourceX sources datasets on request from US companies, with rights review, recorded de-identification and a license that defines records, uses, term and delivery. Nothing is contracted until a supplier agrees. Describe the tables, questions and labels you need at https://sourcex.si/buyers.