> ## Documentation Index
> Fetch the complete documentation index at: https://help.getatelier.design/llms.txt
> Use this file to discover all available pages before exploring further.

# Purchase orders

> What you send a vendor to place an order — the one document in Finance that faces a supplier rather than a client.

Everything else in Finance faces the client. A purchase order faces the
other way: it is what you send a vendor to buy the thing.

That difference runs all the way through the document. A PO carries
**trade price** — what you pay — not the selling price the client sees. It
carries a delivery address rather than a billing address. And its status
tells you where your money is, not where theirs is.

## The list

**Finance → Purchase Orders.** Each row: PO number, vendor, project,
status, created and total.

## Raising one

| Field                | Notes                                                                    |
| -------------------- | ------------------------------------------------------------------------ |
| **Vendor**           | Who you are buying from. Pulls their record.                             |
| **Project**          | Which job it is for.                                                     |
| **Delivery address** | Where the goods go. Usually the site or your warehouse, not your office. |
| **Notes to vendor**  | Special instructions, lead-time notes, anything they need to read.       |
| **Line items**       | Product name, quantity, unit and **trade price**.                        |

**Download PDF** produces the document to send. **Create PO** records it
in Atelier.

<Info>
  Unlike a proposal, invoice or change order, a purchase order has no
  client-facing link — there is nothing to share, and nothing for a vendor
  to open in a browser. **Download PDF** and your own email are the only
  way it leaves Atelier.
</Info>

<Info>
  **Trade price, not selling price.** The line total on a PO is your cost.
  Markup lives on the schedule and reaches the client through an invoice —
  it never appears on a document a vendor sees.
</Info>

## The efficient way to do it

Raising POs one product at a time is slow. The schedule does most of the
work for you:

1. **Start from the Overview.** The project Overview's **Ready to order**
   card counts everything the client approved that nobody has ordered.
   That is the queue.
2. **Group the schedule by vendor.** On the Procurement view, **Organize
   → group by vendor**. Each group is now one purchase order.
3. **Raise one PO per vendor.** Six items from one supplier is one order,
   one delivery and one conversation — not six of each.
4. **Record it back on the schedule.** PO number, order date and the
   vendor's promised ship date go on the Procurement view, and the items
   move to **Ordered**.

<Tip>
  Fill in the vendor's terms before you need them — deposit, balance, lead
  time, return policy. They live on the vendor record, and they are what
  tell you whether the installation date you just promised is real.
</Tip>

## Tracking what you have ordered

The PO is the commitment; the schedule is where you watch it arrive.
Tracking number, carrier, estimated ship and actual delivery all live on
the Procurement view, against the items themselves.

Keeping both in step is what makes *where is the sofa* answerable without
opening your email.

## Changing an order

<Warning>
  Once a PO leaves `DRAFT` the assistant will not change it, and neither
  should you quietly. A vendor working to an order they have already
  received needs a new one, or a conversation.
</Warning>

This is not bureaucracy. The vendor has already begun cutting fabric to
the order in their hand — a silently amended PDF on your side changes
nothing in their workshop.