---
title: Purchase order follow-up
order: 9
updated: 2026-07-12
---

# Purchase order follow-up

The *Purchase Order Follow-Up* screen is the working area for chasing suppliers on purchase orders you have already emailed but that are still open — the goods haven't arrived, or only part of the order has. It lists every PO that is fair game for a reminder, lets you filter down to the ones you care about, and sends a reminder ("chase") email to several suppliers at once. The reminder wording, recipient, and tokens all come from your firm's *Purchase Order Follow-up* template — this screen only decides *which* POs get chased and *which mailbox* the chase is sent from.

The screen mirrors the RFQ-side [Vendor follow-up](/docs/procurement/vendor-follow-up) screen, but for issued purchase orders instead of open RFQs. The two look and behave the same; they just act on different stages of procurement.

Unlike the vendor and customer follow-up screens, PO follow-up has **no auto-terminal state**: there is no "give up after N reminders" rule, because the arrival flow (not a reminder count) is what closes a PO. Reminders simply nudge the supplier until the stock is booked in.

## Open follow-up

The screen has **no sidebar entry of its own**. Open it from *Purchase Orders*:

1. Open *Procurement* in the sidebar and click *Purchase Orders*.
2. Click the options button (the sliders icon) at the top right of the list.
3. Choose *PO Follow-up* (the bell entry, described as "Chase suppliers on sent / partially-arrived POs"). The page heading reads *Purchase Order Follow-Up*.

The *PO Follow-up* menu entry — and the screen itself — only appear if you hold the *View Already Placed Purchase Orders* permission (`procurement.viewAlreadyPlacedPurchaseOrders`); this is the same permission that lets you open the purchase-orders list. The backend re-checks it on every list request and returns `403 Forbidden` without it, so a hand-crafted request can't bypass the gate.

To actually *send* a chase you additionally need the *Send Purchase Order Follow-Up* permission (`procurement.allowPurchaseOrderFollowUp`, which itself depends on *View Already Placed Purchase Orders*). Without it you can still browse the list and open the history, but the row checkboxes and the *Send Follow-ups* button are hidden, and the send endpoint rejects the request server-side.

## What you see

A filter panel sits above a table of open purchase orders. The list loads `10` rows at a time and pages in more as you scroll. A glass "selection bar" floats at the bottom of the screen once you tick at least one row.

The list is deliberately narrow: it shows **only** POs whose status is `sent` (emailed to the supplier, nothing arrived yet) or `partiallyArrived` (some line items booked in, more outstanding). A PO that is still a draft, fully `arrived`, or `cancelled` never appears. That filtering is done on the server, so a row you see is always a legitimate chase target at the moment it loaded.

### Live "follow-ups sent" prompt

If a PO follow-up finishes sending — by you, by another user in your firm, or by the background worker — while you are on the screen, a *PO follow-ups sent* prompt appears. It tells you how many just went out (`A purchase-order follow-up email was just sent.` for one, or `N purchase-order follow-up emails were just sent.` for more) and offers *Refresh* (re-fetch the current page so the dates and counts are current) or *Dismiss*. The counts and history behind the table are stale until you refresh. If more sends land while the prompt is open, it re-appears with the updated total when you close it, so nothing is lost silently.

