From PDF To Programmable Asset: Why The Invoice Is Not A Document
“The map is not the territory.”
Alfred Habdank Skarbek Korzybski, Polish-American philosopher (1879–1950)
Pillar III – From Documents To Verifiable Trade Objects – Part 2 of 3:
By Stephan Wolf, Chair of the Board of Trustees at Verifiable.Trade Foundation
July 2026
Summary
For decades, global commerce has relied on paper and PDFs, not because documents are the underlying assets, but because they served as a convenient workaround for transporting trust between organizations. As digitally verifiable data makes trust intrinsic to the information itself, the traditional document shifts from an essential carrier of truth to a mere temporary view of it. Monolithic containers like invoices dissolve into network-aware business objects that machines can verify deterministically rather than parse probabilistically.
ISTTP fundamentally changes this model. Individual data elements such as trusted identities, delegated authority, payment obligations and verified events become standalone, verifiable assets that embody specific rights, obligations and economic value.
Introduction
In the previous articles, we explored how trust begins with verifiable identity and delegated authority. This article applies those concepts to one of the most familiar trade documents where assumptions and traditional protocols can create a flawed foundation: the invoice.
In April 2015, a finance executive at Mattel received an email that appeared to come from the company's newly appointed CEO. It requested a routine wire transfer of three million US dollars to settle a vendor payment in China. The request matched internal protocol exactly: transfers required approval from two senior managers, and both the executive and the apparent CEO qualified. The transfer was authorized and executed.
A few hours later, the executive mentioned the payment to the CEO in person. He had never sent the request. The email, the vendor, and the invoice behind it were fabricated. Mattel recovered the funds only because a banking holiday in China delayed the transfer long enough for law enforcement to intervene. Most companies targeted by similar schemes are not so fortunate.[1]
What failed at Mattel was not the wire transfer process. Every internal control was followed correctly. What failed was the assumption underneath the process: that a message bearing the right name, the right context, and the right timing could be trusted as evidence of identity and authority. Specifically, the invoice and the accompanying instruction were treated as genuine because they appeared to be correct and had arrived through a plausible channel. Nothing in the process could independently verify who had actually issued it, or whether that person was authorized for the action that followed.
Mattel is not an outlier; the flawed foundation in today’s business models is extensive. In 2024 alone, the FBI's Internet Crime Complaint Center recorded more than 21,000 business email compromise incidents with reported losses of 2.77 billion US dollars, the large majority of them built on the same mechanism: a payment instruction that looked authoritative enough to be acted on.[2]
There is a deeper pattern behind decades of invoices and the broader subject of trade digitisation. The industry has largely focused on replacing paper with PDFs, XML messages, and electronic archives. While this improves efficiency, it does not change the underlying model. Each virtual artefact remains a document that humans and systems must interpret, reconcile, and trust based on appearance.
Digitizing turns paper into electronic form. The content stays the same, only the medium changes, and it's still read by humans.
Digitalizing breaks that content into separate, machine-readable data elements. The information is the same, but now a system can act on it directly instead of just displaying it.
[1] Erika Kinetz, "Chinese scammers take Mattel to the bank, phishing them for $3 million"reporting based on an Associated Press investigation, reproduced by CSO Online, March 2016. https://www.csoonline.com/article/555513/chinese-scammers-take-mattel-to-the-bank-phishing-them-for-3-million.html
[2] FBI Internet Crime Complaint Center (IC3), 2024 Internet Crime Report: Business Email Compromise accounted for 21,442 reported complaints and USD 2.77 billion in losses in 2024 alone. https://www.ic3.gov
We digitized the paper representation of the invoice. We did not digitalize the invoice itself or the trust connnected with the invoice.
That gap is not new. Documents were never the objective of commerce; they emerged as a practical workaround, enabling commercial facts and conversations to be transported between organizations with a degree of authenticity in a paper-based world.
Opportunity
When information itself becomes digitally verifiable, the document loses its role as the primary carrier of trust. It becomes just one possible representation of a richer, underlying commercial reality.
This approach addresses two questions and potentially transforms the context of Trade.
What if an invoice were not a document at all?
What if it were a collection of verifiable digital assets, rights, obligations, authorities, events, and relationships that machines could directly verify rather than merely read?
What Exactly Is the Asset?
One of the first questions readers might ask: if an invoice is decomposed into multiple verifiable objects, what exactly is the asset?
Consider a typical invoice. Behind the appearance of a single document lie several economically valuable elements: the identity of the supplier, the authority of the employee who issued it, the receivable itself, the buyer's payment obligation, and evidence that delivery occurred. Each has value independently of the PDF that bundles them together.
Traditionally, businesses think of assets as tangible things such as physical goods, receivables, cash, securities, or contractual rights. Documents do not constitute these assets; they merely evidence or describe them. A bill of lading evidences rights to goods in transit. A warehouse receipt evidences rights to stored inventory. An invoice evidences a payment obligation for the buyer and a corresponding receivable for the seller.
Under ISTTP (International Secure Trade Transport Protocol), that changes. Beyond the documents where they are found, individual data can carry rights, obligations, authority, provenance, and control. Identity becomes an asset, and trusted identity creates economic value.
Authority becomes an asset because delegated rights enable legally effective actions on behalf of an organization.
A receivable remains an asset because it represents a claim to future payment.
A payment obligation creates a corresponding asset for the creditor because it establishes an enforceable right to payment.
Even a verified event can become an asset because it changes commercial reality and creates new legal and commercial consequences that can happen automatically.
The consequences are endless. A delivery confirmation may trigger payment. A customs clearance may release goods. An approval may activate financing. Under ISTTP, every machine-readable set of data elements can become a verifiable asset when it carries legal significance, economic value, authority, rights, obligations, or evidentiary value.
In this new world, the invoice is not the asset. The invoice is a container that bundles multiple assets, relationships, obligations, authorities, and events into a single human-readable representation that can be actioned.
The Invoice Is Not a Document. It Is a Business Process.
An invoice can be far more than a request for payment. In reality, it is the visible manifestation of an evolving commercial process. In other words, it is a window at a point in time into a long running Business Process
There is an innovative lifecycle hiding within an invoice. It may begin as a quotation invoice or pro forma invoice. It may evolve into a formally issued commercial invoice, a partial invoice, a milestone invoice, a recurring invoice, or a reciprocal tax invoice. It may later be corrected through a credit note or debit note, to trigger, modify, or halt ramifying processes like VAT reporting. It may become disputed, financed, pledged, partially paid, fully settled, cancelled, written off, or archived.
Each of these states represents a legally and commercially meaningful event. Traditional systems model these changes through new documents, document versions, attachments, emails, and workflow records. The result is duplication, reconciliation challenges, fragmented audit trails, and increasing operational, execution, and financial risks.
The underlying reality is simpler. The invoice represents a set of evolving business facts. Those facts change over time. The invoice should therefore be understood as a dynamic state model rather than a static file.
Why AI Parsing Is Not Enough
Many observers argue that modern AI makes decomposition unnecessary because AI can already read invoices.
Large language models can extract invoice numbers, supplier names, amounts, tax information, line items, and payment terms from PDFs with impressive accuracy. However, trade is not fundamentally an information extraction problem. Trade is a perpetual trust problem, end-to-end of any trade and beyond re Recycling, DPP ESG etc. AI cannot read trust into the invoice or any other document.
Mattel's finance team did not fail to read the email correctly. They read it perfectly. What they could not do, and what no amount of parsing accuracy would have changed, was verify whether the sender actually held the authority the message claimed.
An AI model may correctly identify a supplier and an amount due. Yet, there are limitations because of AI’s abbility to accurately determining the following.
· Was the invoice legitimately issued?
· Has it has been revoked?
· Is there a corrected version that supersedes it?
· Have financing rights have already been assigned?
· Does the signatory possessed delegated authority?
· Is there a a dispute that has suspended payment obligations.
PDFs contain information. They do not contain authoritative state. AI therefore remains dependent on inference. It attempts to determine truth from context. A deconstructed model changes this fundamentally.
First, documents are reconstructed into authenticated business objects and data elements that can be verified independently.
Second, commercial processes are reconstructed into verifiable functional or legal states connected by authenticated transitions. Instead of interpreting unstructured documents, systems can directly evaluate identities, authorities, obligations, dependencies, lifecycle events, and the current legal state of a transaction.
The result is a shift from probabilistic interpretation to deterministic verification. Machines spend less effort understanding documents and more effort evaluating trusted facts.
Reconstructing the Invoice into Verifiable Objects
As explored in previous blogs in this series, ISTTP starts from a simple but powerful premise: Data carries its own evidence. Trust travels with the data. Every machine readable collection of data elements can therefore be treated as a digital asset carrying verifiable evidence of origin, integrity, control, and authorization. An invoice is no longer treated as a single monolithic document but as a collection of independently verifiable business objects.
The primary motivation is not security. Digital signatures, credentials, and authorization mechanisms already strengthen today's document-centric models. The real advantage is that the commercial facts contained in an invoice evolve independently. Identity changes rarely. Delegated authority changes more frequently. Delivery events, financing status, disputes, approvals, and settlement each follow their own lifecycle.
An equally important form of reconstruction applies to the business process itself. Commercial transactions evolve through a sequence of verifiable legal and functional states connected by authenticated events. Each state reflects the current legal and commercial position of the transaction at a particular moment.
Traditional documents bundle changing facts into repeated revisions, reconciliations, and parallel records. Reconstruction allows each business object and each transaction state to evolve independently while remaining cryptographically linked to the wider transaction. The result is a shift from document-centric state management to object-centric and state-centric management:
Identity objects describe the supplier, buyer, logistics providers, financing institutions, tax authorities, employees, AI agents, and systems involved.
Authority objects describe delegated powers. They define who may issue, approve, amend, revoke, finance, settle, or dispute an invoice, and whether that authority is still valid at the moment it is exercised.
Commercial objects describe goods, services, quantities, prices, taxes, payment terms, discounts, contractual obligations, and receivables.
Lifecycle objects capture issuance, acceptance, rejection, amendment, correction, financing, factoring, partial payment, settlement, cancellation, and archival.
Dependency objects connect the invoice to purchase orders, delivery notes, transport documents, customs declarations, financing agreements, insurance policies, sustainability credentials, and payment instructions.
Each object becomes a verifiable asset carrying its own evidence while remaining cryptographically connected to the wider transaction.
Under this model, the Mattel scenario changes fundamentally. A payment instruction is no longer evaluated by how convincing it appears. It is evaluated by whether the underlying identity object resolves to a genuine, authenticated party and whether the corresponding authority object is valid, properly scoped to the transaction, and still in force. A message that appears flawless but lacks verifiable delegated authority simply cannot be executed.
The Mattel case illustrates another important point. It demonstrates the need for verifiable identity and delegated authority. It does not, by itself, demonstrate the need for decomposition. A document-centric system enhanced with verifiable identity and authority could likely have prevented the same fraud.
The stronger case for reconstruction lies elsewhere. Commercial relationships evolve continuously. Identities, delegated authorities, deliveries, financing arrangements, disputes, approvals, and settlements each follow their own lifecycle. Treating these as independently verifiable business objects allows every change to be managed, authenticated, and audited without repeatedly recreating entire documents. The value of decomposition therefore lies not primarily in preventing a single fraudulent instruction, but in enabling the efficient and trustworthy management of complex commercial relationships over time.
From Documents to Programmable Assets
A programmable asset is not software. It is an asset whose verified state allows software to take and make deterministic decisions. Once delivery has been verified, payment can be authorized automatically. Once financing has been registered, duplicate financing requests can be rejected immediately. The asset becomes actionable rather than merely readable.
The power of reconstruction becomes apparent when considering automation. A traditional invoice PDF is effectively a snapshot. Systems must repeatedly parse, interpret, compare, reconcile, and validate it. A reconstructed invoice behaves like a programmable asset.
Consider a bank evaluating invoice financing. Instead of interpreting a PDF, the bank can independently verify that the supplier’s identity is authentic, that the issuer has delegated authority, that the goods were delivered, that no conflicting pledge exists, and that payment obligations remain valid.
An ERP system can determine whether delivery obligations have been fulfilled. A customs authority can verify commercial values and supporting evidence. An auditor can independently validate the entire chain of events. An AI procurement agent can evaluate payment obligations based on authenticated facts rather than document interpretation.
The invoice ceases to be a file. It becomes a machine-readable commercial state.
Why does this matter in practice?
The implications extend far beyond fraud prevention. Once invoices become collections of verifiable business objects rather than static documents, entire classes of manual reconciliation disappear.
ERP systems no longer need to compare multiple versions of the same information or maintain duplicate records across applications.
Compliance checks can be performed continuously as business events occur, rather than retrospectively through document reviews.
Financial institutions can automate decisioning and execution of financing requests in real time based on authenticated receivables and verified authority.
Intelligent ERP systems and AI agents can make deterministic decisions from trusted commercial facts rather than inferred document content, enabling a new generation of machine-to-machine commerce in which business processes execute automatically whenever predefined conditions are verifiably satisfied.
Standards Already Exist
The invoice domain already benefits from extensive standardization. Examples include UN/CEFACT Cross Industry Invoice[1], UBL, EN 16931[2], PEPPOL BIS Billing[3], Factur-X, ZUGFeRD, ISO 20022 payment messages[4], and numerous national eInvoicing frameworks.
ISTTP does not seek to replace these. It adds a trust and state-management layer that operates across them: verifiable identity, delegated authority, integrity, provenance, lifecycle management, and dependency awareness, without altering the underlying business semantics. An invoice represented in UBL, CII, EN 16931, PEPPOL, or a national format remains fully valid.
The result is a shift from representing static business states to managing authenticated state transitions, from document exchange to state management. How ISTTP specifically extends a standard such as EN 16931 without breaking compliance is the subject of a dedicated article later in this pillar.
Could ISTTP Endpoints Become PEPPOL Nodes?
PEPPOL has proven the value of interoperable business messaging at global scale. Its federated network of access points solved much of the connectivity and routing challenge that previously limited electronic document exchange. ISTTP addresses a different, complementary layer: identity, delegated authority, integrity, control, lifecycle management, and verifiable state transitions.
Whether an ISTTP endpoint could function as a next-generation PEPPOL node is a real architectural question. PEPPOL and ISTTP are not competing architectures; they solve different problems and can be highly complementary. The implementation details of this relationship are the subject of an upcoming article dedicated to protocol interoperability.
Beyond the Invoice
[1] UN/CEFACT, Cross Industry Invoice (CII) semantic data model, United Nations Centre for Trade Facilitation and Electronic Business. https://unece.org/trade/uncefact
[2] Directive 2014/55/EU of the European Parliament and of the Council on electronic invoicing in public procurement; EN 16931 is the semantic data model developed by CEN/TC 434 to implement it. https://eur-lex.europa.eu/eli/dir/2014/55/oj
[3] OpenPeppol AISBL, Peppol BIS Billing 3.0 specification and the Peppol network governance framework. https://docs.peppol.eu/poacc/billing/3.0/
[4] ISO 20022, "Financial Services — Universal financial industry message scheme," International Organization for Standardization. https://www.iso20022.org
Documents describe commercial reality. Verifiable objects become part of commercial reality. The invoice is only one example.
The same decomposition approach applies to purchase orders, delivery notes, certificates of origin, warehouse receipts, bills of lading, insurance certificates, customs declarations, sustainability credentials, financing agreements, and electronic transferable records.
Ultimately, the objective is not document digitalization. The objective is the creation of a shared Digital Public Infrastructure (DPI) of verifiable business objects that can be independently authenticated, authorized, transferred, and acted upon across organizational boundaries. We see ISTTP as a main building block for such a DPI.
Digital trade is not fundamentally about exchanging documents. It is about managing and acting on trusted states and the relationships between them.
Conclusion
For decades, digital trade has focused on digitizing documents. The next phase of digital transformation is different. It focuses on digitalizing trust and transparency.
Reconstruction enables invoices to evolve from static files into programmable assets comprising authenticated identities, authorities, obligations, rights, events, and relationships. Humans and machines gain access to the same authoritative state and the same chain of evidence.
Mattel's three million dollars moved because a message looked right, arrived at the right time, and matched a process built to check form rather than verify substance. That gap between appearance and verifiable fact is exactly what decomposition closes.
The invoice does not disappear. It simply changes its role. It becomes one possible human-readable representation of a much richer digital reality.
From Concept to Capability: What Finance Leaders, ERP Providers, and Regulators Must Do
The call to action is clear: stop asking whether a document looks authentic, and start asking whether its origin, integrity, and authority can be independently verified.
Finance and trade finance leaders should treat invoice financing, factoring, and payment authorization as verification problems, not document-review problems, and pilot object-level verification wherever counterparty risk and fraud exposure are highest.
ERP and platform providers should prepare their systems to consume and issue verifiable trade objects alongside existing document formats, so decomposition can be adopted incrementally without disrupting current workflows.
Standard-setting bodies and regulators are encouraged to recognize that new invoice syntax alone will not resolve fraud, authority, or lifecycle-integrity failures, and to support a shared trust and state-management layer that operates across existing standards.
Auditors and compliance functions should begin evaluating decomposed, cryptographically verifiable evidence as an equally valid, and eventually superior, alternative to reconciled document trails.
Understanding why the invoice is not a document is the first step. Building the capability to verify its underlying objects, rather than merely reading its content, is the next.
Glossary of Key Terms
Verifiable.Trade Blog Series — From PDF to Programmable Asset: Why the Invoice Is Not a Document
This glossary defines the core technical and conceptual terms used in this article, in addition to terms already defined in earlier entries of the Verifiable.Trade blog series (Identity, Authentication, Authorization, Delegated Authority, Object-Based Trust, vLEI, and others). Each entry links to its authoritative source where one exists.
Authority Object
A verifiable data object that defines who may issue, approve, amend, revoke, finance, settle, or dispute a trade object, and whether that authority is currently valid.
Business Email Compromise (BEC)
A fraud scheme in which an attacker impersonates a trusted party, such as an executive or supplier, by email in order to induce a fraudulent wire transfer or disclosure of sensitive data. Source: FBI Internet Crime Complaint Center (IC3).
Commercial Object
A verifiable data object describing goods, services, quantities, prices, taxes, payment terms, or contractual obligations within a trade transaction.
Reconstruction
The practice of decomposing and deconstructing a commercial document, separating the facts it contains into independently verifiable business objects that can be reconstructed and evolve on their own lifecycle while remaining cryptographically linked to the overall transaction.
Deterministic Verification
A verification approach in which a system confirms a fact directly through cryptographic proof rather than inferring it from context or probability. Contrasted in this article with the probabilistic interpretation used by AI document parsing.
Dependency Object
A verifiable data object that links a trade object to related objects, such as connecting an invoice to its purchase order, delivery note, or financing agreement.
EN 16931The European semantic data model for electronic invoicing, developed by CEN/TC 434 to implement Directive 2014/55/EU on electronic invoicing in public procurement. Source: European Commission, Directive 2014/55/EU.
Factur-X / ZUGFeRD
A hybrid electronic invoice format combining a human-readable PDF with an embedded structured XML data set, jointly developed by French and German standardization bodies.Source: FNFE-MPE / Forum elektronische Rechnung Deutschland (FeRD).
Identity Object
A verifiable data object describing a participant in a transaction, such as a supplier, buyer, logistics provider, financing institution, or AI agent.
ISO 20022
A global standard for structured electronic financial messaging, covering payments, securities, trade services, and cards. Source: International Organization for Standardization.
Lifecycle Object
A verifiable data object capturing a state-changing event in the life of a trade object, such as issuance, correction, financing, settlement, or cancellation.
PEPPOL BIS Billing
A business interoperability specification for electronic invoicing used across the Peppol network, built on EN 16931. Source: OpenPeppol AISBL.
Programmable Asset
A digital asset composed of verifiable objects that systems can evaluate and act upon directly, without repeated manual interpretation, in contrast to a static document such as a PDF.
State Model
A representation of an entity, such as an invoice, as a set of evolving business facts and their transitions over time, rather than as a single static file.
UBL (Universal Business Language)
An open library of standard XML business document formats, including invoices and orders, maintained by OASIS. Source: OASIS Universal Business Language.
UN/CEFACT Cross Industry Invoice (CII)
A cross-industry semantic data model for electronic invoices, maintained by the United Nations Centre for Trade Facilitation and Electronic Business. Source: UNECE UN/CEFACT.
This glossary will be updated as the blog series develops. For questions or suggested additions, contact the Verifiable.Trade Foundation at www.verifiable.trade/contact.
© 2026 Verifiable.Trade Foundation
