What Is a Nested Table: A Simple Guide for 2026

A nested table is a table placed inside the cell of another table, used to show one-to-many relationships within a single parent record. In Oracle, a nested table can store an unspecified number of rows in one column, and it's designed for cases where the number of elements isn't known in advance.

A finance team sees this shape all the time in invoices, KYC forms, delivery notes, and PDFs with sub-sections under a parent record. The problem is that OCR and document automation tools don't always read the parent-child structure correctly, so the data comes out flattened, misaligned, or incomplete.

Understanding What a Nested Table Really Is

A nested table shows up when one record needs its own inner list. An invoice might have a main header row, then line items inside a grouped cell. A KYC form might have an address block with its own itemized details. The outer table holds the parent record, and the inner table holds the child records.

In plain language, a nested table is a table inside another table. That inner table is not decoration. It exists to keep related details together under one parent, so a reader can see the relationship at a glance. In database systems, Oracle documents nested tables as a collection with no declared element count, and Microsoft describes a related parent-child model in Analysis Services where child rows connect back to a parent case through a defined relationship. Those ideas are the same shape, even if the platform differs.

The key thing to notice is the structure. There's an outer table, a cell that contains another table, and an implied relationship between the parent and its children. That relationship matters because downstream systems need to know which sub-rows belong to which parent row. If that link gets lost, the data may still be readable, but it won't be trustworthy.

Practical rule: if a row contains its own repeated sub-rows, you're looking at a nested structure, even when the source file doesn't label it that way.

A good mental model is simple. The parent tells you what the record is. The nested table tells you what belongs to it. That's why nested tables matter so much in document extraction, and why they show up in both layout design and formal data structures. For a broader view of how that fits into document workflows, see intelligent document processing basics.

How Nested Tables Appear in HTML, Word, PDFs, and Spreadsheets

A finance analyst opens an invoice packet, a Word form, and a scanned PDF, and each one seems to show the same thing: a table inside a table. The challenge is that the shape is similar, but the document artifact behind it is different. HTML exposes structure directly, Word often hides it inside layout choices, PDF may preserve the look without preserving the relationships, and spreadsheets often simulate nesting with grouped rows or stacked sections.

HTML and Word

HTML is the clearest case because the nesting is part of the markup. A <table> appears inside a <td>, so developers can parse parent rows and child rows as separate objects while still keeping the hierarchy intact. The part that still needs care is the mapping, because extraction has to preserve which child values belong to which parent record, especially when the inner table holds repeated line items or attributes. If you are checking the raw text before you design that mapping, an OCR text extraction tool can help you see what is present on the page.

Word is harder because users build tables for layout as much as for data. A form can look flat to the eye and still contain nested structure inside one or more cells, or it can look nested because of indentation and spacing even when the document object model is not nested. That mismatch is a common source of confusion during extraction. A practical reference for table extraction from PDF also helps here, because Word files that are exported to PDF often keep the visual shape while losing a clean structural signal.

PDF and spreadsheets

PDFs are where the visual layout can be most misleading. A person can see the parent block, the child block, and the indentation that suggests hierarchy, but the file itself may only provide fragments of text and page geometry. OCR then has to infer cell boundaries, decide which text belongs together, and rebuild the table without mixing the levels.

Spreadsheets create a different kind of confusion. They do not always contain true nested tables, but grouped headers, subtotal rows, merged labels, and stacked sections can behave like one. The human reader sees a clear parent-child pattern. The extraction engine has to decide whether those rows form one record, several records, or a mix of both.

Nested tables show up so often because real documents are designed for people first, not parsers.

For teams building JSON mappings, the key is to keep the hierarchy explicit instead of flattening everything into one row list. If the source structure and the output schema do not line up, child rows drift away from their parent records, and the result looks complete while still being wrong. Guidance on schema validation helps define the expected shape before extraction runs.

Why Nested Tables Break OCR and IDP Pipelines

Nested tables break extraction because they confuse the engine's idea of where one record ends and another begins. OCR can read text, but it doesn't always understand that a block inside a cell belongs to the parent row above it. When that happens, the system may split one child table across multiple outputs, or attach a sub-row to the wrong parent.

The first failure mode is bounding-box overlap. The OCR engine sees text areas that physically sit close together, so it draws boxes that collide or merge. The second is row fragmentation, where a child table gets treated like several loose lines instead of one structured unit. The third is lost parent-child context, which is the business problem, because the extracted values no longer tell you which parent record they came from.

What that means in operations

A finance team ends up reconciling invoice lines by hand. A compliance team has to check whether a KYC sub-field belongs to the right identity record. A logistics team sees shipment details detached from the correct bill of lading. The file may have been “read,” but the data still isn't ready for an ERP, CRM, or audit trail.

If the extraction engine can't preserve hierarchy, you don't really have structured data. You have text with confidence scores.

This is also why nested tables are so often the hidden cause of manual work. The source document looks valid, the OCR output looks complete, and yet the downstream team still has to repair it. That extra review step is where cost piles up. For a useful look at how enrichment depends on clean structure, see data enrichment types and advantages.

Extraction Strategies and JSON Mappings That Work

There are three practical ways to handle a nested table in an extraction pipeline. The right choice depends on whether your downstream system needs speed, structure, or traceability.

A finance lead usually feels the trade-off first. A flat export is quick to review, but the child rows stop carrying their parent context. A hierarchical export keeps the relationship intact, but it can be harder to query if the next system only understands columns. A split-and-rejoin flow sits between those two, since it separates capture from reconstruction.

1. Flatten the data

Flattening turns every child row into a separate output row with duplicated parent fields. It is fast and easy to query. The trade-off is that you lose the original hierarchy, so you may not know which child rows belonged to which parent block if the document has multiple nested sections.

