Spreadsheet Formula Training Data: Formulas, Dependencies and Errors

This guide is for ML engineers building natural-language-to-formula generation, formula repair or spreadsheet copilot features. It covers what to extract, how to label repairs, which quality signals predict usefulness, and what to put in a request. For whole-workbook licensing, see the owner page on spreadsheet and financial model datasets; this page is about the formula-level deliverable.

Why public spreadsheet benchmarks leave a formula-level gap

Public evaluation coverage for formula-native generation and repair is thin, because a widely cited real-world benchmark scores generated code, not cell formulas. SpreadsheetBench collects 912 instructions from online Excel forums and evaluates solutions as generated programs acting on workbooks [1]. Its authors show that real-world spreadsheet manipulation remains hard for state-of-the-art models [2], but a model that writes good openpyxl code is not necessarily one that writes a correct =SUMIFS(...) into cell F12.

Formula prediction research points to the missing ingredient: context. Google's SpreadsheetCoder work (ICML 2021) treated column headers and the two-dimensional table layout as part of the specification, rather than relying on input-output row examples alone. Training data that strips formulas from their surrounding labels throws away the signal those results depend on.

The older public corpora also skew simple. Research on the Enron corpus (company spreadsheets recovered from the Enron email archive) and the search-engine-gathered EUSES corpus generally describes most files as small and most formulas as short. If your product targets finance, operations or engineering models with nested LET, XLOOKUP, dynamic arrays and cross-sheet chains, you need workbooks from businesses that actually build them. Benchmark design for whole tasks lives on the companion page on spreadsheet task benchmarks built from real workbooks.

What a formula-level extraction record should contain

Each record should capture the formula, its inputs, its labels and its computed result, so a model can learn both syntax and intent. The list below reflects what generation and repair models consume; treat field choices as a starting specification to adjust after a sample.

• Formula text, twice. The A1 string as a user sees it (=SUMIFS(Sales!$D:$D,Sales!$B:$B,$A5)) and the R1C1 form (=SUMIFS(Sales!C4,Sales!C2,RC1)). R1C1 makes relative references position-independent, which is what you deduplicate and cluster on.
• Referenced ranges, resolved. Each precedent as sheet, range, absolute/relative flags and whether it is a named range, a structured table reference (Table1[Amount]) or an external link ([1]Sheet1!A1).
• Header and label context. Column header, row label, sheet name and a bounded window of neighboring cell text. This is the natural-language side of NL-to-formula pairs.
• Computed values. The cached value from the file and, ideally, a recalculated value, so you can detect stale caches and volatile functions (NOW, RAND, OFFSET, INDIRECT).
• Function inventory and depth. Functions used, nesting depth, and whether the cell is an array or spill formula.
• Sheet role. Inputs, assumptions, calculations, outputs or lookup tables. This is a labeled hypothesis, not a file property, so record who assigned it and how.
• Dependency edges. Precedent and dependent cell IDs, so the record can be joined into a workbook-level graph.

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

{
  "record_id": "wb_0412:Summary!F12",
  "workbook_id": "wb_0412",
  "sheet": "Summary",
  "sheet_role": "output",
  "sheet_role_source": "annotator_v2",
  "cell": "F12",
  "formula_a1": "=SUMIFS(Sales!$D:$D,Sales!$B:$B,$A12,Sales!$C:$C,F$3)",
  "formula_r1c1": "=SUMIFS(Sales!C4,Sales!C2,RC1,Sales!C3,R3C)",
  "pattern_hash": "r1c1:9c1f…",
  "fill_copies": 48,
  "functions": ["SUMIFS"],
  "nesting_depth": 1,
  "precedents": [
    {"ref": "Sales!$D:$D", "kind": "range", "abs": "col"},
    {"ref": "$A12", "kind": "cell", "label": "Region"},
    {"ref": "F$3", "kind": "cell", "label": "Quarter"}
  ],
  "context": {"col_header": "Q2 Revenue", "row_label": "REGION_07", "sheet_title": "Revenue by region"},
  "cached_value": 184220.5,
  "recalc_value": 184220.5,
  "hardcoded_constants": 0,
  "cross_sheet": true,
  "deid": {"row_label": "surrogate", "numeric_inputs": "perturbed_consistent"}
}

Getting extraction right from OOXML files

Most extraction errors come from the file format, not the model, so validate the parser against the spec before trusting counts. In an .xlsx package, formulas sit in the <f> element of each xl/worksheets/sheetN.xml and the last calculated result in <v>. Shared formulas are the classic trap: only the anchor cell carries the full text with t="shared", a ref range and an si index, while the other cells carry only the index, so a naive reader undercounts or drops them.

Other details matter for training quality:

• Newer functions carry prefixes. Functions added after the original format are written with _xlfn. (for example _xlfn.XLOOKUP), and some dynamic-array behavior is stored as array formulas. Normalize the prefix for training text but keep it in a raw field.
• Defined names live elsewhere. Named ranges and named LAMBDA functions are in xl/workbook.xml under <definedNames>. Without them, =Revenue*TaxRate is unresolvable.
• Legacy .xls stores parsed tokens. BIFF files keep formulas as token streams, so conversion quality varies by tool. Record the converter and version.
• Cached values can be stale. Files saved with manual calculation, or produced by libraries that never recalculate, carry outdated <v> values. Recalculate headlessly (LibreOffice is a common choice) and flag disagreements rather than silently overwriting.
• External links break. References into other workbooks resolve through xl/externalLinks/. Keep the link target name, which may need de-identification, and mark the record as externally dependent.

How to build formula error-repair pairs

