Table & List Field Processing
Intelligently fill tables and repeating fields in PDF forms from structured and unstructured data
Overview
Many forms contain tables or lists for entering multiple items: CMS-1500 service lines, Schedule D capital gains transactions, I-485 employment history entries, medication lists, or expense report line items. Manually filling these tables from existing records is time-consuming and prone to transcription errors, particularly when the source data already exists in a spreadsheet, database, or prior document.
Table & List Field Processing detects table structures inside a PDF form, extracts the corresponding row data from your sources, and fills each table cell. Two separate AI models handle different source types: one extracts row-structured data from sources that have a clear tabular organization, while another handles sources where the relevant data appears as a list or enumeration rather than a formatted table.
Table cells within a form are detected and grouped geometrically by clustering form fields by their Y-position on the page. Fields that share the same horizontal band are treated as columns of the same row. This geometric grouping is what allows the system to identify table rows without relying on explicit markup in the PDF.
Each table row tracks its ID, field values, form version, PDF reference, processing state, and status. Rows are processed in parallel, with each row's processing context fully isolated to prevent data from one row contaminating another's output or cost tracking.
Key Capabilities
- Automatic Table Detection: Form fields are grouped by Y-position to identify table rows without requiring explicit PDF table markup
- Dual Extraction Models: One AI model for structured table sources; another for list-format sources where data appears as enumeration or narrative
- Row State Tracking: Each row tracks its ID, values, form version, PDF reference, processing state, and status
- Parallel Row Processing: Rows are filled concurrently; per-row isolation prevents cross-row data contamination
- Multi-Source Extraction: Pull table data from CSV, Excel, uploaded documents, or profile data
- Variable-Length Tables: Handle both fixed-row forms (Schedule D with a set number of lines) and expandable tables
- Data Validation: Validate data types per column (dates, currency, integers) before writing
- Overflow Handling: Continue tables on additional pages or generate continuation sheets when data exceeds available rows
- Nested Tables: Handle parent-child table relationships (e.g., line items with sub-items)
- Formula Support: Calculate totals, subtotals, and derived values within table rows
- Repeating Sections: Fill non-table repeating sections such as multiple addresses or references in forms like the I-485
How It Works
Upload Form with Tables: The system scans the PDF and groups fields by Y-position, identifying which fields belong to each table row. This works on any PDF — scanned or digitally created — as long as the fields are geometrically arranged in rows.
Provide Table Data:
- CSV/Excel: One row per table entry; column headers map to table column labels
- Uploaded Documents: The AI extracts row data from PDFs, Word files, or images — using a table extraction model for structured sources and a list extraction model for enumerated data
- Profile Data: Employment history, dependents, or education entries stored in a profile are available as table source data
- Manual Entry: Use the table editor to enter rows directly in the UI
Column Mapping: The AI matches source column headers to form table column labels. Mappings can be reviewed, adjusted manually, and saved as reusable templates for the same form type.
Parallel Row Filling: Rows are dispatched as concurrent tasks. Each task:
- Receives its own isolated processing context and metadata
- Reads the row's field values
- Writes values into the form fields identified for that row
- Updates row status and emits a completion event
Review & Adjust: Preview the filled table on the form. Add, remove, or reorder rows. Validate that totals and derived fields calculated correctly.
Use Cases
Table field processing handles the row-level repetition that makes form tables tedious to fill manually. Healthcare billing teams populate CMS-1500 service line tables (procedure codes, dates of service, charges) from practice management exports. Legal teams fill asset schedules in estate or I-485 immigration forms from financial documents. Tax preparers complete Schedule D capital gains tables from brokerage trade confirmations without entering each transaction individually. Employers fill I-9 List A/B/C document tables for new hire cohorts from onboarding data.
Benefits
- Speed: Table rows fill in parallel — a 30-row Schedule D table completes in the same time as a single-row form
- Accuracy: Dedicated AI models extract row data from both structured table sources and list-format sources, eliminating manual transcription
- Row Isolation: Per-row isolation means a failure in one row does not corrupt another row's output or cost tracking
- Correct Cell Detection: Table rows are identified geometrically, handling forms where table cells are not explicitly marked as a PDF table structure
- Consistent Column Mapping: Saved mapping templates reuse the same source-column-to-form-field assignments across future batches of the same form type
- Overflow Handling: Data that exceeds the form's available rows continues on additional pages automatically
Security & Privacy
All data is workspace-scoped and protected by JWT authentication middleware across all service layers. Table row data is never accessible outside the workspace that initiated the session.
Table data extracted from sources or typed manually is encrypted with workspace-scoped keys stored in Azure Key Vault. PDF references and all intermediate processing state are protected under the same encryption scheme.
Per-row isolated contexts ensure that cost records and session metadata from one row's AI extraction call cannot appear in another row's audit log.
Common Questions
What if the table has more rows than the form provides?
Fixed-Row Tables (e.g., Schedule D has a fixed number of lines per page):
- The system generates additional pages with continuation sheets, each carrying the next batch of rows
- Example: A form provides 15 rows; 40 transactions generate 3 pages (15 + 15 + 10)
- Standard IRS and government continuation sheet formats are supported where applicable
Variable-Length Tables (fillable PDFs that support dynamic row addition):
- The system adds rows as needed to accommodate all source data
Prioritization: If you need to limit output to a fixed number of rows, select which rows to include from the preview before writing to the PDF.
Can the system handle calculations within tables?
Yes. Calculations that operate on table row values include:
Row-Level:
- Subtotals: Quantity × Unit Price = Line Total
- Gain/Loss: Proceeds − Cost Basis (Schedule D)
- Duration: End Date − Start Date
Column Totals:
- Sum of all values in a column
- Subtotals by category
- Grand totals feeding into form summary fields
Tax Form Example — Schedule C:
- Line items for business expenses by category
- Category subtotals (Travel, Meals, Supplies)
- Grand total expenses
- Net profit = Revenue − Total Expenses
If a PDF form has built-in calculation fields, the system validates its computed totals against those fields. Users can override calculated values when manual adjustment is needed.
How do I handle tables with varying column structures across forms?
Different forms use different labels for the same data: one form calls a column "Description", another calls it "Item", a third calls it "Expense Description". Save a mapping template per form type that records how your source column headers translate to that form's table column labels.
Workflow:
- Map columns for the first session with a new form type
- Save the mapping as a named template
- On subsequent sessions with the same form, apply the saved template — column mapping is skipped
The AI also proposes mappings based on column name similarity, data type matching, and prior mappings for the same form, which reduces the manual work needed when encountering a new form type for the first time.
Can I fill tables from unstructured documents like invoices or receipts?
Yes. The table extraction AI model processes sources where data appears in a structured table format (e.g., a bank statement with transaction rows). The list extraction AI model handles sources where the same data appears as a bulleted list, numbered list, or narrative enumeration (e.g., a physician's medication list in a clinical note).
Example — Expense Report from Receipts:
- Upload 10 receipt PDFs as session sources
- The list extraction model extracts date, vendor, amount, and category from each receipt
- The extracted rows are staged for writing
- Each row is written to the expense report table concurrently
- User reviews the filled table before generating the final PDF
Printed receipts: ~95% extraction accuracy. Handwritten receipts: ~90% (OCR-dependent).
What about nested tables or tables with merged cells?
Geometric Y-position grouping handles a variety of complex layouts:
Merged Cells: Fields that span multiple columns (category header rows, subtotal label cells) are identified by their wider bounding box and treated as span cells rather than individual data cells.
Nested Tables: Parent-child table relationships (e.g., a bill of materials where each line item has sub-components) are detected when a second Y-position grouping falls within the vertical bounds of a parent row. The system fills parent rows first, then child rows within each parent's vertical band.
Multi-Page Tables: Tables that continue across pages are stitched together using form version metadata to associate each row with the correct page of the PDF.
For layouts that do not map cleanly to Y-position grouping, use Field Management to manually define the table structure and column assignments.