PDF vs structured data: Why appearing digital isn't the same as being digital

A supplier creates an invoice in their accounting system, saves it as a PDF, and emails it to a customer.

No paper is printed. No envelope is needed. The invoice arrives in seconds.

Surely that's digital invoicing?

In one sense, absolutely. The document has been created, delivered, and received electronically. But from the customer's perspective, something important may still be missing.

Someone – or some software – needs to read the PDF, identify the relevant information, and turn it into data the customer's accounting system can understand.

The invoice may have travelled digitally, but the information inside it isn't necessarily ready to be processed. And that distinction is becoming increasingly important as businesses automate their financial processes and governments introduce mandatory e-invoicing requirements.

A digital document isn't necessarily structured data

The difference between a PDF invoice and a structured electronic invoice isn't primarily about how they look. It's about how the information is represented.

A PDF is designed to preserve the appearance of a document. It allows people to see the supplier's name, invoice number, line items, totals, and payment information in a familiar layout.

That makes it convenient for human readers, but a PDF doesn't inherently tell the receiving system which piece of information represents the invoice number, which value is the VAT amount, or which reference connects the invoice to a purchase order.

Those details are visible to a person, but they may need to be extracted and interpreted before the information can be used.

A structured electronic invoice works differently.

Instead of presenting information primarily as a visual document, it organises the data into defined fields according to an agreed structure.

An invoice number is identified as an invoice number. A tax amount is represented as a tax amount. Buyer and supplier information, dates, line items, and references are represented in ways that compatible systems can interpret.

Standards and formats such as UBL, CII, and Peppol BIS Billing support this kind of structured exchange.

The objective isn't to make invoices easier to look at. It's to make them easier for systems to understand.

What happens when a PDF invoice arrives?

Imagine a finance department receiving 500 supplier invoices every month.

If those invoices arrive as PDFs, the company needs a way to extract their contents and enter the information into its accounting or ERP system.

In some organisations, that still involves manual data entry. An employee opens the invoice, identifies the relevant details, and transfers them into the system.

Others use optical character recognition (OCR), AI-based document processing, or other invoice-capture technologies to extract information automatically.

These technologies can be highly effective, and it's important not to underestimate their value. Modern document processing can reduce manual work considerably, particularly when dealing with suppliers that don't support structured electronic invoicing.

But the underlying process still involves interpreting a document.

The software must determine which information on the page corresponds to which field in the receiving system. Different invoice layouts, missing references, ambiguous information, and extraction errors can require additional checks.

Structured electronic invoicing changes the starting point.

When an invoice arrives in a supported structured format, the receiving system can identify the relevant data fields without first having to reconstruct them from the document's visual appearance.

Validation and business rules are still necessary, and exceptions can still occur. But one important step – extracting structured information from an unstructured presentation – can be avoided.

The real difference appears in the process

Consider two suppliers sending invoices to the same customer.

Supplier A emails a PDF, and supplier B sends a structured electronic invoice through an agreed exchange network or integration.

Both invoices contain the same commercial information. Both may look identical if rendered for a human reader. But the customer's systems may handle them very differently.

Supplier A's PDF enters a document-capture process, where the information is extracted, interpreted, and checked before it can be used.

Supplier B's structured invoice can enter a validation and processing workflow directly, provided the format and integration are supported.

The second process isn't automatically perfect. The invoice may still contain an incorrect purchase order number, an unexpected price, or information that doesn't match the customer's records.

But those are business-data problems rather than document-reading problems.

And that's important to bear in mind. Automation becomes more reliable when systems receive information in a form they already understand.

Why purchase order matching matters

The benefits become particularly visible when invoices are connected to other business documents.

Imagine that a customer has already received an electronic purchase order confirmation and shipping information from a supplier.

When the invoice arrives, the customer's system may be able to compare its contents with the original purchase order and, where applicable, the goods receipt.

Do the quantities match? Are the prices correct? Does the invoice reference the right order? Have the goods been received?

This is commonly known as invoice matching, and structured data can make it easier to automate.

Instead of employees manually comparing information across documents, the system can apply predefined rules and identify transactions that require attention.

Of course, structured invoices don't guarantee successful matching. The data still needs to be accurate and consistent across the transaction.

But when purchase orders, shipping information, and invoices all contain structured information, businesses have a stronger foundation for automated processes.

This is also where e-invoicing and traditional EDI begin to overlap.

Both are concerned with exchanging business information in a form that other systems can process, rather than simply moving documents from one inbox to another.

A PDF can still be useful

None of this means PDFs are obsolete or inherently bad.

They remain useful for displaying information, sharing documents, and providing a readable representation of a transaction.

In fact, structured electronic invoices are often rendered into a familiar invoice layout so that people can review them.

Some electronic invoicing formats also combine structured data with a human-readable PDF representation.

The important distinction is therefore not necessarily PDF versus no PDF - it's whether the invoice contains structured information that the receiving system can process.

A PDF may be an excellent way to display an invoice, but it isn't necessarily the best way to exchange the underlying data.

Why e-invoicing mandates are making this distinction important

For many years, businesses could reasonably describe themselves as using electronic invoicing because they had stopped printing and posting invoices.

Today, that definition is becoming increasingly insufficient.

Across Europe and other international markets, governments are introducing requirements for structured electronic invoices, often based on specific national platforms, formats, or interoperability frameworks.

The European standard EN 16931, for example, defines a semantic data model for electronic invoices, helping establish a common understanding of the information an invoice must contain.

Individual countries may implement their requirements differently, but many share an important principle: an invoice that's merely sent electronically isn't necessarily a compliant structured e-invoice.

That's why businesses preparing for mandatory e-invoicing need to look beyond how invoices are delivered.

They need to understand how invoice data is generated, structured, validated, transmitted, and received.

A process built around emailing PDFs may be digital in the everyday sense, but it may not meet the requirements of a particular e-invoicing mandate.

The opportunity goes beyond compliance

It's easy to approach structured e-invoicing as another regulatory requirement.

And for businesses operating in countries introducing mandatory e-invoicing, compliance is certainly an important reason to act.

But focusing exclusively on the mandate risks overlooking the broader opportunity.

When invoice information moves between systems as structured data, businesses can reduce their dependence on manual entry and document interpretation.

They can create more consistent processes for validating information, matching invoices against orders, and identifying exceptions.

And they can build connections between their ERP systems, suppliers, customers, and external networks that support more automated financial operations.

The value isn't simply that an invoice is electronic - it's that the information inside it becomes usable without having to be manually recreated.

Digital delivery is only the first step

Moving from paper invoices to emailed PDFs was an important step in the digitalisation of business processes. It made invoice delivery faster, cheaper, and more convenient.

But it didn't necessarily change what happened after the invoice arrived.

Structured electronic invoicing takes the next step by focusing on the information itself.

Instead of sending a document that another system needs to interpret, businesses can exchange data that's already organised for electronic processing.

At iEDI, we help businesses exchange structured business documents through EDI, Peppol, and country-specific e-invoicing frameworks, connecting different systems, partners, and requirements.

The real potential of digitalisation isn't simply replacing paper with a screen.

It's replacing unnecessary manual processing with information that can move directly between systems.