> ## Documentation Index > Fetch the complete documentation index at: https://docs.getprimo.com/llms.txt > Use this file to discover all available pages before exploring further. # Purchasing policy > An AI-powered policy that defines how an order is authorized, where it ships, which billing profile pays, and who you buy from — the rulebook Primo AI reads before placing any order. The Purchasing Policy is an **AI-powered policy** that governs **how** a purchase happens: what goes through on its own, who signs off on the rest, where parcels are delivered, which billing profile pays, and which suppliers you buy from. You write it in plain language — Primo AI interviews you, or reads your own orders, addresses and billing profiles and proposes a first draft. Once published, it is the text Primo reads at runtime — when you review an order, and when Primo AI equips a new hire during an onboarding. There is one Purchasing Policy per company. The Purchasing Policy defines **how** a purchase is authorized. It is separate from the [Equipment policy](/procurement/equipment-policy), which defines **what** each employee is entitled to. Don't write which laptop a role gets here — write the constraints that govern the order. ## Set up your policy Find the **Purchasing policy** card and click **Setup**. Once a policy exists, the card shows its status chip instead. Primo AI opens the conversation with two options: * **Ask me questions** — it interviews you one decision at a time, proposing a recommended answer each time. * **Analyze my company data** — it reads your orders, employees, company addresses, billing profiles, shipping countries and catalog prices first, writes a complete first draft, then walks you through it and only asks about what your data couldn't settle. You can also just describe what you want in your own words. The editor sits next to the conversation. Each time an answer settles part of the policy, Primo AI writes it into the draft — you see the rule land rather than a promise to note it. Changes you type directly in the editor autosave as a draft too. Drafts are never applied. Click **Publish changes** in the bar at the bottom of the editor to make the policy live. The status pill at the top of the editor tells you where the policy stands: | Status | What it means | | ------------------- | -------------------------------------------------------------------------------------- | | **Unpublished** | A draft exists but nothing is live. Primo reads nothing. | | **Published** | The live version is what Primo reads at runtime. | | **Pending changes** | A published version is live, and your draft holds newer edits that aren't applied yet. | Use **Discard** to drop unpublished edits, or **Unpublish** from the header menu to stop applying the policy while keeping your draft. ## What your policy must answer A Purchasing Policy exists to settle five questions about one concrete order. A policy that answers these five in a page is a finished policy. 1. **May it be placed?** What is auto-approved and what needs sign-off. The simplest working rule: in line with the Equipment policy → auto-approved, anything else → sign-off. An amount threshold works too. 2. **Who signs off?** A real person or team with a contact. If it's "their manager", say so — and make sure the manager is resolvable from the employee record. 3. **Where does it ship?** One default destination, by name and full postal address, then the exceptions that actually exist. 4. **Which billing profile pays?** Name it. 5. **Who do you buy from?** The Primo catalog, plus a tie-break when two suppliers can serve the same item — for example zero-touch first, then stock in the delivery country, then price. A billing profile whose only payment method is a credit card **cannot pay for an equipment order**. Naming it as your default makes the rule unusable at runtime. Primo flags profiles that can pay — name one of those. ### Add more only when you need it Write what your data shows and nothing more. One office means one destination, not a per-country section. Each of these earns its place only when something real triggers it: * **A larger authorization model** — a delta measured against the Equipment policy, or a per-person budget that accrues and acts as the authorization itself. * **Routing between several approvers** — name the key that routes to each (legal entity, team, amount), and say what happens when that key is empty on the employee record. * **Delivery beyond one office** — which office per work location, where a home address comes from, which saved addresses must never be used, and what happens in a shipping country with no company address. * **Renewal** — after how long a device is replaced, what justifies an early replacement, and what happens to the old one. * **Spending rules, order references, and scope** — what the account covers, the PO or cost-centre field to fill, and who is excluded from these rules. A rule you can't run yet — a field nobody fills in, a profile that can't pay — belongs in the policy marked as a known gap, with the interim behaviour. A reader has to be able to tell a rule from an intention. ## Write rules Primo can act on * **Be concrete.** "Expensive orders need sign-off" is not a rule. "Above €1,500, Camille signs off" is. * **Use real names** — your teams, offices, countries and suppliers, never placeholders. * **State amounts with a currency**, anchored on what things actually cost in your catalog. * **Say what happens when something is missing** — an unset work location, no approver for an entity. Primo AI never invents a default; a silent policy stops the run and asks you. * **Say when a rule doesn't exist.** "No price cap" written down reads as a decision; left out, it reads as an omission. ## Where your policy applies * **Order review** — the policy decides what needs your sign-off, where the order ships, and which profile pays. * **Onboarding** — when the **Purchase equipment** step is set to **Automatic**, Primo AI reads this policy plus the Equipment policy to equip a new hire. It also reads the timing you write here, such as *"handle equipment 30 days before the start date"*. See [Purchase equipment at onboarding](/employees/purchase-equipment-at-onboarding). Both policies must be published for the onboarding step to run automatically. While either is unpublished, the step falls back to a person. ## Best practices **Analyze my company data** grounds the first draft in the orders you already place, instead of rules you think you follow. Five answered questions beat ten sections half-filled. Depth is the admin's choice to add, never noise to fill. "A contractor in Poland needs a monitor — cap, approver, address?" If the policy can't answer, the rule isn't finished. Nothing applies until you publish. After publishing, confirm the status pill reads **Published** and not **Pending changes**.