Raise a clean purchase request

A tale of two PRs

A founder we work with showed us two PRs from the same week. Same approver, same approximate amount, near-identical timestamps.

The first one had a justification field that read: "Tools". The supplier was blank. The lines said "Subscription — 1 — £840". It sat in the approver's queue for three days while she chased the requester for context, eventually getting back something like "it's the renewal for the thing James uses". She rejected it and asked them to start over.

The second one had a justification that read: "Renew DataDog seat for the new SRE starting Monday — annual billing is ~20% cheaper than monthly. Same product we already use across the platform team." Supplier was filled in. Lines were itemised. She approved it in 90 seconds.

Same money, same approver, same product. The difference was what the requester put in the justification field. A clean PR is fast; a vague PR is a multi-day game of email tag.

This chapter is about writing the first kind.

What a PR actually is

A Purchase Request is a pre-spend artefact. It exists inside Blankitt Finance Business; the supplier never sees it. It says: "someone on our team would like to spend this money, on these line items, for this reason, and here is who has authority to say yes."

It is not a Purchase Order. A PO is the commitment that goes to the supplier. The PR is one step earlier — the internal decision to commit.

You raise one from Procurement → Purchase Requests → New request. The system creates a draft you can edit until you're ready to submit. Once you submit, the approval engine takes over.

Key point: Nothing is committed to a supplier when you raise a PR. No email is sent. No PDF is generated. The supplier has no idea this request exists. That only happens after approval, when you convert the PR to a PO.

Who can raise a PR

Anyone with tenant access. There's no "buyer" role gate in Blankitt Finance Business by design — the point of a PR is to surface every ask, including the ones from people who don't normally raise spend.

In practice:

• Engineers raise PRs for tooling — DataDog renewals, Sentry seats, the AWS top-up when a new environment spins up.
• Operations raise them for office stuff — printer cartridges, the coffee machine repair, the Slack upgrade.
• Founders raise them for advisor invoices, contractor day rates, occasional consultant work.
• Finance raise them for everything else that needs visibility before it gets paid.

The approval engine handles routing. A junior engineer raising a £200 tool subscription will hit a different policy from a founder raising a £40,000 advisor contract. Both go through the same form; the system decides who needs to say yes.

Anatomy of a PR

Walk through the form top to bottom.

Supplier. Optional at PR stage. If you know who you're buying from, pick them from the contacts list (or create a new contact inline). If you don't yet — common when the buyer is comparing two quotes, or when finance will source on conversion — leave it blank. The supplier becomes required on the PO, not the PR.

Lines. One or more line items, each with description, quantity, and unit price. PRs allow 0 unit price because the buyer doesn't always know the exact figure ("we're getting a quote next week, but I want pre-approval to spend up to £5k"). The PO converter will prompt you for real numbers before sending.

Account code. Optional. The engineer raising a PR for "DataDog renewal" doesn't usually know whether that codes to 7203 — Software subscriptions or 7204 — Monitoring and observability. Leave it blank; finance picks the code on the PO. If you do know the code, fill it in — saves a step.

Justification. The single most important field. This is what approvers read. The bar is: a reader who doesn't know what you do should be able to tell, in two sentences, what this spend is for and why now. Short and specific beats long and vague. "Renew DataDog for new SRE because data retention drops to 7 days otherwise" beats "DataDog renewal — important for monitoring" beats "Tools".

Required-by date. Optional. Set this if delivery date matters — your conference booth materials need to arrive before the conference, your contractor needs onboarding before their start date. Approvers see the date and self-prioritise; the system also flags overdue approvals against this date.

What happens when you submit

The moment you choose Submit for approval, the engine looks at your Settings → Approval policies and matches your PR against the configured rules. Policies match on three things together:

• Document type (PR, PO, Bill — we're matching PR here).
• Total amount of the PR, including any tax lines.
• Raiser — who submitted. Either by user, by team, or by role.

If a policy matches: the PR moves to pending_approval, the approver named in the policy gets notified (in-app + email), and the SLA clock starts based on their configured response time.

If no policy matches: the PR moves directly to approved. This is the right behaviour for routine spend that doesn't need a gate — for example, a £50 stationery order in a team where the threshold is £250. You don't want to bottleneck on rubber-stamping low-value items.

You'll see one of three outcomes on the PR detail screen:

1. approved — green badge. Convert to PO is now actionable.
2. pending_approval — yellow badge. The approver's name is on the card. You can edit or withdraw until they action it.
3. rejected — red badge. The approver's reason is shown. The PR is in your queue to edit and resubmit.

Rejected PRs and what to do

Editing and resubmitting is the standard pattern. The original approval request stays in the audit log — the approver can see "this was rejected once for vague justification, then resubmitted with detail". That's deliberate. You don't get to make rejections invisible. Approvers learn what gets through; raisers learn what their approver wants to see.

Rejected PRs cannot be deleted. The audit trail outweighs cleanliness. If you really don't intend to proceed, mark it withdrawn instead — same audit effect, clearer signal.

PR templates for recurring spend

If your team raises the same shape of PR over and over — the monthly AWS top-up, the quarterly DataDog renewal, the recurring team-lunch budget — turn it into a template.

A PR template lives in Procurement → PR Templates. It carries:

• The supplier.
• The line shape (descriptions, default quantities, default unit prices — all editable per instance).
• The account code (so finance doesn't keep getting asked).
• A justification template (you can pre-fill the structure; the raiser tweaks the variable bits).

To spawn a fresh PR from a template, open the template and choose New PR from this template. You get a draft PR pre-populated with the template fields; edit anything you need, then submit. Each spawned PR still runs through the approval policy — templates are about saving keystrokes, not bypassing controls.

Good template candidates:

• Monthly AWS / GCP / Azure spend (price varies, supplier and code are stable).
• Quarterly software renewals.
• Team-lunch claims (you cap the unit price in the template; raisers fill in attendees).
• Contractor day rates (one line per day; the template captures the rate).

If you find yourself copying-and-pasting from old PRs, that's the signal: make it a template.

The line between PR and PO

This is the most common confusion in early AP setups. Re-stating it explicitly:

	PR	PO
Visible to supplier?	No	Yes — the PDF is emailed to them
Commits cash?	No	Yes — it's a commitment on your books
Required price?	Optional (allows 0)	Required
Required supplier?	Optional	Required
Required account code?	Optional	Required
Produces a PDF?	No	Yes
Status flow	draft → pending_approval → approved (or rejected) → converted	draft → sent → received → closed

Think of the PR as the internal conversation ("can we spend this?") and the PO as the external commitment ("we are spending this").

Tips

• Drafts are saveable. You don't have to submit immediately. Useful if you want a colleague to look it over before it goes to an approver.
• Justification answers "what + why now". Approvers don't need product history; they need the decision case. "Renew DataDog for new SRE because data retention drops to 7 days otherwise" gives them everything to say yes in one sentence.
• If your approver keeps asking the same question, change your justification template. "Why this supplier and not the other one we use?" is a frequent follow-up. If you see it twice, pre-empt it in the justification field the third time.
• Don't game the threshold. Splitting a £6,000 PR into three £2,000 PRs to dodge the £5k policy is detectable (and detectable retrospectively in the audit log). Easier and cleaner to raise the right number and add justification.
• The required-by date is for approvers, not for procurement. If you set it to two days from now, that's a signal to the approver that you need a fast decision. Don't set it artificially tight.

What comes next

Once a PR is approved, you convert it to a PO. That's where the price gets firmed up, the account code gets settled, the supplier gets the document, and the company is on the hook for the spend. Chapter 3 covers that.