# PDF to XML: When a System Wants Tagged Data

- Author: FastBankConvert (https://fastbankconvert.com)
- Published: 2026-10-17
- Category: CSV, JSON and text output
- Canonical: https://fastbankconvert.com/blog/pdf-to-xml

> When you need PDF to XML: systems that want tagged records, how a table maps to elements, and why most people want CSV or JSON instead.
You need PDF to XML conversion when a receiving system only accepts tagged data, such as an older ERP import or a filing portal. Each table row becomes an element, and each value sits inside a named tag. If nobody has asked you for XML specifically, CSV or JSON is usually easier to produce and check.

## Which systems ask for PDF data as XML?

Systems that ask for XML are usually ones built around a fixed, published file layout. Enterprise resource planning imports, electronic invoicing networks, some tax and regulatory portals, and older banking and payroll integrations often define an XML layout and reject anything else. The request almost always comes with a document describing which tags to use.

That document matters more than the PDF. XML itself defines no tag names for an invoice line or a payment. Each system or industry layout names its own. So "convert this PDF to XML" really means "put these values into the tags this system expects". Ask for the layout, or a sample file, before you convert anything.

If the request is vague, ask what the receiver will do with the file. Often a spreadsheet or CSV upload is also accepted, and nobody mentioned it.

## How a PDF table maps to XML elements and attributes

A PDF table maps to XML by turning the table into a parent element, each row into a child element, and each cell into a named element or attribute inside that row. The column headings on the page become the tag names, unless the receiving system dictates its own.

Here is an example invoice line, with made-up values, first as a CSV row:

```
sku,description,qty,unit_price
00412,Pallet wrap 500mm,6,6.95
```

The same row as XML:

```xml
<invoice number="INV-2208">
  <line>
    <sku>00412</sku>
    <description>Pallet wrap 500mm</description>
    <qty>6</qty>
    <unit_price>6.95</unit_price>
  </line>
</invoice>
```

The invoice number is an attribute because it applies to the whole invoice, not to one line. Each value in XML is text; the type comes from the receiving system's rules, so the SKU keeps its leading zeros without any special handling.

The same row in three formats compares like this:

| Format | Size of one row | Names on every value | Nesting |
| --- | --- | --- | --- |
| CSV | Smallest | No, header row only | No |
| JSON | Medium | Yes, as keys | Yes |
| XML | Largest | Yes, as opening and closing tags | Yes |

## XML well-formedness rules that reject a converted file

An XML file that breaks the well-formedness rules is refused before any system reads its values. The [W3C XML 1.0 specification](https://www.w3.org/TR/xml/) says a document has exactly one root element, that elements must nest properly within each other, and that an end tag's name must match its start tag.

Converted PDF text trips those rules in predictable places:

- **Ampersands in descriptions.** A supplier called "Smith & Sons" breaks the file. The specification says `&` and `<` must be escaped, as `&amp;` and `&lt;`.
- **Case changes in tags.** The specification's name matching does no case folding, so `<Line>` closed by `</line>` is an error.
- **Two roots.** Writing each page's table as its own top-level element gives two roots. Wrap them in one parent.
- **Odd characters.** Text copied from a PDF can carry characters in another encoding. Save as UTF-8 and declare it; [why accents break in CSV files and how UTF-8 fixes them](/blog/csv-utf-8-excel) explains the same problem for CSV.

Well-formed is the minimum. The receiver may also validate against its own schema, checking required tags and their order.

## Is CSV or JSON a better target than XML for your PDF?

CSV or JSON is the better target for most PDF data, because more tools read them, the files are smaller and you can check them by eye. Choose XML only when a named system requires it. If you just need the table in another program, CSV opens in every spreadsheet, and JSON loads in every programming language.

Between the flat formats there is a further choice: commas or tabs. [Choosing between TSV and CSV](/blog/tsv-vs-csv) covers when a tab-delimited file avoids quoting trouble with descriptions that contain commas.

## Getting from a PDF to an XML file in two steps

Getting a PDF into XML is easiest as two steps: first extract the table into rows and columns, then write those rows into the required tags. Few tools go straight from a page to a custom XML layout, and splitting the job lets you check the rows before they are wrapped in markup.

1. **Extract the table.** Convert the PDF to CSV or Excel, then check row counts and totals against the page.
2. **Map the columns to tags.** Write down which column fills which tag, including attributes and fixed values the layout requires.
3. **Generate the XML.** A short script reads the CSV and writes one element per row. If you already use Python, [extracting PDF data into Excel with Python](/blog/extract-data-from-pdf-to-excel-python) covers the first step, and the same script can write XML with the standard library.
4. **Validate.** Open the result in a browser or an XML editor, which will flag well-formedness errors, then run the receiver's test upload if it has one.

For bank statements, FastBankConvert is getting ready to open with Excel, CSV and JSON downloads. It does not write XML, so it would cover step one; [Get started](/get-started) to hear when it opens.