Excel and CSV in n8n: read, generate, and automate reports with Extract from File

A client asks for their order history "in Excel," an accountant wants a monthly invoice export, a support team wants the list of open tickets in a file they can sort themselves: the spreadsheet format remains, in 2026, the common language of business data — far more than JSON or even PDF. Automating how you read and generate spreadsheets in n8n is therefore a recurring building block, but one whose shape has changed recently. This guide covers the two current nodes, two concrete use cases, and the pitfalls that cost time the first time you hit them.

Extract from File and Convert to File: the successors to Spreadsheet File

Up through version 1.21.0, n8n offered a single node, Spreadsheet File, to read and write spreadsheets. It's now deprecated: workflows that still use it keep running, but n8n no longer develops it further. It was replaced by two specialized nodes, more consistent with the rest of n8n's file-handling ecosystem:

• Extract from File (n8n-nodes-base.extractFromFile) — reads an incoming binary file and extracts structured data from it. The relevant operations here are Extract From CSV, Extract From XLS, and Extract From XLSX (the node also handles JSON, ICS, or plain text for other formats). The key parameter is Input Binary Field ("data" by default), which tells the node which binary property on the input item holds the file to read, plus a Header Row toggle to indicate whether the first row contains column headers.
• Convert to File (n8n-nodes-base.convertToFile) — does the opposite: it turns JSON data into a binary file, via the Convert to CSV, Convert to XLS, and Convert to XLSX operations. Here you set the output field (Put Output File in Field), a file name, the Header Row toggle, and — for Excel formats only — a Sheet Name and a compression option for XLSX.

Splitting read and write into two distinct nodes, rather than a single dual-purpose node, fits better with the rest of n8n's logic (like Extract from File / Convert to File for PDFs, covered in our invoice extraction guide) and makes a workflow easier to read at a glance: you immediately see whether a step reads or produces a file.

Use case 1: reading an Excel file received by email

A common scenario: a vendor or client sends an XLSX file as an email attachment, and you need to extract its rows to feed elsewhere (a database, a CRM, a billing tool). In a workflow close to the ones in the Inbox AI Pack (€79), an IMAP Trigger or Gmail Trigger node fetches the email with its binary attachment, which an Extract from File node (Extract From XLSX operation) turns directly into an array of JSON objects, one per spreadsheet row.

Three settings worth getting right:

1. Enable Header Row if the first row holds the column names — otherwise the generated keys are numeric (0, 1, 2…) and you have to rename them by hand in a downstream Set node.
2. Check types after extraction: a column that's sometimes text, sometimes numbers in the source file comes out inconsistent on the n8n side. A lightweight Code node that forces the expected type (Number(), String().trim()) before inserting into a database avoids silent surprises.
3. Where to store the extracted rows: for a modest volume with a deduplication need (not re-importing the same file twice), an n8n Data Table is more than enough; for larger volumes or joins, Supabase is the way to go.

The multi-tab workbook pitfall

The point that catches out most people moving to Extract from File: the node only reads the first sheet in the workbook, with no built-in option to pick a different one or loop through all of them. A budget-tracking file with one tab per month, or an accounting export with a "Detail" tab and a "Summary" tab, only surfaces the first sheet — often not the one you want.

The fix goes through a JavaScript Code node: n8n ships the xlsx library in its execution context, which lets you parse the file's binary buffer yourself, iterate over workbook.SheetNames, and return one item per sheet (or merge the relevant sheets as needed). It's more code than a simple node drag-and-drop, but it's the only reliable option as long as Extract from File stays limited to the first sheet — a behavior worth checking systematically before shipping a workflow to production with Excel files whose structure isn't guaranteed.

Use case 2: generating an Excel report automatically

Conversely, generating a spreadsheet on the fly is useful whenever a recipient expects a workable table rather than an HTML email. Our guide on AI-generated audit summary reports builds an HTML report sent by email — a good option for a quick read in a leadership meeting, but an accountant or an external auditor often prefers receiving the same data as an XLSX file they can filter and recalculate themselves. The same workflow can, alongside the HTML email, add a Convert to File node (Convert to XLSX operation) right before sending: it turns the aggregated non-compliance table into an Excel attachment, with an explicit tab name ("Audit summary — July 2026," for instance) and compression enabled to keep the file size down.

This pattern applies directly to the workflows in the Compliance & Audit Pack (€149), where every generated report can exist both as HTML for a quick read and as XLSX for archiving or sharing with a third party who doesn't have access to the tool.

CSV or Excel: which one to pick

Need	CSV	XLSX
Exchange between two automated systems	✅ Lightest, most universal format	Works, but overkill
File opened and edited by a human in Excel	⚠️ Risk of garbled accents (no UTF-8 BOM)	✅ Formatting, several differently-typed columns, no encoding worries
Several sheets in one file	❌ A CSV holds only one table	✅ Configurable sheet name in Convert to File
Large file, tens of thousands of rows	✅ Faster to process, lighter file	Works, but heavier to open

The practical rule: CSV for what stays inside an automated pipeline (import into another tool, exchange between workflows), XLSX as soon as a human needs to open the file directly in Excel or Google Sheets without any prior manipulation.

Why structured extraction beats hardening manual entry

Automating how you read a spreadsheet avoids a well-documented class of errors in the academic literature on spreadsheets. A landmark review by Powell, Baker, and Lawson (A Critical Review of the Literature on Spreadsheet Errors, Decision Support Systems, 2008 — see it on Google Scholar) points out that manual entry errors and formula errors in operational spreadsheets are not only common, but propagate silently from one version of the file to the next, with no built-in detection mechanism. An n8n pipeline that reads an XLSX with type-checking at every step, rather than manually re-keying the same data into another tool, mechanically eliminates that class of error — without removing the need to validate the data at the source.

Going further

Extract from File and Convert to File cover most Excel/CSV needs in an n8n workflow: reading files received by email, generating reports for external recipients, exchanging data between systems. The one blind spot worth knowing about upfront is the first-sheet-only limitation on reads, which requires a Code node for multi-tab workbooks. And if your inbound files are PDFs rather than spreadsheets, the same Extract from File node is the starting point of a RAG over your PDF documents. The FlowKit packs already combine these nodes with Supabase and AI to turn raw files into usable data — from the email attachment in the Inbox AI Pack (€79) to the exportable audit report in the Compliance & Audit Pack (€149).