Why the PDF Is the Right Home for Structured Appraisal Data
When a lender orders an appraisal, what they expect to receive is a PDF. When an underwriter reviews a property, they open a PDF. When an appraiser delivers their work, they send a PDF. The PDF is — and has always been — the document that the appraisal world recognizes as the appraisal.
So when the question arises of how to deliver structured data alongside the appraisal report, the answer that EPM arrives at is straightforward: put it in the file everyone already uses. Put it in the PDF.
This article explains why that approach is better than the alternatives, and why the industry's experience with an earlier standard — the Uniform Appraisal Dataset (UAD) — helped point the way.
The Problem: Two Files Are Harder Than One
Structured data is the machine-readable version of the information in an appraisal report — the kind that software, analytics tools, and AI systems can actually work with. A PDF alone does not provide this. Getting structured data out of a PDF the hard way means extraction — software attempting to read and interpret the text on the page. That process is imprecise and error-prone.
The better path is to carry the structured data with the report, intact and ready to use, so nothing has to be guessed or reconstructed.
The question is: how?
Two approaches have been tried or proposed in the mortgage and appraisal industry. Both have real drawbacks.
Approach 1 — A Separate File (the "Sidecar" Model)
One option is to deliver the structured data as a separate file alongside the PDF — either on its own or bundled together in a ZIP file. This is how the current UAD 3.6 submission to the UCDP works: a ZIP package containing the PDF, an XML data file (structured data), and a folder of property images.
The problem is that two files have to stay together through every step of a transaction — email, portals, cloud storage, review, and archive. In practice, files get separated. The PDF gets forwarded to the underwriter; the XML stays behind in someone's upload folder. Or the ZIP gets opened, the PDF gets pulled out, and the structured data is never seen again.
Nobody does this intentionally. It just happens, because the PDF is the thing people are looking for. Everything else feels like baggage.
Approach 2 — The PDF Embedded in the XML
This is what the original UAD 2.6 standard required from 2011 until recently. The appraisal's XML data file was the primary delivery file, and the PDF was tucked inside it — encoded as scrambled text that a human cannot read without specialized software.
This arrangement was born out of necessity. In 2011, there was no widely adopted standard for embedding files inside a PDF. XML was the only practical container at the time. But the result was awkward: appraisers were sending lenders files that looked like computer code, lenders couldn't open them without special tools, and the industry immediately developed workarounds just to extract a readable copy of the report.
It was a machine-first design that made life harder for the humans who needed to use it. The experience of UAD 2.6 was, in many ways, one of the motivations behind thinking carefully about how structured data should travel with a report — and doing it better.
The EPM Approach — Invisible Infrastructure
EPM takes the opposite view from both approaches above.
The PDF is the host. The structured data rides inside it as a payload. It is stored in a standardized, discoverable way that does not affect the appearance, readability, or printability of the report in any way.
A reader who opens the PDF sees exactly what they have always seen. Nothing looks different. Nothing is harder to use. The structured data is simply there, silently, for any system that knows how to find it.
This matters for several reasons:
One file, one workflow. The appraiser delivers a PDF, same as always. The client receives a PDF, same as always. There is no second file to keep track of, no ZIP to unpack, no XML to explain to someone who has never heard of it.
The data stays with the document. Because the payload is part of the PDF itself, the structured data cannot be accidentally separated from the report. Wherever the PDF goes — forwarded, uploaded, downloaded, archived — the data goes with it.
Transparency without disruption. Embedding a file inside a PDF using modern standards is a well-established capability. It does not change the document's appearance. It does not break printing. It does not require the recipient to do anything differently. For the vast majority of people who receive an appraisal, nothing has changed. For the systems that need the structured data, everything has improved.
Intentional protection, not accidental loss. Could someone deliberately open the PDF and remove the embedded payload? Yes — just as someone could open a ZIP and delete the XML file, or receive an email attachment and forward only one of two files. No delivery method is immune to deliberate action. But EPM's approach eliminates the accidental separation that the sidecar model invites every time a file is forwarded or uploaded.
The Source of Truth Travels With the Report
Structured data is the source of truth. The PDF is its rendered form — the human-readable expression of that truth. The PDF is the appraisal standards compliant document. There is no reason these two things cannot live in the same file.
EPM makes the PDF the single document of record: readable by people, usable by machines, and delivered in the format the appraisal world has always expected.
If you want the related security and transport details, see EPM Payload Encryption and Compression.
Glossary terms referenced on this page: structured data, extraction, ZIP file, XML, UCDP, payload