Purchase Orders and Approval Documents

A purchase order is a small document doing a surprisingly large job: it is an offer, a budget commitment, an authorisation record, and the key that matches an invoice to a receipt three months later. Organisations that handle POs badly do not usually have a purchasing problem — they have a document problem, where the authorisation exists in an email thread nobody can find and the invoice cannot be matched to anything. This covers how the documents in a purchase-to-pay cycle actually work and where they come apart.

The document chain

The standard sequence, and what each document is for:

1. Requisition — an internal request to buy something. Establishes need and gets budget approval. Frequently skipped in smaller organisations, which is where uncontrolled spending begins.
2. Purchase order — the authorised order sent to the supplier. Carries a unique PO number, line items, prices, quantities, delivery details and terms. Legally, an offer to buy.
3. Order acknowledgement — the supplier accepting, sometimes with changes. Worth keeping, because a supplier's acknowledgement with different lead times is the document that resolves a later dispute.
4. Goods received note / delivery note — evidence that what was ordered arrived. The often-missing link in the chain.
5. Invoice — the supplier's demand for payment, referencing the PO number.
6. Remittance advice — confirmation of what was paid and against which invoices.

The critical structural point is the three-way match: PO, receipt, and invoice must agree before payment. That control is what stops duplicate payments, quantity discrepancies, and invoices for things nobody ordered. It only works if all three documents exist, are findable, and carry a common reference.

Why the PO number is the whole system

Every document in the chain should carry the PO number, prominently and machine-readably. It is the join key.

Practical consequences:

• Invoices without a PO number cannot be matched and go into an exceptions queue where they age, get chased, and eventually get paid late. If you are a supplier, putting the PO number on the invoice is the single highest-value thing you can do to get paid on time. If you are a buyer, a "no PO, no pay" policy — enforced — is what makes the control real.
• Put it in a consistent position on the document, so extraction can find it. Top right of page one is conventional.
• Make it unique and sequential, with a prefix if you have multiple entities: PO-2026-04417.
• Never reuse a number, including for a revised order. A revision is PO-2026-04417 Rev B, not a new document with the same number.

Approval, and where it should live

The recurring failure: the approval exists as "yes, go ahead" in an email, and six months later nobody can establish who authorised a £40,000 commitment.

What an auditable approval record needs:

• Who approved, identifiably.
• What they approved — the specific version of the specific document, not "the order".
• When.
• Under what authority — the delegation of authority that gave them the power to approve that amount.

Three ways to hold this, in descending order of robustness:

A purchasing system with approval workflow built in. The record is structured, searchable and hard to falsify. This is what any organisation past a certain size should have, and the documents it produces are outputs rather than the record itself.

A signed PDF. For organisations without a system, a PO approved with a digital signature carries its own evidence: the signature binds the approver to the specific document bytes, and it is verifiable later. See digital signatures vs electronic signatures and how to verify a digital signature in a PDF. For anything with a long retention period, long-term validation and PDF timestamps explains why a signature alone may not still verify in five years.

An email thread, attached to the document. Weak, common, and better than nothing — provided the email is filed with the PO rather than left in an individual's mailbox.

The general shape of approval routing is covered in document approval workflows.

PDF as the exchange format

POs and invoices are exchanged as PDFs overwhelmingly, and that creates a well-known friction: a human-readable document that a machine has to parse to process.

Three approaches coexist:

PDF plus extraction. The dominant reality. The supplier sends a PDF invoice; the buyer's system extracts the fields. Accuracy is good for consistent, machine-generated documents and poor for scanned ones. See AI data extraction from PDFs and extracting tables from PDFs with AI.

Structured e-invoicing. EDI, UBL, Peppol, and — increasingly mandatory in Europe — the hybrid formats. ZUGFeRD and Factur-X are the interesting case: a PDF/A-3 file with an XML invoice embedded as an attachment. The human sees a normal PDF; the machine reads the XML. No extraction, no ambiguity, one file. This is the direction of travel, driven by e-invoicing mandates in Italy, France, Germany, Poland and elsewhere, and it is worth knowing about before a mandate arrives. The mechanism is the embedded-file feature described in PDF attachments and embedded files, and the archival container is PDF/A.

Portal upload. The buyer's system is the system of record and the supplier types the invoice in. Reliable for the buyer, tedious for the supplier, and the reason large organisations' suppliers complain about portals.

If you are choosing, hybrid PDF/XML is the format that satisfies both the person who has to read it and the system that has to process it.

Extraction that works

If you are parsing PDFs, a few things determine whether it works:

• Text-based PDFs extract reliably; scans do not. Ask suppliers to send generated PDFs rather than scans of printouts. This one request improves match rates more than any tooling change.
• Consistent layouts per supplier allow template-based extraction, which is accurate and cheap. Model-based extraction handles variety but needs validation.
• Validate arithmetic. Line items should sum to the subtotal, tax should compute correctly, the total should match. This catches extraction errors that no confidence score will — and it is the same warning as in OCR language support and accuracy: recognition errors in numbers are silent.
• Match on the PO number first, then verify amounts. Fuzzy matching on supplier name and amount is how duplicate payments happen.

The fraud problem

Purchase-to-pay is one of the most attacked business processes there is, and the attacks are document-shaped.

• Bank detail changes. An email, apparently from a known supplier, with a "new" account number and an invoice PDF that looks perfect. Verify by calling a number you already hold — never one from the email or the document. This attack succeeds constantly, at organisations of every size.
• Fake invoices for plausible services, sent to accounts payable in the hope they are paid without a matching PO. A strict no-PO-no-pay rule defeats this entirely.
• Duplicate submission, the same invoice sent twice in slightly different forms. Detection depends on matching, not on vigilance.
• Altered PDFs. An intercepted genuine invoice with the bank details edited. Metadata and structure sometimes reveal the edit — see how to detect tampered PDFs and PDF incremental updates explained — but the reliable control is process, not forensics.

The pattern in all four: the document looks fine. Controls that depend on someone noticing a suspicious PDF do not work. Controls that require a matching PO and out-of-band verification of payment changes do.

Retention and audit

POs, invoices and receipts are financial records with statutory retention periods — commonly six to ten years depending on jurisdiction and tax regime.

• Archive the whole matched set together: PO, receipt, invoice, approval evidence, remittance. An invoice alone does not evidence anything.
• Use a durable format. PDF/A for the archive; the searchable text layer preserved so the archive is usable. How to archive PDFs long term.
• Preserve the approval evidence, which is the part most likely to be lost because it lives in a system that gets replaced.
• Set and enforce a deletion schedule at the end of the period: document retention policies.

For small organisations

Everything above scales down. Without a purchasing system:

• Number your POs sequentially and keep them in one folder.
• Require a PO for anything above a threshold you set — even if the PO is a one-page PDF you produce yourself.
• File the invoice next to the PO it matches, named with the same reference.
• Keep the approval, even if it is a forwarded email, in the same folder.
• Reconcile monthly rather than annually.

The relevant end-to-end setup is in PDF workflows for small business owners, and the process side in document approval workflows.

Summary

The PO number is the join key for the entire purchase-to-pay chain, and a three-way match between order, receipt and invoice is the control that makes it work — which requires all three documents to exist and be findable. Hold approvals in a system or a signed PDF rather than an email thread, prefer generated PDFs to scans for anything you must parse, validate extracted arithmetic rather than trusting it, and never accept a change of bank details without verifying out of band.