Convert PR to PO and send to the supplier

The conversation that never happened

A client of ours ordered "consulting support for the migration" from a boutique IT firm. They'd talked it through on a Zoom call — two consultants, six weeks, mostly on the strategy side, occasional implementation. Nobody wrote anything down. The supplier said "we'll send a kick-off email next week" and the client said "great".

Two months later the invoice arrived. It was for four consultants, eight weeks, almost entirely implementation, at a higher day rate than the strategy work. About £45,000 more than the client had assumed. When they pushed back, the supplier sent over their proposal document — which had been discussed on that Zoom call but never actually agreed in writing. The proposal said "two consultants minimum, scope to expand as needed". The client remembered "two consultants total".

There was no PO. There was no email confirming the agreed scope. There was no paper trail other than the supplier's proposal and the client's memory. The dispute eventually settled somewhere in the middle, costing both relationships and most of a Friday afternoon of senior-team time.

A PO would have prevented it. Not because POs are magic but because the PO is the artefact that pins the conversation down in writing, in a place both sides can see. The PR was internal. The PO is the document the supplier acknowledges.

What changes when PR → PO

Three things shift the moment a PR becomes a PO.

The supplier sees it. The PR was internal — no email left the system, no PDF was generated. Converting to PO produces a PDF, addressed to the supplier, and sends it to their nominated contact email. The supplier now has a document on file that says "this is what we agreed to buy from you".

The price firms up. PRs can carry 0 unit prices because the buyer often doesn't know. POs cannot. You must enter a real number on every line before sending. This is the moment finance reviews the figures the requester gave (often informally — "I think it's around £4k a year") and replaces them with the real ones from the quote or contract.

The account code firms up. Same logic. The engineer raising the PR didn't know whether DataDog codes to 7203 or 7204. Finance knows. On conversion, the account code becomes required and is set against your chart of accounts. This is what makes the PO post into the right place when the bill eventually arrives.

The PR also picks up two things that didn't exist before: payment terms (Net 30, Net 60, due-on-receipt, etc.) inherited from the supplier contact record, and a delivery address. Both appear on the supplier-facing PDF; both are part of what you're agreeing to.

How to convert

From an approved PR's detail screen:

1. Open the approved PR (status approved, green badge).
2. Choose Convert to PO. The system pre-fills a draft PO from the PR lines.
3. Review the supplier. If the PR was raised without a supplier ("TBD"), you must pick one now.
4. Edit the line prices. Any line still at 0 will block sending until you fill it in. Any line where the price has materially changed from the PR estimate — flag it for the approver if the change pushes the PO over the original approval threshold.
5. Set or confirm the account code on each line. Pulled from the chart of accounts.
6. Confirm payment terms and delivery address (auto-populated from supplier + your default; both editable per PO).
7. Save as draft, or choose Send to supplier to email the PDF immediately.

If the price on the PO is materially higher than what the PR was approved for — say, more than 10% above the PR total, or above a separately configured re-approval threshold — the PO routes back through approval before it can be sent. The approval engine handles this automatically. The PR approver effectively saw a budget; the PO approver confirms the actual spend.

The PO PDF

The PDF that lands in the supplier's inbox is generated on demand by the worker. A4. Single page for short POs, multi-page for long ones. Layout:

