PDF to Excel automation, traced past the flat-sheet dump.

Path 1: Excel as a sheet

Your PDF is a single-page table of values. Your Excel is a fresh sheet. You want the table out of the PDF and into the workbook so you can sort it. This is the case Microsoft built into Excel itself in 2020. Open Excel, go to Data, Get Data, From File, From PDF, point it at the PDF, choose the table from the navigator, and load.

The build-in import is power-queryable, refreshable, and free. For one-off conversions and small recurring extracts, it is the right answer. The reason it is not the answer for an enterprise workflow is that it produces a fresh sheet, not a write into your existing structure. If your real destination is a reconciliation workbook with eight tabs, named ranges, and ten years of formulas, the import sits on a new tab and you still have to copy values across.

The other limit is that the import handles a flat table well and a form-shaped PDF poorly. An invoice PDF where total, vendor, and PO number are scattered across labelled boxes is not what the importer is for. For that case you need either a document AI tool or the destination-shaped pipeline below.

Path 2: Excel as a row-per-document log

The PDFs arrive on a schedule. Each one is a vendor invoice or a claims form or a bill of lading. The Excel target is a long sheet where each row represents one document. The columns are invoice_number, vendor, total, due_date, and so on. You want every new PDF to become one new row.

This is the lane the document AI vendors own. Docparser, Klippa, Parseur, Nanonets, Affinda, and Rossum will all parse the PDF into JSON, and most of them have a built-in Excel or Google Sheets destination that appends a row. Microsoft Power Automate ships a first-party action called Extract data from PDF that does the same thing inside Office tenants. They have all converged on the same shape, because the row-per-document case is the bulk of the market.

When this is your destination shape, do not over-think it. The row-append products are mature and the price-per-document is in single-digit cents. Mediar does not have a particularly differentiated answer here, and we will tell you so on a call. The destination-shaped pipeline below is for the case the row-append tools cannot handle.

Path 3: Excel as a corporate template

Your Excel destination is not a sheet that grows by row. It is a template. There are merged cells, named ranges, IF and SUMIF formulas across tabs, data validations on certain inputs, and a structure your finance team built and refuses to redesign. The PDF values do not become a row at the bottom; they become specific cells inside the template. The PO number goes in B5 of the Header tab, the line items go in A12 through E40 of the Detail tab, and the total in B5 of the Summary tab is a formula that references both.

This is the case the row-append products do not address. The destination is structured beyond what a column mapping can describe. A typical workaround is a brittle VBA macro that reads a JSON file and walks the workbook, which works until the template grows a tab or somebody renames a sheet. The destination-shaped pipeline is built for this case, and it leans on a feature of Excel that nobody in the PDF-to-Excel category writes about: every cell is a UI Automation element.

Why Excel cells are UI Automation elements (and why that matters)

UI Automation is the framework Windows screen readers use to read the screen aloud. It exposes every visible control as a tree of elements, each with a role (Edit, Button, ComboBox, DataItem), an accessible name, an automation id, and one or more control patterns. The Value pattern is the one that says “this control accepts and emits a string,” and an Excel cell that is in edit mode supports it. Microsoft documents this as a property of the DataItem control type and the IValueProvider interface, both shipped before Office 365 had a public name.

The practical consequence is that any UI Automation client (a screen reader, a Mediar runtime, a Rust binary, a Python script using uiautomation) can address an Excel cell by its accessible name and call SetValue on it. Excel reacts the same way it reacts to a human typing: dependents recalc, validations fire, conditional formatting reflows. There is no xlsx parser writing bytes underneath the running Excel process. The state goes through the application itself.

Here is what the relevant slice of the UIA tree looks like when you inspect a workbook with the Inspect tool that ships in the Windows SDK:

That tree is what the Mediar runtime walks. The locator for cell B5 on Sheet1 is name:B5|role:DataItem|parent_name:Sheet1, captured at recording time and replayed at run time. When the template grows a column and the same cell is now C5, the locator falls back to the recorded automation id (which is the cell’s underlying Range identifier, not the visible label) and the typing pass still resolves.

The recorder writes the schema, not you

The reason this pipeline can target a custom Excel template at all is that nobody hand-writes the schema. The recorder watches the operator fill the template once, captures every cell that received a typed value, and emits a Zod input schema with one line per cell. The code that does this lives in one file in the open repo:

// apps/desktop/src-tauri/src/recording_processor.rs

let mut detected_inputs: HashMap<String, String> = HashMap::new();
for (i, step) in workflow.steps.iter().enumerate() {
    for substep in &step.substeps {
        for input in &substep.inputs {
            if !detected_inputs.contains_key(input) {
                detected_inputs.insert(
                    input.clone(),
                    format!("// Found in step: {}", step.step_name),
                );
            }
        }
    }
}

let mut input_fields = String::new();
for input in detected_inputs.keys() {
    let field_name = to_camel_case(input);
    input_fields.push_str(&format!(
        "  {}: z.string().optional().describe(\"{}\"),\n",
        field_name, input,
    ));
}

For an Excel reconciliation template with cells labelled invoice_number, vendor, po_number, total, due_date, and currency, the generated terminator.ts inputSchema is six lines of z.string().optional().describe(...). That schema is then handed to the vision pass on the PDF as the structured-output target, which means the JSON returned by the model has those exact keys. There is no manual remap from extractor field names to template cell names, because the template cell names became the extractor schema.

You can verify this by cloning the desktop app, opening the file at the path above, and grepping for detected_inputs. The loop that emits the schema lines is around line 1670.

The three paths, side by side

Here is the comparison rolled up. The first column is the row-per-document tooling that owns Path 2; the second column is the destination-shaped pipeline for Path 3. Path 1 is not in the table because the native Excel import does not really compete on these axes; it is for the case where Excel is empty.

What this still does not solve

A page that only describes the easy cases is a brochure. Three honest limits:

• On PDFs that current vision-capable models cannot read (handwritten cursive, multi-language carbon copies, severe ink bleed) the extraction step still needs human review. The schema constraint keeps the model honest about which cells it could not fill, but it does not improve recognition quality.
• On Excel installs where the workbook is open in a SharePoint web view, an iframe inside Teams, or Excel for Mac, the UI Automation tree is different or absent. The native Windows Excel client is the reliable target, and the runtime is honest about that.
• If your Excel destination is a fundamentally flat sheet that grows by row, the destination-shaped recording is overkill. Use Docparser or Power Automate’s Extract data from PDF action and pay cents per document.

Within those limits, the destination-shaped path is what most finance, ops, and claims teams are actually trying to buy when they search for PDF to Excel automation. They do not want a smarter table extractor. They have an extractor. They want the values in the right cells of the template they already built.

Frequently asked questions