The real shape of enterprise data
If you have ever asked an enterprise client to send you their data, you know what arrives. Not a clean CSV with one header row and uniform columns. Instead, you get an Excel workbook with 12 sheets, each containing multiple tables stacked vertically, separated by blank rows, preceded by title blocks, and followed by summary totals. Some sheets have tables arranged side by side. Some have merged header cells spanning three columns. Some have a company logo embedded in cell A1.
This is not messy data. This is how large organizations actually structure their reporting. Finance teams build workbooks where each sheet represents a cost center, with separate tables for headcount, expenses, and budget allocations on the same sheet. HR teams export workbooks where Sheet 1 has employee demographics, Sheet 2 has compensation tables stacked by department, and Sheet 3 has benefits elections in a completely different layout. ERP exports from SAP, Oracle, and Workday follow internal formatting conventions that made sense to the person who built the template five years ago.
Most data import tools assume one file equals one table. They read the first sheet, treat row 1 as the header, and parse everything below as data. When they encounter a multi-sheet workbook with multiple tables per sheet, they either fail silently (importing only the first table from the first sheet) or require the client to manually split each table into a separate file before uploading. Neither outcome is acceptable when your product needs to process these files at scale. This is a core challenge in file ingestion that most generic tools ignore entirely.
Why multi-table detection is harder than it looks
Detecting table boundaries inside a spreadsheet seems straightforward in theory. Find the blank rows, split on them, treat each section as a table. In practice, it is a much harder problem because real workbooks do not follow consistent rules.
- Tables are not always separated by blank rows. Sometimes a title row sits directly above the next table with no gap. Sometimes two tables are placed side by side with only a blank column between them.
- Title rows look like data. A row containing 'Q1 2024 Revenue by Region' in a merged cell is not a data row, but a naive parser cannot distinguish it from a single-column data row.
- Summary rows sit below tables. A 'Total' or 'Average' row at the bottom of a table is not part of the data, but it shares the same column structure as the data rows above it.
- Merged cells break column alignment. When a header spans three columns via a merge, the actual sub-headers are in the row below. A flat row-by-row parser misses this hierarchy entirely.
- Mixed content on the same sheet. Charts, text annotations, instructions, and logos can appear anywhere on the sheet, interleaved with actual data tables.
A common failure: your parser reads a workbook, grabs the first sheet, and imports 2,000 rows. But 300 of those rows are actually from a second table with different columns that was stacked below the first. The data maps to the wrong fields, validation passes because the types happen to match, and corrupted records end up in production. You find out when a customer reports that their Q1 numbers include Q2 budget projections.
How FileFeed handles multi-sheet Excel workbooks
FileFeed treats multi-sheet, multi-table Excel workbooks as a first-class input format. Instead of forcing clients to restructure their files, FileFeed adapts to the structure the client already uses. The processing pipeline has four stages: sheet enumeration, table detection, mapping, and validation with human review.
Stage 1: Sheet enumeration and preview
When a workbook is uploaded, FileFeed reads every sheet and presents them in a selection interface. Users see each sheet name, a preview of its contents, and the number of detected tables per sheet. They can select which sheets to process and which to skip. Sheet names are preserved as metadata throughout the pipeline, so downstream systems always know where each record originated.
For automated SFTP pipelines, sheet selection is configured once during pipeline setup. When recurring files arrive, FileFeed automatically processes the configured sheets without manual intervention. If a new sheet appears that was not in the original configuration, FileFeed flags it for review rather than silently ignoring it.
Stage 2: Automatic table boundary detection
For each selected sheet, FileFeed scans the cell grid to identify distinct table regions. The detection algorithm analyzes multiple signals simultaneously:
- Contiguous data regions. FileFeed identifies rectangular blocks of non-empty cells, treating significant gaps (blank rows or columns) as boundaries between tables.
- Header row identification. Within each detected region, FileFeed looks for rows where the values function as column labels: text-heavy cells with distinct values that differ in pattern from the data rows below.
- Title and summary row filtering. Rows above a detected header (title rows) and rows below the last data row with aggregation patterns (totals, averages, counts) are tagged separately and excluded from the data extraction.
- Merged cell resolution. When merged cells span columns, FileFeed resolves the merge into a multi-level header hierarchy. A top-level merge saying '2024' spanning three columns with sub-headers 'Q1', 'Q2', 'Q3' becomes three fields: 2024_Q1, 2024_Q2, 2024_Q3.
- Side-by-side table detection. When two tables sit next to each other on the same sheet separated by a blank column, FileFeed detects them as separate tables rather than treating the combined region as one wide table with sparse data.
After detection, the user sees each table extracted with its boundaries highlighted. They can adjust boundaries manually if the automatic detection missed an edge case, split a detected table into two, or merge two detected regions into one. This combination of automatic detection with manual override gives teams confidence that every table is correctly isolated before mapping begins.
Stage 3: Per-table semantic mapping
Each detected table is mapped independently to a target schema. This is critical because different tables on the same sheet often have completely different structures. A sheet might contain a headcount table with columns like Name, Department, Start Date alongside a compensation table with columns like Employee ID, Base Salary, Bonus Target, Equity Grant.
FileFeed's AI-powered mapping engine analyzes each table's headers and sample data to suggest the best target schema match and field-level mappings. The mapping considers:
- Header similarity. Column names are compared against all available target schemas using semantic matching, not just exact string comparison. 'Emp ID', 'Employee Number', 'Worker ID', and 'Personnel No.' all map to the same target field.
- Data pattern analysis. The actual values in each column inform the mapping. A column of values like 'john@acme.com' maps to an email field regardless of what the header says.
- Schema affinity scoring. Each detected table is scored against every available target schema. If you have schemas for 'employees', 'departments', and 'compensation', a table with columns Name, Email, Department, Start Date scores highest against the employees schema.
- Cross-table relationship detection. When tables on the same sheet or across sheets share a common column (like Employee ID), FileFeed identifies the relationship and flags it for users who need referential integrity checks.
Mapping memory persists across pipeline runs. If a client sends the same workbook structure every month, the mapping from the first run is automatically applied to subsequent runs. The user only reviews and confirms. Over time, recurring workbooks process with zero manual mapping.
Stage 4: Validation, auto-fix, and human review
After mapping, every extracted table passes through FileFeed's validation engine. Validation rules are applied per-table, which means different tables can have different rules even if they came from the same sheet. The validation pipeline runs in this order:
- Type validation. Every value is checked against the expected type for its mapped field. Dates must be valid dates. Numbers must be numeric. Emails must match email format. Values that fail type validation are flagged with a specific error message.
- Business rule validation. Custom rules that span multiple fields or enforce domain-specific logic. For example: if status is 'Active', then end_date must be empty. If country is 'US', then state must be a valid US state code.
- Cross-table validation. When tables have declared relationships, FileFeed checks referential integrity. Every department_id in the employees table must exist in the departments table. Missing references are flagged before delivery.
- Auto-fix suggestions. For common data quality issues, FileFeed suggests corrections automatically. Phone numbers with inconsistent formatting are normalized. Dates in ambiguous formats (01/02/2024) are flagged with a suggested interpretation. Leading and trailing whitespace is trimmed. Values that are close to an expected enum value ('Actvie' for 'Active') are flagged with a spelling correction suggestion.
- Human review. All tables, their validation results, and any auto-fix suggestions are presented in a review interface. Reviewers see the original value, the suggested fix, and the validation error side by side. They can accept fixes individually or in bulk, edit values manually, delete invalid rows, or reject entire tables and request a resubmission from the source.
The review interface tracks every change. When a reviewer accepts an auto-fix or edits a value manually, the action is logged with a timestamp and user identity. This audit trail is critical for teams in regulated industries where data provenance matters.
Automated pipelines vs. embedded importer
FileFeed supports multi-sheet Excel processing through both product paths. The right choice depends on who uploads the file and how often.
For recurring workbooks that arrive via SFTP on a schedule. Configure the pipeline once: which sheets to process, how to detect tables, which schemas to map to. Every subsequent file is processed automatically with results delivered to your webhook. Human review is optional and triggered only when anomalies are detected.
For workbooks uploaded manually by your users inside your application. The React component guides users through sheet selection, table review, mapping confirmation, and data validation. Every step includes a human-in-the-loop checkpoint. Ideal when the file structure varies or when user confirmation is required before processing.
Both paths share the same detection, mapping, and validation engine. A workbook that starts being uploaded manually through the embeddable importer can later be moved to a fully automated SFTP pipeline once the mapping is stable. The transition requires no re-engineering.
What this solves for engineering teams
Without multi-table detection, engineering teams end up writing custom parsing scripts for every client's workbook format. Each script is a one-off that reads specific sheets, extracts tables from hardcoded row ranges, and maps columns by position rather than semantics. When the client changes their template (and they always do), the script breaks and an engineer has to debug it. This is the same pattern that causes data onboarding churn across the industry.
FileFeed replaces this entire class of custom work. The table detection is format-aware, not position-dependent. The mapping is semantic, not index-based. The validation is configurable, not hardcoded. And the human review step means that edge cases are caught by people before they become production incidents.
If your product ingests data from enterprise clients who send multi-sheet Excel workbooks, you have two options: build and maintain custom parsing infrastructure for every format variation, or let FileFeed handle the complexity so your team can focus on building the product your customers actually pay for.
Key Takeaways
- FileFeed reads all sheets in a workbook and lets users select which to process, with automatic detection for recurring pipelines.
- Table boundary detection identifies multiple tables per sheet, handling title rows, summary rows, merged cells, and side-by-side layouts.
- Each detected table is mapped independently using AI-powered semantic matching against your target schemas.
- Validation runs per-table with auto-fix suggestions for common data quality issues like formatting, spelling, and type mismatches.
- Human-in-the-loop review gives teams confidence before data enters production, with a full audit trail of every change.
- Works through both the embeddable React importer and automated SFTP pipelines, with the same engine powering both.
Related resources
