---
title: Send arrival receipt to supplier
order: 12
updated: 2026-07-12
---

# Send arrival receipt to supplier

Once a stock arrival is **approved**, you can email the supplier a receipt confirmation — a short note telling them what you received against their invoice, how much has now arrived in total against their purchase order (PO), and what is still pending. It is the procurement-side mirror of the customer-facing [delivery receipt](/docs/enquiry-bank/delivery-receipt).

The whole flow is deliberately **one-click**. This page has no email composer: the subject, body, recipient, CC/BCC and attachments all come from the firm's *Arrival Receipt Personalisation* template, so every user sends a consistent, pre-approved confirmation. You review the arrival, press *Send Receipt*, and the mail is queued. All the wording is set once in [Document templates](/docs/settings/document-templates#arrival-receipt-personalisation).

## Open the Send Arrival Receipts page

1. Open *Inventory* in the sidebar.
2. Click *In Stock*.
3. Click the kebab menu (the three-dots button, top-right of the *In Stock* header) and choose *Send Arrival Receipts*.

That opens the *Send Arrival Receipts* page (route `/inventory/in-stock/arrival-receipt-send`). It is **not** in the sidebar — the kebab entry is the only way in, keeping this sub-flow out of the primary navigation. Both the kebab entry and the page itself only appear if you hold the right permission (below); without it the page shows *"You do not have permission to send arrival receipts."*

## Who can use this page

Sending and ignoring receipts is gated by the *Send Arrival Receipt to Supplier* permission (`inventory.sendArrivalReceiptToSupplier`). A firm administrator always has access regardless of this flag. The backend re-checks this permission on every list, send, and ignore call — the page hiding is only the first line of defence.