2. Preserve the hierarchy

A recursive JSON structure keeps the parent object and its child array together. This is the cleanest shape when the source document is hierarchical. It is also the easiest way to keep repeated sub-sections intact, especially when a parent record can contain several child records.

3. Split and rejoin by key

Some pipelines extract the parent table and child table separately, then join them later with a stable key. This is often the most reliable production pattern because it makes validation easier. The downside is that it depends on the document carrying a trustworthy relationship key, or on your pipeline generating one consistently.

A simple JSON mapping for a nested document usually looks like this:

{
  "parent_id": "INV-1042",
  "customer_name": "Northwind",
  "billing_period": "2026-01",
  "children": [
    {
      "item": "Consulting",
      "quantity": 2,
      "amount": "1200.00"
    },
    {
      "item": "Support",
      "quantity": 1,
      "amount": "300.00"
    }
  ]
}

That shape keeps the parent visible and the child rows grouped. It also fits systems that expect nested arrays rather than flat columns, which is often where document pipelines start to break if the mapping is too simple. Schema rules matter here, because they keep field names, types, and nesting from drifting as documents vary. For a closer look at that layer, see schema validation design.

Good mapping rule: preserve the source hierarchy in JSON unless a downstream system requires flattening.

Design the JSON around the document structure first, before extraction starts failing. If the mapping matches the way the source page is built, the parent-child relationship survives OCR noise, partial reads, and repeated sub-sections much better.

Real Document Examples Across Common Use Cases

An electricity bill with consumption sub-tables is a classic nested-table case. The parent section holds customer and contract details. The child section holds usage lines, tariff breakdowns, or CUPS-related fields. The best fit is usually hierarchical JSON, because the bill's structure matters as much as the values themselves. That keeps the usage rows attached to the correct account and billing period.

A delivery note often has a header block with SKU and quantity rows nested underneath. The problem is that a flat extractor may separate the header from the item lines. The solution is to split the document into parent and child sections, then rejoin them by a stable key or inherited identifier. The result is cleaner reconciliation in logistics and fewer mismatches in inventory systems.

A payslip can contain itemized deductions inside a summary block. If the engine flattens those rows too aggressively, payroll teams lose traceability. A recursive structure works better here, because each deduction stays under the right pay period and employee record. The output is easier to audit, especially when the document contains several grouped components.

Bill of Lading files usually mix shipment metadata with container-level details. The parent row identifies the shipment, while the child rows describe containers, seals, or package counts. The safest extraction pattern is the one that preserves the relationship between shipment-level and container-level data. That gives operations teams a record they can match to freight workflows without rebuilding it manually.

KYC identity documents can be just as tricky. An address block may contain sub-fields or repeated identity attributes that behave like a nested table even when the layout looks compact. For compliance teams, the issue isn't just readability. It's whether every child field lands under the right identity record, with enough traceability to support review.

Best Practices and Troubleshooting Tips

A nested table is easiest to handle when the pipeline respects the document before it tries to normalize it. Start by classifying the document type first, then extract, because mixed document sets often need different parsing logic. Split multi-page PDFs before extraction when table boundaries run across pages, and detect nested regions programmatically instead of hoping the OCR engine guesses correctly.

Checklist for stable output

• Pre-process early: Split multi-page documents before the extractor runs.
• Classify first: Route invoices, payslips, KYC files, and logistics docs into the right model path.
• Detect nested regions: Use layout-aware detection for cells that contain sub-tables.
• Define keys clearly: Keep parent and child relationships explicit in your schema.
• Validate against source layout: Check totals, repeated headers, and orphaned child rows before export.

Missing line items usually point to bounding-box overlap, not bad OCR alone. Duplicated headers often mean the engine treated the nested table as a new document. Orphaned child rows usually mean the join logic broke, or the parent key wasn't preserved.

When the output looks almost right, the problem is often structure, not text quality.

That's why troubleshooting should focus on hierarchy first. If the extracted values look readable but the relationships feel off, the issue usually sits in classification, region detection, or schema design. For teams building review logic, that's the point where automation needs a validation layer, not just a better text reader.

How Matil.ai Handles Nested Tables End to End

Matil.ai handles nested tables as a structured extraction problem, not just an OCR problem. Its workflow combines OCR, classification, validation, and automation in one pipeline, so the engine can detect document type, identify nested regions, and return structured output instead of a loose text dump. That matters for bills, delivery notes, payslips, ID documents, Bills of Lading, and customs declarations, where parent-child context has to stay intact.

Nested-Table Challenge	Result Without the Right Tool	How Matil.ai Handles It
Child rows lose parent context	Manual rework and inconsistent exports	Keeps parent and child data in one structured flow
Nested regions are hard to detect	Fragmented rows and missing fields	Uses OCR plus classification to identify layout more cleanly
Validation fails late	Errors show up after export	Applies validation before the data leaves the pipeline

The platform also supports flexible structure definition, so teams can model parent fields and child arrays without long training cycles. That's useful when the document pattern changes across vendors or countries. Matil.ai also offers pre-trained models for common document types, plus a simple API for teams that want to embed extraction into existing systems. Its security posture includes GDPR, ISO 27001, SOC, and zero data retention, which matters for finance, operations, legal, and compliance workflows.

If nested tables are blocking your extraction pipeline, treat them as a structure problem first and an OCR problem second. Matil.ai gives teams a way to process those documents without custom parsing for every new layout, while keeping the JSON output consistent enough for downstream automation.

---

If you're evaluating how to automate nested-table extraction in invoices, KYC files, logistics documents, or payslips, visit Matil and review how its API handles classification, validation, and structured output in one workflow. It's a practical next step if your team needs document extraction that keeps parent-child relationships intact instead of flattening them away.