• Header. Your company details (registered name, address, company number, VAT number) — pulled from Settings → Company details. Your logo if you've uploaded one. The supplier's details on the right.
• PO number. The system-assigned identifier the supplier will quote on their invoice. Easy to find at the top.
• Order date and required-by date.
• Line items. Description, quantity, unit price, line total. Account codes are NOT shown on the supplier PDF — they're internal coding that the supplier doesn't need to see and might confuse them.
• Totals. Subtotal, VAT (split by rate if you've got mixed-rate lines), grand total.
• Payment terms in plain English ("Net 30 days from invoice date").
• Delivery address if it differs from your registered address.
• Notes field if you've added any — useful for delivery instructions or contractual references ("Per SOW dated 12 March 2026").

The PDF is regeneratable. If you re-open the PO later and re-download the PDF, you get the current state — useful if you've made a correction, but also means the supplier's original-email-attached PDF and your in-system view can drift if you don't re-send. More on that below.

Sending to the supplier

The Send to supplier action does three things:

1. Generates the latest PO PDF.
2. Emails it to the contact email on the supplier's contact record (supplier_contact.email), with a configurable subject line and body. The default body includes the PO number, total, and your payment terms.
3. Writes a row to fin_po_email_log capturing: timestamp, recipient email, message-id, the PDF version that was sent, and the user who triggered the send.

That log is your audit trail for "did we send this?" disputes. A supplier claiming they never received the PO can be checked against the log — you'll see the message-id, the timestamp, and the exact PDF that went out.

If the send fails (bounce, invalid email, mail server reject), the system flags the PO with a send_failed status and surfaces the error message. Usual cause: the supplier contact's email field is empty or malformed. Fix on the contact record, retry the send.

PO statuses

The PO progresses through four states:

Status	Meaning	What you can do
draft	Created from the PR, not yet sent	Edit freely, send, or discard
sent	PDF has been emailed to the supplier	Edit creates a v2 (see below). Awaiting goods.
received	At least one line has been GRN'd	Bills can now match against it. Continue receiving against remaining lines.
closed	All lines received + all bills paid + all reconciled	No further activity expected. Read-only.

You move through these mostly automatically — sent happens on send, received happens on first GRN, closed happens when the last reconciliation completes. You can also manually close a PO that's been abandoned (supplier pulled out, you cancelled) via Actions → Mark closed, which prompts for a reason that goes into the audit log.

Editing a sent PO

The platform refuses to silently edit a PO that's been sent. The supplier has a v1 PDF on file; changing the in-system record without re-issuing would create the kind of "what did we actually agree?" gap that POs exist to prevent.

What happens instead: when you edit a sent PO and save, the system creates a v2. Both versions persist in the audit log. You're prompted on save with two choices:

• Re-send to supplier. Emails the v2 PDF; the email body explains it's a revised version and notes what changed. A new row goes into fin_po_email_log.
• Save internal only. Logs the v2 against the PO but doesn't email the supplier. Use this for genuinely internal corrections (typo in your own delivery address, account code change) that the supplier doesn't need to know about.

If a change affects the price, scope, or quantity — anything the supplier needs to acknowledge — re-send. If it's a typo in your own internal fields, save internal only. When in doubt, re-send.

What if the supplier ignores the PO

It happens. You sent it, they didn't notice, the goods don't arrive. The platform supports re-sending without creating a v2 — choose Actions → Re-send on a sent PO and the same v1 PDF goes out again, with a new entry in the email log.

Don't change the PO to nudge the supplier. Changing creates a v2 and confuses the conversation ("which version are we acting on?"). Re-sending is the right move when nothing has changed but the supplier needs a reminder.

If after two re-sends there's still no acknowledgement, that's a procurement issue, not a PO issue — pick up the phone.

What if the price comes in different on the bill

Don't retrospectively edit the PO to match the bill. The PO captures what you agreed; the bill is what the supplier sent. Discrepancies between the two are exactly what the three-way match is designed to surface (chapter 4 covers this).

The right responses, in order of typical scenarios:

• Supplier's bill is wrong. Push back. Ask them to issue a corrected invoice. The PO is your evidence of what was agreed.
• The agreed price has genuinely changed. Raise a variation PO — a new PO that supersedes or supplements the original. Keeps the original PO intact and adds a documented variation.
• The bill is right and the PO was understated. Accept the variance on the bill (the matcher will flag it; you tick "approved variance" with a reason). Use this sparingly — frequent acceptances of price-up variances mean your initial PRs are estimating poorly.

Common mistakes

• Forgetting the supplier email on the contact. Send action fails with a clear error. Fix the contact record (Contacts → supplier → edit), retry.
• Editing a sent PO without re-sending. Supplier still sees v1; when the bill arrives matched to v2 prices, you'll get an awkward chase. Re-send when the change is supplier-facing.
• Closing a PO too early. Don't mark closed until the bill is paid and reconciled. Closing too early can cause the bill matcher to fail to find the PO, and the bill drops into the unmatched queue.
• Manually overriding statuses to skip stages. The platform allows it; the audit log captures it. If you find yourself doing this regularly, the underlying process is wrong — usually because something else upstream (GRN, bill upload) isn't being done. Fix the upstream gap rather than masking it.

What comes next

The PO is the commitment. The next stage is confirming what actually arrived against what the PO said. That's the Goods Receipt Note — and the three-way match it enables. Chapter 4 covers GRNs, partial deliveries, and how the bill matcher uses PO + GRN together to flag discrepancies before payment.