You can also refresh manually at any time from the options dropdown on this screen (see [Table options](#table-options)).

## Filters

The filter panel has four searchable dropdowns plus a status selector. Leaving one blank means "don't filter on this". Changing any filter clears your current row selection so you never send a chase to a row you can no longer see.

Each ID filter is validated on the server: a value is only applied if it is a well-formed record ID, so a malformed or foreign-tenant ID is ignored rather than crashing the list.

### Supplier

Restricts the list to POs for one supplier. Search by name and pick from the results. Clearing or changing the supplier also **clears the contact-person filter**, because contact people belong to a supplier.

### Contact person

Restricts to POs addressed to one of the selected supplier's contact people. This dropdown is scoped to the supplier chosen above — pick a supplier first for it to be meaningful.

### Product head

Restricts to POs that include a line item under the chosen product head (product family). Changing or clearing the product head also **clears the product-code filter**.

On the server this expands to "any product code belonging to that head". If the head has no product codes at all, the list comes back empty.

### Product code

Restricts to POs that include a specific product code. Scoped to the selected product head. A product-code filter takes **precedence** over a head filter when both are set — the server uses the code and ignores the head in that case.

### Status

A dropdown that narrows the two eligible statuses further. Options:

- *All eligible* (`all`) — both `sent` and `partiallyArrived` POs. **Default** (also what an empty/unspecified value means).
- *Sent — none arrived* (`sent`) — only POs where nothing has been booked in yet.
- *Partially arrived* (`partiallyArrived`) — only POs where some line items have arrived and more are outstanding.

The server treats a missing value and `all` identically, and rejects anything outside these three tokens.

## The table

Each row is one purchase order. Columns (the options dropdown lets you show/hide each one):

| Column | Shows |
|---|---|
| *PO No* | The purchase-order number, e.g. `2026-0042`. `—` if the PO carries no formatted number. |
| *Supplier* | The supplier's name. |
| *CP* | The contact person the PO was addressed to. |
| *Product* | The product code(s) on the PO, one per line. |
| *Qty* | The quantity for each of those lines, aligned with *Product*. |
| *Status* | A chip — *Sent* (accent) or *Partially arrived* (amber). |
| *PO Sent* | The date the PO's first email went to the supplier. `—` if not recorded. |
| *Last Sent* | The date of the most recent email (initial PO *or* any follow-up) to this supplier. Falls back to the PO-sent date. |
| *Follow Ups* | The dates of every **successful** follow-up already sent for this PO, newest first. `—` if none yet. |
| *Select* | A checkbox to include the row in a chase. Only present if you have the *Send Purchase Order Follow-Up* permission. |

Two counts behind the table are computed server-side from the PO's send queue: *Follow Ups* counts only **successful follow-up** sends (the initial PO email doesn't count as a follow-up), while *Last Sent* looks at **all** successful sends (initial email + follow-ups). Queued or failed sends are not counted in either.

### Row actions

Right-click a row (or use its context menu) for three actions:

- *View Purchase Order* — opens the PO detail page for this order, where you can view or resend it, edit it, or mark an arrival against it. See [View a purchase order](/docs/procurement/view-purchase-order).
- *Follow-up History* — opens the [follow-up history](#follow-up-history) modal for this PO.
- *Latest PO Send* — opens the [latest PO send](#latest-po-send) modal for this PO.

### Table options

The sliders button at the top right of the *Purchase Order Follow-Up* screen opens a small menu:

- *Toggle Columns* — show or hide individual columns. A *Reset* link restores the default column set. Column visibility is remembered per browser.
- *Refresh* — reload the follow-up list from scratch.

## Send a chase

1. Tick the *Select* checkbox on each PO you want to remind. The selection bar at the bottom counts how many are selected.
2. Click *Send Follow-ups* on the selection bar (or *Clear* to start over).
3. The *Send N PO Follow-up(s)?* modal opens.
4. Pick a mailbox under *Send from* (see below), then click *Send N Follow-up(s)* to confirm.

Each chase is **queued**, not sent instantly — a background worker actually delivers the mail. On success you get a toast such as `3 follow-ups queued`, and if some rows were dropped it reads `3 follow-ups queued (1 skipped)`. The screen then clears your selection and refreshes.

### Send from

The *Send from* dropdown lists the mailboxes you are allowed to send supplier follow-ups from. It is populated from your firm's *Supplier Follow-up* sending policy and only shows accounts that are currently **valid** (an account that failed verification is filtered out). If exactly one account qualifies, it is pre-selected.

PO follow-ups **share the supplier-follow-up mailbox policy with vendor RFQ follow-ups** — both go to suppliers, so the firm configures one policy for both. Each option is labelled with its owner and address: `[firm]` accounts belong to the firm, `[user]` accounts are your own personal mailbox, with the sender name shown when one is set.

If the dropdown is empty you'll see *No account is allowed for supplier follow-ups. Ask an admin to configure the policy.* Set up mailboxes and the *Supplier Follow-up* policy under [Email accounts and sending policy](/docs/settings/document-templates#email-accounts-and-sending-policy).

### What the server checks before queuing

The confirm modal is only the request; the backend re-validates everything before anything is queued (assume the request can be forged):

- **Permission** — you must hold *Send Purchase Order Follow-Up*; otherwise the whole request is rejected with `403 Forbidden`.
- **Batch size** — between `1` and `50` POs per send request.
- **Mailbox policy** — the chosen account must be in your firm's *Supplier Follow-up* (`followupSupplier`) policy set. A mailbox you're not entitled to is rejected even if you somehow selected it.
- **Row eligibility** — each PO must still be in the `sent` or `partiallyArrived` state. Rows that fail (wrong status, or a foreign/invalid ID) are **skipped**, not sent, and reported in the "skipped" count. This is why a PO that arrived between your last refresh and your send simply drops out instead of getting a needless reminder.
- **A prior successful PO send must exist** — a follow-up is threaded onto the original PO email and re-uses its PDF and attachments, so a PO with **no successful initial send on record** is skipped ("cannot follow up before the first email goes out").
- **Recipient** — the actual to/cc addresses are derived server-side from the *Purchase Order Follow-up* template's recipient mode (supplier contact person, fixed mailbox, or hybrid), never from anything the browser sends. If the mode resolves to no valid email address (e.g. the contact person has no email, or the firm's fixed mailbox is blank/invalid), that row is skipped.
- **Subject** — if the template's subject resolves to empty text after tokens are filled, the row is skipped.

Every row that passes becomes a queued job; the skipped rows are returned so the toast can show the count.

### What goes in the chase email

The subject and body come from your firm's *Purchase Order Follow-up* template. The original PO's PDF and every attachment the supplier first received are **re-attached automatically** to each reminder, and the follow-up is threaded onto that first email — there are no attachment toggles on this screen. The `{followUpList}` token in the template body expands to a list of the previous reminders already sent for that PO (empty on the very first follow-up).

To change the wording, recipient, or tokens, edit the template under [Document templates → PO follow-up](/docs/settings/document-templates#po-follow-up). The default subject is `Following up on PO {poNumber}`, and the recipient defaults to the supplier's contact person. Template changes only affect chases sent *after* you save them.

## Follow-up history

*Follow-up History* (from a row's actions) lists every follow-up ever attempted for that PO — queued, sent, or failed — newest first, with a *Refresh* button to re-pull. Each entry shows:

- A status chip: *Queued*, *Processing*, *Sent*, or *Failed*.
- When it was sent (or approved), and an *Attempt #N* badge if the worker retried.
- The mailbox it was sent *via*.
- *Queued by* and *Approved & sent by* (the users, with timestamps).
- The resolved *Subject*, and the *To* / *Cc* addresses actually used.
- The attached PO PDF and any other attachments, each with *View* and *Download* buttons.
- On a failed entry, the *Last error* returned by the mail server.

If no follow-up has been sent for the PO yet, the modal shows *No follow-ups sent for this purchase order yet.*

Opening the history (and the latest-send modal) needs either the *View Mail History of Enquiries* permission (`procurement.viewMailHistoryOfEnquiries`) or the *View Already Placed Purchase Orders* permission. Viewing or downloading the attached files goes through a separate endpoint that requires *View Already Placed Purchase Orders* — so anyone who can open this screen can also open the files. The server verifies each requested file actually belongs to that queue entry (its PDF or one of its snapshotted attachments) and is fully stored before streaming it, so a forged file ID can't pull unrelated bytes.

## Latest PO send

*Latest PO Send* (from a row's actions) shows the most recent **successful** original PO email sent to this supplier — the initial send, not a follow-up. It uses the same card layout as a history entry (status, sender, subject, recipients, PO PDF, and attachments with *View* / *Download*). It's the quick way to confirm exactly what the supplier first received before you chase them again. If no PO email has successfully gone out yet, it shows *No successful PO send recorded for this purchase order yet.* The same permission and file-download rules as the history modal apply.

## Common questions

### Why isn't a purchase order showing in the list?

The list only shows POs in the `sent` or `partiallyArrived` state. A PO drops off once every line item has arrived (status `arrived`), once it is `cancelled`, or while it is still an unsent draft. Use the *Status* filter to narrow to *Sent — none arrived* or *Partially arrived*, and refresh to be sure you're looking at the current state.

### A supplier already delivered against one of the rows I ticked — will they get a needless reminder?

No. Refresh first and fully-arrived POs disappear, but even if you don't, the backend re-checks every selected row at send time and skips any that are no longer in `sent`/`partiallyArrived`. Skipped rows are reported in the toast's "skipped" count.

### I ticked a PO but it was skipped — why?

A row is skipped when, at send time, it is no longer eligible (arrived/cancelled), has no successful initial PO email on record to thread onto, resolves to no valid recipient email (contact person has no address, or the firm's fixed mailbox is blank), or the template subject comes out empty. The other selected rows still send.

### No accounts appear in *Send from*.

No mailbox is allowed for supplier follow-ups (the *Supplier Follow-up* sending policy has no valid account). Ask an admin to add a mailbox and update the policy under [Email accounts and sending policy](/docs/settings/document-templates#email-accounts-and-sending-policy). Accounts that failed verification are also hidden until re-verified. This is the same policy used by [Vendor follow-up](/docs/procurement/vendor-follow-up).

### Can I customise the chase message?

Yes, but not on this screen. The subject, body, tokens, and recipient mode live in the firm-wide *Purchase Order Follow-up* template under [Document templates](/docs/settings/document-templates#po-follow-up). The default subject is `Following up on PO {poNumber}`. Here you only choose which POs go out and which mailbox they send from.

### Does the follow-up include the PO PDF and attachments?

Yes — the original PO's PDF and every attachment the supplier first received are re-attached automatically to each reminder, and it threads onto the first email. There is nothing to toggle.

### Can I chase a PO without using this screen?

Yes — open the PO from *Purchase Orders* and resend it from its detail page. The follow-up screen is for chasing several POs in one go. See [View a purchase order](/docs/procurement/view-purchase-order).

### How many purchase orders can I chase at once?

The selection can be any size on screen, but a single send request is capped at `50` POs on the server; if you need more, send in batches.

### The reminder was queued but the supplier says they never got it.

Sending is asynchronous, so "queued" means the job was accepted, not delivered. Open *Follow-up History* for that PO: a *Failed* entry shows the mail server's *Last error*, and a *Sent* entry confirms delivery and the exact recipients used. If it's failing, check the sending mailbox is still valid.

### Why is there no "auto-close after N reminders" like vendor follow-up has?

Because a PO isn't resolved by a reminder count — it's resolved when the stock arrives. Booking in the goods (see [Add a stock arrival](/docs/inventory/add-stock-arrival)) moves the PO to `partiallyArrived` and then `arrived`, at which point it drops off this list. Reminders only nudge the supplier in the meantime.

### What's the difference between this and the *Vendor Follow-Up* screen?

[Vendor follow-up](/docs/procurement/vendor-follow-up) chases suppliers for a **quotation** on an RFQ that hasn't been answered. This screen chases suppliers on a **purchase order** that's already been issued but not yet fully delivered. They look and behave the same but act on different stages of procurement, and they share the same *Supplier Follow-up* mailbox policy.