Repair pairs need version history, because a single saved file shows either the broken state or the fixed one, rarely both. Academic work on the Enron corpus has taken this route, matching successive versions of the same spreadsheet so that a later corrected formula serves as evidence of a real earlier error. Enterprise sources with SharePoint, OneDrive or Google Drive version history, or email threads that circulate successive versions, make this matching far more reliable.

A useful repair pair records the error state, the diagnosis and the fix, plus the evidence linking them:

• Error value or symptom. #REF! (deleted precedent), #N/A (lookup miss), #VALUE!, #DIV/0!, #NAME? (misspelled function or missing name), #SPILL! (blocked dynamic array), and silent errors that compute but are wrong, such as an approximate-match VLOOKUP over an unsorted range or a SUM range that stops one row short.
• Circular references. These raise a warning rather than an error value, so detect them from the dependency graph, and record whether iterative calculation was enabled in the workbook.
• Before and after formula, plus the diff type. Range extension, reference re-anchoring (A1 to $A$1), function swap (VLOOKUP to XLOOKUP), argument fix or wrapper (IFERROR). Treat IFERROR wrappers with suspicion: they often hide an error rather than fix it.
• Evidence and confidence. Same workbook ID, same cell or moved cell, time between versions, and whether a human reviewer confirmed the pair.

Edit sequences across many cells, where an agent navigates and changes a workbook over time, are a separate deliverable covered on the page about spreadsheet task trajectories for spreadsheet agents.

Deduplication and the quality signals that predict usefulness

Count unique formula patterns, not cells, because one dragged formula can produce thousands of identical R1C1 records. In the illustrative record above, fill_copies: 48 collapses a column of copies into one training example with a weight. Without this step, a few large lookup tables dominate the mix and the model overfits to VLOOKUP(...,FALSE).

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

For any human-labeled layer, such as natural-language intents written for formulas or sheet-role labels, budget a second-pass audit. Even well-known benchmarks were found to have an average label error rate of at least 3.3% in their test sets [3], and formula intents are more subjective than image classes.

Hold out evaluation workbooks at the workbook level, not the cell level, so the same model logic never appears on both sides. Keep the eval set private: OpenAI stopped reporting SWE-bench Verified because contamination meant gains increasingly reflected training-time exposure [4]. For layouts with several tables per sheet, pair this data with messy multi-table spreadsheets for table detection.

De-identifying values without breaking formula semantics

De-identification for formula data has to preserve types, ranges and lookup keys, or the formulas stop computing the same way. Names, emails, phone numbers and account numbers commonly appear as lookup keys, row labels, sheet names (Acme renewal Q3), comments, external link paths and document properties such as dc:creator and cp:lastModifiedBy in docProps/core.xml. Models can memorize and regurgitate such strings verbatim [5], so they must not survive into training text.

Practical rules:

• Replace keys consistently. The same customer name maps to the same surrogate everywhere, or VLOOKUP and MATCH results change.
• Preserve types and order. Dates stay dates, sorted ranges stay sorted (approximate lookups depend on it), and text that looks numeric stays text.
• Perturb numbers with care. If you scale or jitter inputs, recompute outputs and store both, and keep thresholds referenced by IF logic on the same side.
• Recalculate after de-identification. Any record whose recomputed value changes error state (for example a new #N/A) should be flagged, since it now teaches the wrong repair.

Request template for formula-level data

Describe the formulas and the deliverable, not the companies that hold them. A request in this shape lets any supplier or intermediary assess fit more precisely.

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

Use case: NL-to-formula SFT + formula repair eval for a spreadsheet copilot
Source workbooks: operating finance and FP&A models, US businesses, .xlsx preferred
Formula profile: cross-sheet references, SUMIFS/XLOOKUP/INDEX-MATCH, LET/LAMBDA where present
Unit: unique R1C1 pattern with fill_copies weight; workbook-level grouping kept
Fields: A1 + R1C1 text, resolved precedents, defined names, header/row-label context,
        cached + recalculated values, sheet role (labeled, with labeler ID)
Repair layer: version-matched before/after pairs, error type, diff type, confidence
Eval split: held-out workbooks, never released publicly
De-identification: consistent surrogates for keys, sheet names, comments, doc properties;
        recalc check after replacement; method documented
Volume: <range of unique patterns>; sample of <n> workbooks before full delivery
Allowed uses needed: training + internal evaluation; term and delivery to be agreed

When the target is SQL rather than spreadsheet formulas, the analogous specification is on text-to-SQL training data from real enterprise schemas; grain and history terms generalize from what to specify when licensing tabular data.

Where SourceX fits for formula-level data

SourceX sources operational datasets, including documents and finance workflows, from US companies on request and manages the licensing process; nothing is held in stock and a request does not guarantee a match. Buyers describe the formula data they need, and SourceX looks for US businesses that hold it. Every release is approved by the supplying company, rights-reviewed for ownership and consents, and delivered under a license defining records, uses, term and delivery.

Personal details such as names, emails, phone numbers and account numbers are removed or replaced before delivery, the method is recorded and a sample is checked, though no method is perfect. Diligence materials covering source, rights, preparation and allowed use are prepared per dataset. Background on why these files matter is in what makes spreadsheets and financial models valuable for AI, licensing terms for complete workbooks are on license spreadsheets and financial models for AI training, and the broader cluster map is the tabular, time-series and transactional data buyer's guide.

Request a spreadsheet formula dataset

If you need formulas with context, dependency graphs or version-matched repair pairs from real business workbooks, describe the data and intended uses, and SourceX assesses data and licensing permissions with suppliers before anything is agreed. Pricing and allowed uses are set per deal in a license, and delivery runs through private, access-controlled workflows after an executed agreement. Start a buyer request.