Editing the underlying email template (*Arrival Receipt Personalisation*) is a separate, **firm-administrator-only** control in Settings — see [Configuring the template](#configuring-the-template-admin) below.

## Which arrivals appear in the list

The list shows every arrival that meets **all** of these conditions:

- **Approved** — the arrival has passed approval. Draft or pending arrivals never appear; approve them first (see [Add a stock arrival](/docs/inventory/add-stock-arrival)).
- **Not a reverse entry** — return-to-supplier (reverse) arrivals never get a receipt, because a receipt confirms goods *received*, not returned.
- **Not yet sent or ignored** — the moment you send or ignore a receipt, it drops off this list for good and does not come back.

Rows are ordered newest-first (by the arrival's creation time). The list loads `20` at a time and fetches more as you scroll.

## Filtering the list

The filter bar across the top narrows the list. Filters combine (all active filters must match), and the list refreshes as soon as you change any of them.

### Supplier

Type to search and pick a supplier. Only arrivals from that supplier are shown. Clearing it removes the constraint.

### Supplier CP

The supplier's contact person. This box is only useful **after** you pick a supplier — its options are scoped to the chosen supplier. Selecting a new supplier clears any contact person you had picked.

### Product Head

Filter to arrivals that contain at least one product under the chosen product head (category). Picking a new head clears the *Product Code* filter below it.

### Product Code

Filter to arrivals containing a specific product code. The code list is scoped to the head selected above, so pick the head first if you want the code options narrowed.

### PO Number

A free-text search on the linked purchase order number. It is a case-insensitive "contains" match, and it is **debounced** — the list refreshes about `650 ms` after you stop typing, not on every keystroke. Arrivals with no linked PO (direct arrivals) never match a PO-number search.

## The receipt table

Each row is one approved arrival. A column toggle in the top-right lets you show or hide columns; your choice is remembered per browser. The columns are:

- *PO No* — the linked PO number, or `—` for a direct arrival with no PO.
- *Supplier* — the supplier name.
- *Supplier CP* — the supplier contact person on the arrival, or `—`.
- *Products* — the product code names in this arrival, one per line.
- *Arrived* — the quantity received in **this** arrival, per product line.
- *Total Qty* — the total quantity ordered on the linked PO for that product. Shows `—` when there is no PO baseline (direct arrival, or a product that isn't on the PO).
- *PO Date* — the date on the linked PO. **Hidden by default**; enable it from the column toggle.
- *Arrival Upload Date* — when the arrival record was created.
- *Send Button* — the *Send* link that opens the review modal.

Press *Send* on any row to open the review-and-send modal.

## Reviewing a receipt

The modal is a read-only review of the arrival with the actual send button at the bottom. Nothing here edits the arrival — it only decides whether (and to whom, via the firm template) the confirmation goes out. A green *approved* chip and the supplier name sit in the header; a kebab menu in the top-right holds the secondary actions.

### Arrival Source card

Static reference details pulled from the arrival and its linked PO:

- *Supplier* — supplier name.
- *Supplier CP* — contact person name, with their email in brackets if one is on record. **This email is where the receipt is sent** in the default (*supplier*) recipient mode — if it is blank, the send is refused (see [Sending the receipt](#sending-the-receipt)).
- *PO No* and *PO Date* — from the linked PO, or `—` for a direct arrival.
- *Invoice No* and *Invoice Date* — the supplier's invoice details captured with the arrival.

### Arrival Details card

Audit and attachment metadata:

- *Generated By* — the user who recorded the arrival.
- *Approved By* — the user who approved it (only shown once approved).
- *Created* — the arrival's creation date and time.
- *Invoice Documents* — a *View N file(s)* link (or *None*) that opens the invoice attachments list.
- *PO Documents* — the same, for the linked PO's document files. Only shown when the arrival is linked to a PO.

### Products table

One row per product in the arrival. Columns:

- *Head* — the product's external display head (falls back to the internal head name).
- *Code* — the product code.
- *Qty* — the quantity received in **this** arrival, with its unit.
- *Arrived (cum.)* — the cumulative quantity received against the PO **up to and including this arrival**. Shows `—` when there is no PO baseline.
- *Total* — the total quantity ordered on the PO for that product. `—` without a PO baseline.
- *Pending* — ordered minus cumulative-arrived, floored at `0`. Rendered in red when greater than `0`. `—` without a PO baseline.

Expanding a row reveals the product's *HSN* and full *Description*.

Whenever a product line has no PO baseline — a **direct arrival** with no linked PO, or a product that simply isn't on the PO — the cumulative, total, and pending figures all read `—`. There is nothing to measure "pending" against, so the receipt just confirms the quantity received.

### Viewing invoice and PO documents

The *View N file(s)* links open an attachments list showing each file's name, format, and size, with a *View* button per file. Viewing streams the file through a secure download and opens it in the in-app file preview (this works the same in the web app and the desktop app). These are the files that may also be attached to the outgoing email, depending on the template's attachment switches.

### Open the linked purchase order

If the arrival is linked to a PO, the modal's kebab menu offers *Open Purchase Order*, which takes you to that PO's record. The entry is hidden for direct arrivals.

## Sending the receipt

Press *Send Receipt* at the bottom of the modal. The app then, in order:

1. Asks the backend which email accounts are allowed for the *Arrival Receipt Send* use-case and picks the first allowed account. If **no** account is allowed, the send is blocked with *"No email account is allowed for arrival-receipt sends. Configure the email policy in Firm Customisation first."* — fix this under [Email accounts and sending policy](/docs/settings/document-templates#email-accounts-and-sending-policy).
2. Reads the firm's arrival-receipt recipient mode so it can pick the right recipient (the supplier contact person, or the firm's fixed mailbox in *fixed* mode).
3. Queues the mail. A worker then composes and sends it in the background, so the toast reads *"Receipt queued for sending"* — the email goes out moments later, not synchronously. The row disappears from the list immediately.

Because the content is entirely template-driven, there is no subject/body editor on this screen — to change any wording, edit the [Arrival Receipt Personalisation](/docs/settings/document-templates#arrival-receipt-personalisation) template first.

### What the backend guarantees (server-side re-checks)

Everything is re-validated on the server so a forged or repeated request can't cause a double-send or leak:

- **Single send, race-safe.** Before anything else, the backend atomically stamps the arrival as "queued". That stamp is what removes it from the list. A second click — yours or a colleague's at the same moment — hits an already-stamped arrival and gets a `409` *"This arrival receipt has already been sent, ignored, or is not eligible to send"* instead of a duplicate email.
- **Account re-verified.** The chosen email account is re-checked against the *Arrival Receipt Send* policy. If it isn't allowed, the stamp is rolled back and the send is refused (`403`) so you can pick another account.
- **Recipient re-resolved.** The recipient is derived from the firm template, not trusted from the client:
  - *Supplier* mode (default) → the supplier contact person's email.
  - *Fixed* mode → the firm's fixed mailbox (must be a valid address).
  - *Hybrid* mode → the contact person, or the fixed mailbox if the sender chose it.
  If no valid recipient can be resolved, the stamp is rolled back and the send is refused (`400`) — e.g. *"Supplier contact person has no valid email address"* or *"Firm fixed email is not configured or is invalid"*.
- **CC/BCC from the template.** The firm-wide CC and BCC lists are attached automatically and de-duplicated against the recipient.
- **Attachments snapshotted.** Only files that have finished uploading are attached, per the template's switches (invoice documents and/or the PO copy).
- **Stable numbers.** The "arrived till now" figures are computed up to this arrival's approval time, so they stay correct even if a newer arrival for the same PO is approved afterwards.

## Ignoring a receipt

Some arrivals never need a supplier email — internal transfers, samples, or anything you'd rather not confirm by mail. Open the modal, open the kebab menu, and choose *Ignore Sending The Receipt*. A confirmation appears (*"Ignore this arrival receipt? No mail will be sent. The receipt will be marked as ignored and stop showing up in this list. This can't be undone."*). Confirm and the arrival is permanently removed from the list with no email sent.

Ignoring uses the same atomic gate as sending, so a race between *Send* and *Ignore* can never double-process the same arrival — whichever lands first wins, and the other gets a `409`. **Ignoring cannot be undone** from this screen.

## What the supplier receives

The email is built from the *Arrival Receipt Personalisation* template. Out of the box:

- **Subject** — default `Receipt confirmation for invoice {invoiceNo}`.
- **Body** — default:

  > `Dear {contactPerson},`
  > `This is to confirm that we have received the following items against your invoice {invoiceNo} dated {invoiceDate}.`
  > `{ProductTable}`
  > `Please let us know if there are any concerns.`
  > `Regards,`

- **Product table** — the `{ProductTable}` placeholder expands to a styled HTML table with the columns `#`, `Item`, `This Arrival`, `Arrived Till Now`, `Ordered`, `Pending`, and `Description`. Lines with no PO baseline show `—` in the cumulative, ordered, and pending cells.
- **Attachments** — the arrival's invoice documents and (optionally) the linked PO's document files, according to the template's switches (see below).
- **Additional charges** — if the template's *Include additional charges* option is on, a small table of the PO charges attached to the arrival (with a charge-inclusive total) is appended below the products table.

The tokens the arrival-receipt template understands are `{supplier}`, `{contactPerson}`, `{poNo}`, `{poDate}`, `{arrivalDate}`, `{invoiceNo}`, `{invoiceDate}`, and `{productsCommaSeparated}` in the subject and body, plus `{ProductTable}` in the body only. These are inserted (with quick-insert buttons) from the personalisation modal, not from this send page — anything you type that isn't a recognised token is left as-is at send time. The full editable list lives on [Document templates](/docs/settings/document-templates#arrival-receipt-personalisation).

## Configuring the template (admin)

The wording, recipient, CC/BCC, and attachments are all set in Settings, and this entry is **firm-administrator only**:

*Settings → Firm Customisation → Procurement → Arrival Receipt Personalisation*.

There you can set:

- **Recipient mode** — *Supplier contact person* (`supplier`, the default), *Fixed mailbox* (`fixed`), or *Hybrid* (the sender chooses at send time). *Fixed* and *Hybrid* require a valid fixed mailbox address before the modal will save.
- **CC & BCC lists** — firm-wide addresses copied on every arrival receipt, up to `20` each.
- **Email subject** and **email body** — with the tokens listed above.
- **Attachments** — *Attach invoice documents from the arrival* (**on by default**), *Attach PO documents (when linked to a PO)* (**off by default**), and *Include additional charges* (**off by default**).

Full field-by-field detail — including defaults, ranges, and the email sending policy — is on [Document templates](/docs/settings/document-templates#arrival-receipt-personalisation).

## Common questions

### An arrival I just approved isn't in the list — why?

Check three things: it must be **approved** (not draft/pending), it must **not** be a reverse/return-to-supplier entry, and it must **not** already have been sent or ignored. Reverse entries never get a receipt by design.

### I pressed Send but the supplier says nothing arrived. Did it send?

Sending is asynchronous — the toast says *"Receipt queued for sending"* because a background worker delivers the mail moments later. If the supplier never receives it, the most common cause is a missing or invalid recipient email (the contact person has no email address on file) or an email account problem. Fix the contact person's email or the sending policy and, because the arrival is now stamped, contact an administrator if you need it re-sent.

### The send button gave an error about email accounts.

No email account is allowed for the *Arrival Receipt Send* use-case yet. A firm administrator sets this under *Firm Customisation → Email Accounts → Policy*. See [Email accounts and sending policy](/docs/settings/document-templates#email-accounts-and-sending-policy).

### Why do the "Arrived", "Ordered", and "Pending" columns show `—`?

That arrival (or that product line) has no PO baseline — it is a direct arrival with no linked purchase order, or the product isn't on the linked PO. Without an order to measure against there is nothing to total or mark pending, so those cells show `—` and the receipt just confirms the quantity received.

### Can I edit the email before it goes out?

Not from this page — it is one-click by design so every user sends the same, firm-approved confirmation. Change the wording, recipient, or attachments in the [Arrival Receipt Personalisation](/docs/settings/document-templates#arrival-receipt-personalisation) template (firm-administrator only) and it applies to every send made afterwards.

### I ignored a receipt by mistake — how do I get it back?

You can't from this screen; ignoring is permanent and removes the arrival from the list without sending anything. The arrival record itself is unaffected — only the receipt-send opportunity is closed.

### Two of us clicked Send on the same receipt. Did the supplier get two emails?

No. The backend stamps the arrival atomically before queuing, so only the first click wins and the second gets a *"already been sent, ignored, or is not eligible to send"* message. The same guard protects a simultaneous *Send* and *Ignore*.
